Caso de éxito · Privacidad del consumidor · Móvil
Caso de éxito LiMP VPN: cómo lanzamos una VPN de consumo en producción (App Store y Google Play, en servicio en Estados Unidos y la Unión Europea) basada en WireGuard, con un plano de control sin registros, conexión con un toque y una arquitectura preparada para auditoría que resiste el escrutinio del RGPD y la CCPA desde el primer día.
El equipo de producto de LiMP quería una VPN de consumo que no pareciera un retroceso a 2015, con un icono pesado en la bandeja y un ritual de conexión de 90 segundos. La idea clave era que el comprador actual de privacidad de consumo en Estados Unidos y la Unión Europea no se conforma con el cifrado: quiere una política sin registros defendible, una conexión con un toque que termine en menos de un segundo y un mapa de servidores que realmente pueda entender. Los SDK de VPN en marca blanca existentes fallaban de inmediato dos pruebas de aceptación: sus paquetes inflaban el IPA y el APK por encima de los umbrales de instalación por red móvil de App Store, y sus configuraciones de registro por defecto no podían superar una revisión de privacidad independiente. Creamos LiMP desde cero como aplicación nativa para iOS y Android: un cliente ligero construido sobre el protocolo WireGuard, un plano de control en Go con una separación estricta entre la identidad de facturación y la identidad del túnel, y una flota de servidores que funciona en modo solo RAM, de modo que la incautación de un nodo no arroja ningún estado persistente. El resultado es una VPN de consumo publicada en App Store y Google Play, disponible en limpvpn.com y orientada a públicos de EE. UU. y la UE según las expectativas del RGPD y la CCPA desde el primer día.
Un resumen de lo que aportó el desarrollo de LiMP en iOS, Android y un plano de control reforzado en su primer ciclo de producción.
La elección del protocolo domina todas las demás decisiones de arquitectura en el desarrollo de una VPN. Elegimos WireGuard frente a OpenVPN e IKEv2 porque las contrapartidas encajan limpiamente con un producto de consumo nuevo de la era de 2024. La implementación de referencia de WireGuard tiene unas 4,000 líneas de código con un único conjunto criptográfico moderno (Curve25519 para el intercambio de claves, ChaCha20-Poly1305 para el cifrado simétrico y BLAKE2s para el hash) y es auditable en una sola tarde. OpenVPN, en cambio, es una base de código mucho mayor, con conjuntos de cifrado negociados y una superficie de ataque más extensa sobre la que debe razonar cualquier afirmación honesta de ausencia de registros. IKEv2 es maduro y cuenta con buen soporte nativo en iOS, pero su semántica de reanudación de sesión en dispositivos con itinerancia es más ruidosa que el modelo de claves de sesión de WireGuard, diseñado precisamente para los cambios de operadora que los usuarios móviles viven a diario.
Los stacks de VPN propietarios, como los que vienen incluidos en los SDK de marca blanca, se descartaron pronto: sus condiciones de licencia exigían telemetría en el servidor que el enfoque sin registros no puede tolerar, y sus primitivas criptográficas suelen estar sin documentar. Optar por el protocolo del whitepaper de WireGuard significó que todo el stack (túnel del cliente, plano de control, rotación de claves) es abierto y citable de extremo a extremo.
| Criterio | WireGuard (LiMP) | OpenVPN | IKEv2 / propietario |
|---|---|---|---|
| Tamaño del código del protocolo | ~4,000 líneas: auditable de una sola vez | ~70,000+ líneas, incluida la superficie de OpenSSL | Stack grande del SO o binario del proveedor |
| Conjunto criptográfico | Primitivas modernas fijas: Curve25519, ChaCha20-Poly1305, BLAKE2s | Negociado: superficie de ataque más amplia | Definido por el proveedor; a menudo opaco |
| Latencia del handshake (típica) | Menos de 100 ms en LTE móvil | Cientos de ms: handshake TLS más establecimiento del túnel | Variable; IKEv2 rápido, el propietario varía |
| Comportamiento en itinerancia | Integrado mediante claves de sesión, sin reinicio del túnel | Requiere reiniciar el túnel al cambiar de red | MOBIKE en IKEv2; el propietario varía |
| Integración con el kernel (Linux) | En la rama principal desde la 5.6: rendimiento a velocidad de línea | En espacio de usuario: más lento con alto rendimiento | Mixto kernel/espacio de usuario |
| Adecuación a App Store / Play Store | Envoltorio ligero sobre NetworkExtension / VpnService | Paquete mayor; dependencias en espacio de usuario | IKEv2 encaja de forma nativa; el SDK propietario añade volumen |
| Auditabilidad de la ausencia de registros | Túnel sin estado: la configuración del peer es el único estado | Estado por sesión: hay que suprimirlo activamente | Controlado por el proveedor: opaco |
Referencias del protocolo: whitepaper de WireGuard (Donenfeld), documentación de NetworkExtension de Apple, referencia de VpnService de Android.
El cliente de iOS está desarrollado en Swift, con SwiftUI para la capa de interfaz y una extensión Packet Tunnel Provider basada en el framework NetworkExtension de Apple. Toda la superficie visible para el usuario se reduce a una única máquina de estados (inactivo, conectando, conectado, reconectando) y la pantalla de inicio es un gran botón táctil que la controla. La selección de región queda a un toque del botón de conexión, con una lista ordenada por latencia y almacenada en caché local para que el selector nunca se bloquee esperando a la red. El Packet Tunnel Provider aloja la implementación de WireGuard en espacio de usuario; el proceso principal de la app solo gestiona la interfaz, el estado de facturación y el puente IPC hacia la extensión.
El camino de «tocar para conectar» es donde la mayoría de las VPN de consumo pierden tiempo, y donde dedicamos un esfuerzo de ingeniería desproporcionado. El flujo es: tocar, validar el token de sesión en caché (sin llamada a la red si es válido), levantar el Packet Tunnel Provider, entregarle la configuración del peer a través del puente NETunnelProviderProtocol y dejar que se complete el handshake de WireGuard. En las redes móviles habituales de EE. UU. y la UE, el recorrido completo se resuelve en menos de un segundo desde la perspectiva del usuario. El mismo cliente de iOS incorpora el comportamiento de kill switch que espera el revisor de App Store: cuando el túnel se cae, todo el tráfico fuera del túnel se bloquea en la capa NetworkExtension hasta que el usuario se desconecta de forma explícita. La superficie completa de iOS se entrega como parte de nuestra práctica de desarrollo de aplicaciones móviles.
El cliente de Android está escrito en Kotlin, con Jetpack Compose para la interfaz y un servicio en primer plano basado en la API VpnService de Android. El servicio en primer plano es obligatorio: en las familias de dispositivos Samsung, Xiaomi, OnePlus y Pixel, los optimizadores de batería agresivos terminan en pocos minutos los procesos de túnel que solo se ejecutan en segundo plano, rompiendo el contrato de reconexión automática al que el usuario se suscribe de forma implícita. El servicio muestra una notificación persistente mínima que mantiene vivo el proceso del túnel durante los ciclos del modo Doze, y WorkManager se encarga de las operaciones no urgentes (actualización de la lista de servidores, vaciado de contadores de telemetría, rotación de certificados) con una semántica de retroceso que respeta los estados de ahorro de batería desde Android 10 hasta Android 14.
El mapa de servidores es donde el cliente de Android demuestra su valor. Los usuarios ven una lista seleccionada de regiones en Países Bajos, Alemania, Francia, Suecia, Irlanda y las costas este y oeste de EE. UU., con sondeos de RTT en vivo que se actualizan en segundo plano y una lista de favoritos fijada arriba. El motor de recomendación se ejecuta en el cliente: cuando el patrón de tráfico DNS del dispositivo parece de streaming intensivo, el mapa muestra primero los nodos optimizados para rendimiento; cuando domina la latencia (juegos, videollamadas), suben los nodos de RTT bajo. Tras un cambio de Wi-Fi a LTE, el cliente restaura automáticamente el último nodo que funcionaba: el modelo de itinerancia de WireGuard hace que sea un intercambio de claves de sesión y no una reconstrucción completa del túnel. El mismo equipo de ingeniería se ocupa de iOS y Android en paralelo dentro de nuestra práctica de ingeniería para iOS y Android.
El enfoque sin registros declarado por LiMP fue una decisión de arquitectura antes que una afirmación de marketing. Los nodos VPN de borde, las máquinas que realmente transportan los paquetes de los usuarios, funcionan en modo solo RAM: su sistema de archivos raíz es una superposición efímera, y un reinicio o una incautación no arroja ningún estado de sesión persistente. El plano de control en Go reside en un plano reforzado aparte y guarda solo lo imprescindible: claves públicas de los peers, derechos de la suscripción y una vista de capacidad por región basada únicamente en contadores. No hay tabla de sesiones por usuario, ni registro de conexiones, ni canal de metadatos hacia un stack de observabilidad centralizado. Los contadores se agregan en el borde y se envían como series numéricas anónimas; los identificadores no salen del nodo.
La identidad de facturación se separa deliberadamente de la identidad del túnel. Los registros de pago residen en la bóveda de Stripe bajo un ID de cliente que los nodos VPN nunca ven; los nodos solo reciben tokens de sesión de corta duración que se asocian de forma opaca a los derechos de la suscripción. Las políticas de infraestructura como código hacen cumplir las invariantes de ausencia de registros: cualquier pull request que introduzca un registro de sesión, una traza por usuario o un identificador de larga duración en el plano del túnel falla en CI. El enfoque está diseñado para alinearse con las obligaciones del RGPD para los usuarios de la Unión Europea y con las obligaciones de la CCPA / CPRA para los usuarios de California y del resto de Estados Unidos, y para que una futura revisión independiente de preparación de la ausencia de registros sea un ejercicio de documentación y no una reforma de la arquitectura.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Un desarrollo en cinco fases que llevó a LiMP desde la especificación del producto hasta producción en iOS, Android y un plano de control sin registros.
Modelo de amenazas (de quién se defiende el usuario: ISP, anunciantes, atacantes de wifi público), invariantes de ausencia de registros, mapa del enfoque del RGPD y la CCPA, y revisión de los permisos de VPN en App Store y Google Play.
Selección del protocolo WireGuard, esqueleto del plano de control en Go, generación de la configuración de peers, política de rotación de claves, identidad de facturación aislada en Stripe e imágenes de nodos de borde solo RAM.
Cliente de iOS en Swift / SwiftUI sobre NetworkExtension Packet Tunnel Provider; cliente de Android en Kotlin / Jetpack Compose sobre VpnService; conexión con un toque, kill switch y reconexión automática.
Políticas de infraestructura como código que bloquean regresiones de registro, aprovisionamiento de nodos solo RAM, QA de kill switch y de fugas de DNS, y estructura base de la evaluación de preparación por terceros.
Envío a App Store y Google Play en las tiendas de EE. UU. y la UE, y despliegue de la flota de servidores en Países Bajos, Alemania, Francia, Suecia, Irlanda y la costa este / oeste de EE. UU.
La capa de monetización de LiMP se construyó para mantener demostrablemente separadas la identidad de pago y la identidad del túnel, porque la afirmación de ausencia de registros se derrumba en cuanto una única base de datos une un ID de cliente de Stripe con un token de sesión. El nivel de suscripción se vende a través de Apple StoreKit en iOS, Google Play Billing en Android y Stripe para el pago web, que devuelve un código de derechos a los clientes móviles. La validación de recibos en el servidor se ejecuta contra el endpoint de verificación de cada tienda y escribe un único registro de derechos, identificado por un identificador opaco y rotado, nunca por Apple ID, cuenta de Google ni dirección de correo electrónico. Dentro de los nodos VPN, lo único visible es un token bearer de corta duración que se asocia a los derechos y caduca con rapidez; el nodo no tiene ningún camino de vuelta a una identidad de pago, ni siquiera si se ve comprometido. El comportamiento del kill switch, la reconexión automática al cambiar de red y la selección de split tunneling por app (Android) leen del mismo registro de derechos, de modo que un único estado de suscripción se resuelve limpiamente tras reinstalaciones, cambios de dispositivo y el futuro cliente de escritorio. Todo el subsistema se diseñó pensando en la extensibilidad: añadir un plan familiar, derechos multidispositivo o un nivel B2B con gestión de equipos es un cambio de configuración en el servicio de derechos, no una publicación de código.
LiMP se lanzó en Apple App Store y Google Play con fichas activas en Estados Unidos y en la Unión Europea. La versión en inglés atiende a usuarios de California, Nueva York, Texas, Florida y Washington en EE. UU., y a usuarios de Países Bajos, Alemania, Francia, Irlanda y Suecia en la UE, sin una base de código distinta por región. Los flujos de consentimiento dependen de la región en la capa del cliente: los usuarios de la UE y del EEE reciben una pantalla de consentimiento granular al estilo del RGPD, con interruptores separados para cualquier analítica de producto opcional; los usuarios de California reciben en el mismo flujo un aviso al estilo de la CCPA, «No vender ni compartir mi información personal». Las prácticas de tratamiento de datos están alineadas con el RGPD para los usuarios europeos y con el mosaico de normas estatales de privacidad de EE. UU.: CCPA/CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) y la CPA de Oregón. Como la arquitectura sin registros elimina los datos por usuario que más preocupan a ese mosaico de normas, el cumplimiento regional se reduce a una divulgación honesta y no a una segregación de datos por jurisdicción.
La flota de servidores se desplegó en paralelo en centros de datos de la UE y de EE. UU. (Países Bajos, Alemania, Francia, Suecia e Irlanda para la cobertura de la UE; costa este y costa oeste de EE. UU. para Norteamérica), con los nodos de cada región aprovisionados de forma idéntica a partir de imágenes solo RAM. El servicio de emparejamiento que elige el nodo de menor RTT para cada usuario ejecuta workers sin estado que pueden fijarse de forma independiente a regiones de la UE o de EE. UU. para futuros compromisos de residencia de datos. Tanto la clasificación por edades de App Store como la clasificación de contenido de Google Play se calibraron para el conjunto de funciones de la VPN, y la política de privacidad dentro de la app se redactó para documentar exactamente la arquitectura descrita, citando directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. El equipo de ingeniería que está detrás del desarrollo está repartido en la zona CET y trabaja con una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para las reuniones diarias, la coordinación de las revisiones de las tiendas y la respuesta a incidencias: la franja horaria que permite a un equipo de producto estadounidense y a un equipo de ingeniería europeo compartir cuatro horas de solapamiento en directo cada día.
La hoja de ruta activa de desarrollo de software a medida de LiMP incluye split tunneling por app en Android (primero Pixel y Samsung), un nivel de relé MultiHop para usuarios que quieren un segundo salto en otra jurisdicción, un transporte con ofuscación para redes restrictivas donde se bloquean los handshakes de WireGuard estándar y un cliente de escritorio creado con Tauri para compartir lógica de negocio con la base de código móvil. Está previsto un nivel B2B con dominio propio, gestión de equipos y SSO para pequeñas empresas de EE. UU. y la UE, con el subsistema de derechos ya estructurado para la asignación a varios usuarios. Los planes de infraestructura incluyen más automatización de la flota de servidores, un banco de pruebas interno de verificación continua de la ausencia de registros y una futura evaluación independiente de preparación integrada en la hoja de ruta de cloud y DevOps.
Si está planificando una VPN de consumo, un producto de ingeniería de la privacidad o cualquier app móvil en la que la afirmación de ausencia de registros deba superar a un revisor externo para públicos de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma significativa el plazo de desarrollo. El producto en servicio está disponible en limpvpn.com para iOS y Android, y el equipo de ingeniería que lo desarrolló forma parte de YuSMP Group. Trabajamos a precio cerrado para MVP bien acotados y con equipos de desarrollo dedicados para la entrega continua, con una jornada CET y una franja garantizada de solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias, demos y respuesta a incidencias.
Casos relacionados
Marketplace PropTech y administración para promotoras residenciales: cuadrículas de inventario a nivel de vivienda, flujos multirol y residencia de datos en EE. UU. y la UE.
Ver el caso →
Plataforma social nativa para iOS + Android con descubrimiento por geo-radar, chat en tiempo real y una economía de monedas virtuales en EE. UU. y la UE.
Ver el caso →
Herramientas digitales empresariales para un fabricante multinacional: portales de partners, configuradores y despliegue en la UE y EE. UU.
Ver el caso →
Apps nativas para iOS y Android y multiplataforma, con pipelines de publicación listos para las tiendas.
Más información →
Plataformas a medida diseñadas para su modelo de negocio, que escalan sin problemas desde el MVP hasta millones de usuarios.
Más información →
Ingenieros sénior integrados en su Jira y en sus standups en dos semanas. Jornada CET con solapamiento con la costa este de EE. UU.
Más información →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.