¿Está el iPhone en una VPN? Lo que una app de iOS puede ver de verdad

Pregunte a una app de iOS si el teléfono está en una VPN y la respuesta honesta es que no puede saberlo en el sentido que usted quiere. El SDK no expone ninguna bandera de «el dispositivo está en un túnel», y las interfaces privadas que podrían acercarse están cerradas para las apps que se publican. Puede observar la configuración de su propia app, el estado asociado a ella y uno o dos indicios indirectos de la pila de red. Cada uno responde a una pregunta distinta, y la mayoría de las comprobaciones rotas vienen de tomar uno de ellos como la respuesta completa.

El mito de la bandera única de VPN

La creencia es que en algún lugar del SDK hay una propiedad que informa de si el dispositivo está en un túnel, igual que una bandera de alcanzabilidad informa de si un host responde. Esa propiedad pública no existe. E incluso si existiera, «hay un túnel» y «mi tráfico lo usa» son afirmaciones distintas, y solo la segunda importa a la mayoría de las apps.

Ese hueco es la razón por la que las bibliotecas que anuncian un detector de VPN de una línea suelen leer algo frágil, como un nombre de interfaz o una clave de proxy, y presentarlo como un veredicto.

Cargue las preferencias antes de fiarse de un nil

La instancia compartida del gestor existe en cuanto la pide, pero su propiedad de protocolo sigue siendo nil hasta que termina la llamada de carga. Así que un protocolo nil significa «aún no cargado» al menos con la misma frecuencia que «no instalado». Haga la lectura dentro del bloque de finalización y solo entonces decida: un objeto de protocolo que existe, con la bandera de habilitación activada, es el aspecto de «instalado».

Una segunda señal está en el objeto de conexión: el estado no válido, que el sistema informa cuando esta app no tiene ninguna configuración instalada. Un estado no válido junto con un protocolo nil tras una carga completada es una ausencia real, no una carrera de tiempos.

Los cambios de conexión llegan como notificaciones

Los manejadores que se pasan a load y save informan de lo que ocurrió con la configuración, no de lo que hace el túnel. Esperar a que uno de ellos se dispare al conectar es una carrera que nunca se resuelve. Observe en su lugar la notificación de cambio de estado y lea el valor actual del objeto de conexión cuando llegue.

Una vez instalada una configuración, el estado de conexión recorre una secuencia corta: desconectado, conectando, conectado, reafirmando, desconectando. «Conectado» describe el túnel y no el servidor que hay detrás, así que no es prueba de que el tráfico fluya. On-demand también puede levantar un túnel mientras la app está suspendida, y entonces la notificación llega antes de que tenga nada que actualizar.

La instantánea de proxy con alcance limitado es un indicio, no un veredicto

CFNetwork puede dar a la app la configuración de proxy actual del sistema, y dentro de ese resultado hay un diccionario de alcance limitado con clave por nombre de interfaz. Ver un nombre que empieza por tun, utun, ppp, ipsec o tap es un indicio de que hay un túnel. Sigue siendo una instantánea de lo que esta app puede ver, no una afirmación sobre por dónde viajan los paquetes.

Los proveedores no se ponen de acuerdo en los nombres, así que un prefijo ausente no demuestra nada, y una interfaz presente puede existir sin llevar tráfico. La alcanzabilidad es aún más débil: una petición correcta a una dirección privada muestra que la ruta funcionó para esa petición en ese momento, no que haya una VPN instalada.

El simulador toma prestado el Mac, y las demás apps quedan invisibles

El simulador no tiene pila de red propia; cada conexión que hace es la del Mac. Por tanto, una VPN que corre en el Mac anfitrión ya está en vigor para la app simulada, y los ajustes del propio simulador no muestran nada. Si el túnel se levantó después de iniciar el simulador, reiniciarlo suele ser más rápido que depurar la app. Un anfitrión en un puerto no estándar necesita ese puerto en la URL, o una redirección local como socat TCP-LISTEN:12345,fork TCP:host:12345.

Las API públicas no enumerarán perfiles de VPN que pertenecen a otras apps o a perfiles de configuración. Para una app conocida, la prueba de esquema de URL mediante canOpenURL es el truco portátil, y desde iOS 9 el esquema consultado debe declararse en su Info.plist; si lo omite, la llamada devuelve false. OpenVPN Connect responde a openvpn://, lo que lo convierte en un buen ejemplo y un mal detector general.

Combine tres observaciones y diga qué significan

Apile tres resultados en la práctica: una configuración que se cargó y está habilitada, un estado de conexión que no es no válido y una petición a una dirección solo alcanzable por el túnel. Cada uno engaña por separado; juntos dicen lo que la app puede saber en lugar de lo que el usuario supone.

Escriba el resultado como tres líneas en sus diagnósticos, no como un solo booleano. Cuando un usuario dice que la VPN está desactivada mientras su app no está de acuerdo, las tres líneas muestran qué observación divergió, y esa es la diferencia entre un ticket de soporte sobre el que puede actuar y uno que termina en «a mí me funciona».