iPhone-ul este într-un VPN? Ce poate vedea cu adevărat o aplicație iOS

Întrebați o aplicație iOS dacă telefonul este într-un VPN, iar răspunsul onest este că nu poate ști acest lucru în sensul la care vă gândiți. SDK-ul nu expune niciun indicator pentru «dispozitivul este într-un tunel», iar interfețele private care s-ar putea apropia de asta sunt închise aplicațiilor publicate. Puteți observa configurația propriei aplicații, starea legată de ea și unul sau două indicii indirecte din stiva de rețea. Fiecare răspunde la o altă întrebare, iar majoritatea verificărilor stricate provin din a lua una dintre ele drept răspunsul complet.

Mitul indicatorului unic de VPN

Credința este că undeva în SDK există o proprietate care raportează dacă dispozitivul este într-un tunel, așa cum un indicator de accesibilitate raportează dacă un host răspunde. O astfel de proprietate publică nu există. Și chiar dacă ar exista, «există un tunel» și «traficul meu îl folosește» sunt afirmații diferite, iar pentru majoritatea aplicațiilor contează doar a doua.

Exact acest gol este motivul pentru care bibliotecile care promovează un detector de VPN de o singură linie citesc de obicei ceva fragil, cum ar fi un nume de interfață sau o cheie de proxy, și îl prezintă ca pe o sentință.

Încărcați preferințele înainte de a avea încredere într-un nil

Instanța partajată a managerului există imediat ce o cereți, dar proprietatea sa de protocol rămâne nil până când se termină apelul de încărcare. Deci un protocol nil înseamnă «încă neîncărcat» cel puțin la fel de des precum înseamnă «neinstalat». Faceți citirea în blocul de finalizare și abia apoi decideți: un obiect de protocol care există, cu indicatorul de activare pornit, așa arată «instalat».

Un al doilea semnal se află pe obiectul de conexiune: starea invalidă, pe care sistemul o raportează atunci când această aplicație nu are nicio configurație instalată. O stare invalidă împreună cu un protocol nil după o încărcare finalizată este o absență reală, nu o cursă de timp.

Modificările conexiunii sosesc ca notificări

Manipulatorii pasați la load și save raportează ce s-a întâmplat cu configurația, nu ce face tunelul. A aștepta ca unul dintre ei să se declanșeze la conectare este o cursă care nu se rezolvă niciodată. Urmăriți în schimb notificarea de schimbare a stării și citiți valoarea curentă a obiectului de conexiune când sosește.

După ce o configurație este instalată, starea conexiunii parcurge o secvență scurtă: deconectat, se conectează, conectat, reafirmă, se deconectează. «Conectat» descrie tunelul și nu serverul din spatele lui, deci nu este dovada că traficul curge. On-demand poate ridica un tunel și în timp ce aplicația este suspendată, iar atunci notificarea sosește înainte să aveți ce actualiza.

Imaginea limitată a proxy-ului este un indiciu, nu o sentință

CFNetwork poate oferi aplicației setările curente de proxy ale sistemului, iar în acel rezultat există un dicționar cu sferă limitată, cu cheie după numele interfeței. Un nume care începe cu tun, utun, ppp, ipsec sau tap este un indiciu că există un tunel. Rămâne o imagine a ceea ce poate vedea această aplicație, nu o afirmație despre unde călătoresc pachetele.

Furnizorii nu sunt de acord asupra denumirilor, așa că un prefix lipsă nu dovedește nimic, iar o interfață prezentă poate exista fără să transporte trafic. Accesibilitatea este și mai slabă: o cerere reușită către o adresă privată arată că ruta a funcționat pentru acea cerere în acel moment, nu că este instalat un VPN.

Simulatorul împrumută Mac-ul, iar celelalte aplicații rămân invizibile

Simulatorul nu are o stivă de rețea proprie; fiecare conexiune pe care o face este a Mac-ului. Așadar, un VPN care rulează pe Mac-ul gazdă este deja în vigoare pentru aplicația simulată, iar setările simulatorului însuși nu arată nimic. Dacă tunelul a urcat după pornirea simulatorului, repornirea lui este de obicei mai rapidă decât depanarea aplicației. Un host pe un port nestandard are nevoie de acel port în URL, sau de o redirecționare locală precum socat TCP-LISTEN:12345,fork TCP:host:12345.

API-urile publice nu vor enumera profiluri VPN care aparțin altor aplicații sau profilurilor de configurare. Pentru o aplicație cunoscută, sondarea schemei URL prin canOpenURL este trucul portabil, iar din iOS 9 schema interogată trebuie declarată în Info.plist; dacă o omiteți, apelul returnează false. OpenVPN Connect răspunde la openvpn://, ceea ce îl face un exemplu bun și un detector general slab.

Combinați trei observații și spuneți ce înseamnă

În practică stivuiți trei rezultate: o configurație care s-a încărcat și este activată, o stare de conexiune care nu este invalidă și o cerere către o adresă accesibilă doar prin tunel. Fiecare induce în eroare de unul singur; împreună spun ce poate ști aplicația, nu ce presupune utilizatorul.

Scrieți rezultatul ca trei rânduri în diagnosticările voastre, nu ca un singur boolean. Când un utilizator spune că VPN-ul este oprit iar aplicația voastră nu este de acord, cele trei rânduri arată care observație a divergat, iar aceasta este diferența dintre un tichet de suport pe care puteți acționa și unul care se termină cu «la mine funcționează».