VPN-en van az iPhone? Mit láthat valójában egy iOS-alkalmazás

Kérdezz meg egy iOS-alkalmazást, hogy a telefon VPN-en van-e, és az őszinte válasz az, hogy nem tudhatja úgy, ahogy te érted. Az SDK nem tesz közzé jelzőt arra, hogy «az eszköz alagútban van», és a privát interfészek, amelyek megközelíthetnék ezt, zárva vannak a kiadott alkalmazások előtt. Megfigyelheted az alkalmazás saját konfigurációját, a hozzá kapcsolt állapotot, és egy-két közvetett utalást a hálózati stackből. Mindegyik más kérdésre válaszol, és a legtöbb elromlott ellenőrzés abból fakad, hogy valamelyiket az egész válasznak tekintik.

Az egyetlen VPN-jelző mítosza

A hit az, hogy valahol az SDK-ban van egy tulajdonság, amely jelzi, hogy az eszköz alagútban van-e, ahogy az elérhetőségi jelző jelzi, hogy egy hoszt válaszol-e. Ilyen nyilvános tulajdonság nincs. És ha lenne is, «van alagút» és «az én forgalmam használja» különböző állítások, és a legtöbb alkalmazásnak csak a második számít.

Pont ez a szakadék az oka, hogy az egysoros VPN-detektort hirdető könyvtárak általában valami törékenyt olvasnak, például egy interfésznevet vagy egy proxykulcsot, és ítéletként mutatják be.

Töltsd be a beállításokat, mielőtt megbízol egy nilben

A megosztott kezelőpéldány létezik, amint kéred, de a protokoll-tulajdonsága nil marad, amíg a betöltési callback be nem fejeződik. A nil protokoll tehát «még nincs betöltve» jelentéssel legalább olyan gyakran bír, mint «nincs telepítve». A befejezési blokkon belül olvass, és csak utána dönts: egy létező protokoll-objektum, bekapcsolt engedélyezési jelzővel, így néz ki a «telepítve».

Egy második jel a kapcsolat-objektumon van: az érvénytelen állapot, amelyről a rendszer akkor számol be, ha ennek az alkalmazásnak nincs telepített konfigurációja. Érvénytelen állapot nil protokollal együtt egy befejezett betöltés után valódi hiány, nem időzítési verseny.

A kapcsolatváltozások értesítésként érkeznek

A load és save függvényeknek átadott kezelők arról számolnak be, mi történt a konfigurációval, nem arról, mit tesz az alagút. Megvárni, hogy valamelyikük a csatlakozáskor elsüljön, olyan verseny, amely soha nem oldódik meg. Figyeld inkább az állapotváltozási értesítést, és olvasd ki a kapcsolat-objektum aktuális értékét, amikor megérkezik.

Miután egy konfiguráció telepítve van, a kapcsolat állapota rövid sorozaton megy át: leválasztva, csatlakozik, csatlakozva, újraérvényesítés, leválasztás. A «csatlakozva» az alagutat írja le, nem a mögötte lévő szervert, tehát nem bizonyíték arra, hogy forgalom folyik. Az On-demand akkor is felemelhet egy alagutat, amikor az alkalmazás fel van függesztve, és akkor az értesítés azelőtt érkezik, hogy bármit frissíthetnél.

A korlátozott proxy-pillanatkép utalás, nem ítélet

A CFNetwork átadhatja az alkalmazásnak a rendszer aktuális proxybeállításait, és az eredményben van egy korlátozott szótár, amelynek kulcsa az interfész neve. Ha olyan nevet látsz, amely tun, utun, ppp, ipsec vagy tap előtaggal kezdődik, az utalás arra, hogy van alagút. Ez továbbra is pillanatkép arról, amit ez az alkalmazás láthat, nem állítás arról, hová utaznak a csomagok.

A szolgáltatók nem értenek egyet az elnevezésben, ezért a hiányzó előtag semmit nem bizonyít, és egy jelen lévő interfész létezhet forgalom nélkül is. Az elérhetőség még gyengébb: egy sikeres kérés egy privát címre azt mutatja, hogy az útvonal akkor, abban a pillanatban működött, nem azt, hogy VPN van telepítve.

A szimulátor kölcsönveszi a Macet, a többi alkalmazás láthatatlan marad

A szimulátornak nincs saját hálózati stackje; minden kapcsolat, amit létesít, a Macé. Ezért a hoszt Macen futó VPN már érvényben van a szimulált alkalmazás számára, és magának a szimulátornak a beállításai semmit nem mutatnak. Ha az alagút a szimulátor indítása után jött fel, újraindítása általában gyorsabb, mint az alkalmazás hibakeresése. Egy nem szabványos porton lévő hoszthoz kell az a port az URL-ben, vagy egy helyi átirányítás, mint a socat TCP-LISTEN:12345,fork TCP:host:12345.

A nyilvános API-k nem sorolják fel a más alkalmazásokhoz vagy konfigurációs profilokhoz tartozó VPN-profilokat. Egy ismert alkalmazás esetében az URL-séma próba a canOpenURL segítségével a hordozható trükk, és az iOS 9 óta a lekérdezett sémát deklarálni kell az Info.plistben; ha kihagyod, a hívás false-t ad vissza. Az OpenVPN Connect a openvpn://-re válaszol, ami jó példává és rossz általános detektorrá teszi.

Kombinálj három megfigyelést, és mondd meg, mit jelentenek

A gyakorlatban rakj egymásra három eredményt: egy konfigurációt, amely betöltődött és engedélyezve van, egy kapcsolatállapotot, amely nem érvénytelen, és egy kérést egy olyan címre, amely csak az alagúton át érhető el. Mindegyik önmagában félrevezet; együtt azt mondják meg, mit tudhat az alkalmazás, nem azt, mit feltételez a felhasználó.

Az eredményt három sorban írd le a diagnosztikádban, ne egyetlen booleanben. Amikor a felhasználó azt mondja, hogy a VPN ki van kapcsolva, miközben az alkalmazásod nem ért egyet, a három sor megmutatja, melyik megfigyelés tért el, és ez a különbség egy kezelhető támogatási jegy és egy «nálam működik» végű jegy között.