Er iPhone på ein VPN? Kva ein iOS-app faktisk kan sjå

Spør ein iOS-app om telefonen er på eit VPN, og det ærlege svaret er at han ikkje kan vite det slik du meiner. SDK-et viser ikkje noko flagg for «eininga er i ein tunnel», og dei private grensesnitta som kunne nærme seg det, er lukka for apper som blir publiserte. Du kan observere konfigurasjonen til appen din, tilstanden som heng på han, og eitt eller to indirekte hint frå nettverksstakken. Kvar av dei svarer på eit ulikt spørsmål, og dei fleste øydelagde sjekkane kjem av å ta ein av dei som heile svaret.

Myten om det eine VPN-flagget

Førestillinga er at det ein stad i SDK-et finst ein eigenskap som rapporterer om eininga er i ein tunnel, slik eit tilgjengelegheitsflagg rapporterer om ein vert svarar. Ein slik offentleg eigenskap finst ikkje. Og sjølv om han gjorde det, er «det finst ein tunnel» og «trafikken min brukar han» ulike påstandar, og for dei fleste apper er berre den andre viktig.

Nettopp dette gapet er grunnen til at bibliotek som annonserer med ein éinlinjes VPN-detektor, ofte les noko skjørt, som eit grensesnittnamn eller ein proxy-nøkkel, og presenterer det som ein dom.

Last inn innstillingane før du stolar på ein nil

Den delte manager-instansen finst så snart du ber om han, men protokoll-eigenskapen blir verande nil til last-callbacken er ferdig. Ein nil-protokoll tyder altså «ikkje lasta enno» minst like ofte som «ikkje installert». Gjer lesinga inne i fullføringsblokka, og avgjer først etterpå: eit protokollobjekt som finst, med aktiveringsflagget på, er korleis «installert» ser ut.

Eit andre signal sit på tilkoplingsboksen: den ugyldige tilstanden, som systemet rapporterer når denne appen ikkje har nokon installert konfigurasjon. Ugyldig tilstand saman med ein nil-protokoll etter ei fullført innlasting er eit reelt fråvær, ikkje eit tidskapplaup.

Tilkoplingsendringar kjem som varsel

Handsamarane som blir gjevne til load og save, rapporterer kva som skjedde med konfigurasjonen, ikkje kva tunnelen gjer. Å vente på at ein av dei blir utløyst ved tilkopling er eit kapplaup som aldri blir løyst. Følg i staden varselet om statusendring, og les gjeldande verdi av tilkoplingsboksen når det kjem.

Når ein konfigurasjon er installert, går tilkoplingsstatusen gjennom ein kort sekvens: fråkopla, koplar til, tilkopla, stadfester på nytt, koplar frå. «Tilkopla» skildrar tunnelen og ikkje tenaren bak han, så det er ikkje prov på at trafikk flyt. On-demand kan også reise ein tunnel medan appen er suspendert, og då kjem varselet før du har noko å oppdatere.

Det avgrensa proxy-augneblinksbiletet er eit hint, ikkje ein dom

CFNetwork kan gje appen dei gjeldande systeminnstillingane for proxy, og inne i det resultatet ligg ei avgrensa ordbok med nøkkel etter grensesnittnamn. Å sjå eit namn som byrjar med tun, utun, ppp, ipsec eller tap er eit hint om at ein tunnel finst. Det er framleis eit augneblinksbilete av kva denne appen kan sjå, ikkje ei utsegn om kvar pakkane reiser.

Leverandørar er usamde om namngjeving, så eit manglande prefiks provar ingenting, og eit grensesnitt som finst kan eksistere utan å føre trafikk. Tilgjenge er endå svakare: ein vellukka førespurnad til ei privat adresse viser at vegen virka for den førespurnaden i det augneblinket, ikkje at eit VPN er installert.

Simulatoren låner Macen, og andre apper blir verande usynlege

Simulatoren har ingen eigen nettverksstakk; kvar tilkopling han gjer, er Macen sin. Eit VPN som køyrer på verts-Macen er difor allereie i kraft for den simulerte appen, og innstillingane til simulatoren sjølv viser ingenting. Viss tunnelen kom opp etter at simulatoren starta, er det vanlegvis raskare å starte han på nytt enn å feilsøkje appen. Ein vert på ein ikkje-standard port treng den porten i URL-en, eller ei lokal vidaresending som socat TCP-LISTEN:12345,fork TCP:host:12345.

Offentlege API-ar vil ikkje liste opp VPN-profilane som høyrer til andre apper eller konfigurasjonsprofilar. For éin kjend app er ein URL-skjema-test gjennom canOpenURL det portable trikset, og sidan iOS 9 må skjemaet det blir spurt om, deklarerast i Info.plist-en din; utelèt du det, returnerer kallet false. OpenVPN Connect svarar på openvpn://, noko som gjer det til eit godt døme og ein dårleg generell detektor.

Kombiner tre observasjonar og seie kva dei tyder

Stapl tre resultat i praksis: ein konfigurasjon som vart lasta og er aktivert, ein tilkoplingsstatus som ikkje er ugyldig, og ein førespurnad til ei adresse som berre er nåbar gjennom tunnelen. Kvar for seg villeder dei; saman seier dei kva appen kan vite, i staden for kva brukaren føreset.

Skriv resultatet som tre linjer i diagnostikken din, ikkje som éin boolean. Når ein brukar seier at VPN-en er av medan appen din er usamd, viser dei tre linjene kva observasjon som avveik, og det er skilnaden mellom ein støttebillett du kan handle på og ein som endar med «hos meg verkar det».