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

Spørg en iOS-app, om telefonen er på en VPN, og det ærlige svar er, at den ikke kan vide det på den måde, du mener. SDK'et udstiller ingen flag for «enheden er i en tunnel», og de private grænseflader, der måske kunne nærme sig det, er lukkede for apps, der udgives. Du kan iagttage din apps egen konfiguration, den tilstand der hænger på den, og et eller to indirekte vink fra netværksstakken. Hver især svarer de på et forskelligt spørgsmål, og de fleste brudte tjek kommer af at tage et af dem som hele svaret.

Myten om det enkelte VPN-flag

Forestillingen er, at der et sted i SDK'et findes en egenskab, der rapporterer, om enheden er i en tunnel, ligesom et tilgængelighedsflag rapporterer, om en vært svarer. En sådan offentlig egenskab findes ikke. Selv hvis den gjorde, er «der findes en tunnel» og «min trafik bruger den» forskellige påstande, og kun den anden betyder noget for de fleste apps.

Det hul er grunden til, at biblioteker, der annoncerer med en éenlinjes VPN-detektor, typisk læser noget skrøbeligt, som et grænsefladenavn eller en proxy-nøgle, og præsenterer det som en dom.

Indlæs præferencerne, før du stoler på en nil

Den delte manager-instans findes, så snart du beder om den, men dens protokol-egenskab forbliver nil, indtil load-callbacken er færdig. Så en nil-protokol betyder «ikke indlæst endnu» mindst lige så ofte, som den betyder «ikke installeret». Udfør læsningen inde i completion-blokken, og beslut først derefter: et protokolobjekt, der findes, med enable-flaget slået til, er, hvordan «installeret» ser ud.

Et andet signal sidder på connection-objektet: den ugyldige tilstand, som systemet rapporterer, når denne app ikke har nogen konfiguration installeret. Ugyldig status sammen med en nil-protokol efter en fuldført indlæsning er en ægte fravær, ikke et tidskapløb.

Forbindelsesændringer kommer som notifikationer

Handlere, der gives til load og save, rapporterer, hvad der skete med konfigurationen, ikke hvad tunnelen gør. At vente på, at en af dem udløses ved forbindelse, er et kapløb, der aldrig løses. Hold øje med notifikationen om statusændring i stedet, og læs connection-objektets aktuelle værdi, når den kommer.

Når en konfiguration er installeret, går forbindelsestilstanden gennem en kort sekvens: afbrudt, forbinder, forbundet, genbekræfter, afbryder. «Forbundet» beskriver tunnelen og ikke serveren bag den, så det er ikke bevis for, at trafik flyder. On-demand kan også rejse en tunnel, mens appen er suspenderet, og så lander notifikationen, før du har noget at opdatere.

Det begrænsede proxy-øjebliksbillede er et vink, ikke en dom

CFNetwork kan give appen systemets aktuelle proxy-indstillinger, og inde i det resultat er en begrænset ordbog med nøgle efter grænsefladenavn. At se et navn, der begynder med tun, utun, ppp, ipsec eller tap, er et vink om, at en tunnel er til stede. Det er stadig et øjebliksbillede af, hvad denne app kan se, ikke en udtalelse om, hvor pakker rejser hen.

Udbydere er uenige om navngivning, så et manglende præfiks beviser intet, og en tilstedeværende grænseflade kan findes uden at føre trafik. Tilgængelighed er endnu svagere: en vellykket anmodning til en privat adresse viser, at vejen virkede for den anmodning i det øjeblik, ikke at en VPN er installeret.

Simulatoren låner Mac'en, og andre apps forbliver usynlige

Simulatoren har ingen egen netværksstak; hver forbindelse, den laver, er Mac'ens. En VPN, der kører på værts-Mac'en, er derfor allerede i kraft for den simulerede app, og simulatorens egne indstillinger viser intet. Hvis tunnelen kom op, efter simulatoren startede, er det normalt hurtigere at genstarte den end at fejlfinde appen. En vært på en ikke-standardport har brug for den port i URL'en eller en lokal videresendelse som socat TCP-LISTEN:12345,fork TCP:host:12345.

Offentlige API'er vil ikke opregne VPN-profiler, der tilhører andre apps eller konfigurationsprofiler. For én kendt app er en URL-skema-probe gennem canOpenURL det portable trick, og siden iOS 9 skal det forespurgte skema være deklareret i din Info.plist; udelader du det, returnerer kaldet false. OpenVPN Connect svarer på openvpn://, hvilket gør det til et godt eksempel og en dårlig generel detektor.

Kombiner tre iagttagelser og sig, hvad de betyder

Stabl tre resultater i praksis: en konfiguration, der blev indlæst og er aktiveret, en forbindelsestilstand, der ikke er ugyldig, og en anmodning til en adresse, der kun kan nås gennem tunnelen. Hver især vildleder de alene; sammen siger de, hvad appen kan vide, i stedet for hvad brugeren antager.

Skriv resultatet som tre linjer i din diagnostik, ikke som én boolean. Når en bruger siger, at VPN'en er slået fra, mens din app er uenig, viser de tre linjer, hvilken iagttagelse der afveg, og det er forskellen mellem en supportbillet, du kan handle på, og en der ender med «det virker hos mig».