Je iPhone na VPN? Co může aplikace pro iOS skutečně zjistit
V iOS SDK neexistuje jediný příznak VPN. Aplikace může pozorovat vlastní konfiguraci, oznámení o stavu a omezený snímek proxy, nic víc.
Zeptejte se aplikace pro iOS, zda je telefon na VPN, a poctivá odpověď je, že to nemůže vědět tak, jak to myslíte. SDK nenabízí žádný příznak pro «zařízení je v tunelu» a soukromá rozhraní, která by se tomu mohla přiblížit, jsou pro publikované aplikace uzavřená. Můžete pozorovat vlastní konfiguraci aplikace, stav, který je k ní připojen, a jeden či dva nepřímé náznaky ze síťového zásobníku. Každý odpovídá na jinou otázku a většina rozbitých kontrol vzniká tím, že se jeden z nich vezme za celou odpověď.
Mýtus jediného příznaku VPN
Věří se, že někde v SDK existuje vlastnost, která hlásí, zda je zařízení v tunelu, podobně jako příznak dosažitelnosti hlásí, zda hostitel odpovídá. Taková veřejná vlastnost neexistuje. I kdyby existovala, «tunel existuje» a «můj provoz ho používá» jsou různá tvrzení a pro většinu aplikací je důležité jen to druhé.
Právě kvůli této mezeře knihovny, které inzerují jednosloupcový detektor VPN, obvykle čtou něco křehkého, třeba název rozhraní nebo klíč proxy, a vydávají to za rozsudek.
Načtěte předvolby, než uvěříte nil
Sdílená instance správce existuje, jakmile o ni požádáte, ale její vlastnost protokolu zůstává nil, dokud se nedokončí zavolání pro načtení. Proto nil protokol znamená «ještě nenačteno» přinejmenším stejně často jako «nenainstalováno». Čtěte uvnitř bloku dokončení a teprve potom rozhodněte: objekt protokolu, který existuje a má zapnutý příznak povolení, tak vypadá «nainstalováno».
Druhý signál je na objektu připojení: neplatný stav, který systém hlásí, když tato aplikace nemá nainstalovanou žádnou konfiguraci. Neplatný stav spolu s nil protokolem po dokončeném načtení je skutečná nepřítomnost, ne časový závod.
Změny připojení přicházejí jako oznámení
Obslužné rutiny předané do load a save hlásí, co se stalo s konfigurací, ne co dělá tunel. Čekat, až se jedna z nich spustí při připojení, je závod, který se nikdy nevyřeší. Sledujte místo toho oznámení o změně stavu a přečtěte aktuální hodnotu objektu připojení, když dorazí.
Jakmile je konfigurace nainstalovaná, stav připojení projde krátkou sekvencí: odpojeno, připojování, připojeno, znovupotvrzení, odpojování. «Připojeno» popisuje tunel, ne server za ním, takže to není důkaz, že provoz teče. On-demand může tunel zvednout i tehdy, když je aplikace pozastavená, a pak oznámení dorazí dřív, než máte co aktualizovat.
Omezený snímek proxy je náznak, ne rozsudek
CFNetwork může aplikaci předat aktuální systémové nastavení proxy a uvnitř toho výsledku je omezený slovník s klíčem podle názvu rozhraní. Název začínající na tun, utun, ppp, ipsec nebo tap je náznak, že tunel existuje. Zůstává to snímkem toho, co tato aplikace vidí, ne tvrzením o tom, kudy pakety putují.
Poskytovatelé se neshodnou na pojmenování, takže chybějící prefix nic nedokazuje a přítomné rozhraní může existovat, aniž by přenášelo provoz. Dosažitelnost je ještě slabší: úspěšný požadavek na soukromou adresu ukazuje, že cesta pro ten požadavek v tu chvíli fungovala, ne že je nainstalovaná VPN.
Simulátor si půjčuje Mac a ostatní aplikace zůstávají neviditelné
Simulátor nemá vlastní síťový zásobník; každé spojení, které naváže, je Macu. VPN běžící na hostitelském Macu tedy už platí i pro simulovanou aplikaci a nastavení samotného simulátoru nic neukazují. Pokud tunel vznikl po spuštění simulátoru, restartovat ho je obvykle rychlejší než ladit aplikaci. Hostitel na nestandardním portu potřebuje ten port v URL, nebo místní přesměrování jako socat TCP-LISTEN:12345,fork TCP:host:12345.
Veřejná API nevyjmenují profily VPN, které patří jiným aplikacím nebo konfiguračním profilům. Pro jednu známou aplikaci je přenosný trik sonda schématu URL přes canOpenURL a od iOS 9 musí být dotazované schéma deklarované ve vašem Info.plist; vynecháte-li ho, volání vrátí false. OpenVPN Connect odpovídá na openvpn://, což z něj dělá dobrý příklad a špatný obecný detektor.
Spojte tři pozorování a řekněte, co znamenají
V praxi složte tři výsledky: konfiguraci, která se načetla a je povolená, stav připojení, který není neplatný, a požadavek na adresu dostupnou jen tunelem. Každé samo o sobě mate; dohromady říkají, co aplikace může vědět, ne co uživatel předpokládá.
Zapište výsledek jako tři řádky v diagnostice, ne jako jeden boolean. Když uživatel tvrdí, že VPN je vypnutá, a vaše aplikace nesouhlasí, tři řádky ukážou, které pozorování se rozešlo, a to je rozdíl mezi tiketem podpory, na který můžete reagovat, a tiketem, který skončí u «mně to funguje».