Er iPhone på en VPN? Hva en iOS-app faktisk kan se

Spør en iOS-app om telefonen er på en VPN, og det ærlige svaret er at den ikke kan vite det slik du mener. SDK-et eksponerer ingen flagg for «enheten er i en tunnel», og de private grensesnittene som kunne nærme seg det, er lukket for apper som publiseres. Du kan observere appens egen konfigurasjon, tilstanden som henger på den, og ett eller to indirekte hint fra nettverksstakken. Hver av dem svarer på et ulikt spørsmål, og de fleste ødelagte sjekkene kommer av å ta en av dem som hele svaret.

Myten om det ene VPN-flagget

Forestillingen er at det et sted i SDK-et finnes en egenskap som rapporterer om enheten er i en tunnel, slik et tilgjengelighetsflagg rapporterer om en vert svarer. En slik offentlig egenskap finnes ikke. Og selv om den gjorde det, er «det finnes en tunnel» og «trafikken min bruker den» forskjellige påstander, og for de fleste apper er bare den andre viktig.

Nettopp dette gapet er grunnen til at biblioteker som annonserer med en éenlinjes VPN-detektor, ofte leser noe skjørt, som et grensesnittnavn eller en proxy-nøkkel, og presenterer det som en dom.

Last inn innstillingene før du stoler på en nil

Den delte manager-instansen finnes så snart du ber om den, men protokoll-egenskapen forblir nil til last-callbacken er ferdig. En nil-protokoll betyr altså «ikke lastet ennå» minst like ofte som «ikke installert». Gjør lesingen inne i fullføringsblokken, og avgjør først etterpå: et protokollobjekt som finnes, med aktiveringsflagget på, er hvordan «installert» ser ut.

Et andre signal sitter på tilkoblingsobjektet: den ugyldige tilstanden, som systemet rapporterer når denne appen ikke har noen installert konfigurasjon. Ugyldig tilstand sammen med en nil-protokoll etter en fullført innlasting er en reell fravær, ikke et tidskappløp.

Tilkoblingsendringer kommer som varsler

Handlerne som gis til load og save, rapporterer hva som skjedde med konfigurasjonen, ikke hva tunnelen gjør. Å vente på at en av dem utløses ved tilkobling er et kappløp som aldri løses. Følg i stedet varselet om statusendring, og les tilkoblingsobjektets gjeldende verdi når det kommer.

Når en konfigurasjon er installert, går tilkoblingstilstanden gjennom en kort sekvens: frakoblet, kobler til, tilkoblet, bekrefter på nytt, kobler fra. «Tilkoblet» beskriver tunnelen og ikke serveren bak den, så det er ikke bevis for at trafikk flyter. On-demand kan også reise en tunnel mens appen er suspendert, og da kommer varselet før du har noe å oppdatere.

Det begrensede proxy-øyeblikksbildet er et hint, ikke en dom

CFNetwork kan gi appen systemets gjeldende proxy-innstillinger, og inne i det resultatet ligger en begrenset ordbok med nøkkel etter grensesnittnavn. Å se et navn som begynner med tun, utun, ppp, ipsec eller tap er et hint om at en tunnel finnes. Det er fortsatt et øyeblikksbilde av hva denne appen kan se, ikke en uttalelse om hvor pakkene reiser.

Leverandører er uenige om navngiving, så et manglende prefiks beviser ingenting, og et grensesnitt som finnes kan eksistere uten å føre trafikk. Tilgjengelighet er enda svakere: en vellykket forespørsel til en privat adresse viser at veien virket for den forespørselen i det øyeblikket, ikke at en VPN er installert.

Simulatoren låner Macen, og andre apper forblir usynlige

Simulatoren har ingen egen nettverksstakk; hver tilkobling den gjør, er Macens. En VPN som kjører på verts-Macen er derfor allerede i kraft for den simulerte appen, og simulatorens egne innstillinger viser ingenting. Hvis tunnelen kom opp etter at simulatoren startet, er det vanligvis raskere å starte den på nytt enn å feilsøke appen. En vert på en ikke-standard port trenger den porten i URL-en, eller en lokal videresending som socat TCP-LISTEN:12345,fork TCP:host:12345.

Offentlige API-er vil ikke liste opp VPN-profiler som tilhører andre apper eller konfigurasjonsprofiler. For én kjent app er en URL-skjema-test gjennom canOpenURL det portable trikset, og siden iOS 9 må skjemaet som spørres om, deklareres i Info.plist-en din; utelater du det, returnerer kallet false. OpenVPN Connect svarer på openvpn://, noe som gjør det til et godt eksempel og en dårlig generell detektor.

Kombiner tre observasjoner og si hva de betyr

Stabl tre resultater i praksis: en konfigurasjon som ble lastet og er aktivert, en tilkoblingstilstand som ikke er ugyldig, og en forespørsel til en adresse som bare kan nås gjennom tunnelen. Hver for seg villeder de; sammen sier de hva appen kan vite, i stedet for hva brukeren antar.

Skriv resultatet som tre linjer i diagnostikken din, ikke som én boolean. Når en bruker sier at VPN-en er av mens appen din er uenig, viser de tre linjene hvilken observasjon som avvek, og det er forskjellen mellom en støttebillett du kan handle på og en som ender med «hos meg virker det».