L'iPhone és en una VPN? Què pot veure realment una app d'iOS

Pregunteu a una app d'iOS si el telèfon és en una VPN i la resposta honesta és que no ho pot saber tal com ho enteneu. L'SDK no exposa cap indicador de «el dispositiu és en un túnel», i les interfícies privades que podrien aproximar-s'hi estan tancades per a les apps que es publiquen. Podeu observar la configuració de la vostra pròpia app, l'estat que hi va lligat i un o dos indicis indirectes de la pila de xarxa. Cadascun respon una pregunta diferent, i la majoria de comprovacions espatllades vénen de prendre'n un com la resposta sencera.

El mite de l'indicador únic de VPN

La creença és que en algun lloc de l'SDK hi ha una propietat que informa si el dispositiu és en un túnel, tal com un indicador d'abastabilitat informa si un amfitrió respon. Aquesta propietat pública no existeix. I encara que existís, «hi ha un túnel» i «el meu trànsit l'utilitza» són afirmacions diferents, i només la segona importa a la majoria d'apps.

Aquest buit és la raó per la qual les biblioteques que anuncien un detector de VPN d'una línia solen llegir una cosa fràgil, com un nom d'interfície o una clau de proxy, i presentar-ho com un veredicte.

Carregueu les preferències abans de confiar en un nil

La instància compartida del gestor existeix tan bon punt la demaneu, però la seva propietat de protocol es queda en nil fins que es completa la crida de càrrega. Així, un protocol nil vol dir «encara no carregat» com a mínim tan sovint com «no instal·lat». Feu la lectura dins del bloc de compleció i només després decidiu: un objecte de protocol que existeix, amb l'indicador d'habilitació activat, és com es veu «instal·lat».

Un segon senyal és a l'objecte de connexió: l'estat no vàlid, que el sistema informa quan aquesta app no té cap configuració instal·lada. Un estat no vàlid juntament amb un protocol nil després d'una càrrega completada és una absència real, no una cursa de temps.

Els canvis de connexió arriben com a notificacions

Els gestors que es passen a load i save informen què ha passat a la configuració, no què fa el túnel. Esperar que un d'ells s'activi en connectar és una cursa que no es resol mai. Mireu en canvi la notificació de canvi d'estat i llegiu el valor actual de l'objecte de connexió quan arriba.

Un cop instal·lada una configuració, l'estat de connexió recorre una seqüència curta: desconnectat, connectant, connectat, reafirmant, desconnectant. «Connectat» descriu el túnel i no el servidor que hi ha darrere, així que no és prova que el trànsit flueixi. On-demand també pot aixecar un túnel mentre l'app està suspesa, i llavors la notificació arriba abans que tingueu res per actualitzar.

La instantània de proxy d'abast limitat és un indici, no un veredicte

CFNetwork pot donar a l'app la configuració de proxy actual del sistema, i dins d'aquest resultat hi ha un diccionari d'abast limitat amb clau pel nom d'interfície. Veure un nom que comença amb tun, utun, ppp, ipsec o tap és un indici que hi ha un túnel. Segueix sent una instantània del que aquesta app pot veure, no una afirmació sobre on viatgen els paquets.

Els proveïdors no es posen d'acord en els noms, així que un prefix absent no demostra res, i una interfície present pot existir sense portar cap trànsit. L'abastabilitat encara és més feble: una petició correcta a una adreça privada mostra que el camí va funcionar per a aquella petició en aquell moment, no que hi hagi una VPN instal·lada.

El simulador agafa el Mac, i les altres apps queden invisibles

El simulador no té pila de xarxa pròpia; cada connexió que fa és la del Mac. Per tant, una VPN que corre al Mac amfitrió ja està en efecte per a l'app simulada, i la configuració del simulador no mostra res. Si el túnel es va aixecar després d'iniciar el simulador, reiniciar-lo sol ser més ràpid que depurar l'app. Un amfitrió en un port no estàndard necessita aquest port a l'URL, o una redirecció local com socat TCP-LISTEN:12345,fork TCP:host:12345.

Les API públiques no enumeraran perfils de VPN que pertanyen a altres apps o a perfils de configuració. Per a una app coneguda, la prova d'esquema d'URL mitjançant canOpenURL és el truc portable, i des d'iOS 9 l'esquema consultat s'ha de declarar a l'Info.plist; si l'ometeu, la crida retorna false. OpenVPN Connect respon a openvpn://, cosa que en fa un bon exemple i un mal detector general.

Combineu tres observacions i digueu què signifiquen

Apileu tres resultats a la pràctica: una configuració que s'ha carregat i està habilitada, un estat de connexió que no és no vàlid i una petició a una adreça només abastable pel túnel. Cadascun enganya per si sol; junts diuen què pot saber l'app en lloc de què suposa l'usuari.

Escriviu el resultat com a tres línies als vostres diagnòstics, no com un sol booleà. Quan un usuari diu que la VPN està desactivada i la vostra app no hi està d'acord, les tres línies mostren quina observació ha divergit, i aquesta és la diferència entre un tiquet de suport sobre el qual podeu actuar i un que acaba amb «a mi em funciona».