Är iPhone på ett VPN? Vad en iOS-app faktiskt kan se

Fråga en iOS-app om telefonen är på ett VPN, och det ärliga svaret är att den inte kan veta det på det sätt du menar. SDK:t exponerar ingen flagga för «enheten är i en tunnel», och de privata gränssnitten som skulle kunna närma sig det är stängda för appar som publiceras. Du kan observera appens egen konfiguration, tillståndet som hänger på den, och en eller två indirekta ledtrådar från nätverksstacken. Var och en svarar på en annan fråga, och de flesta trasiga kontrollerna kommer av att man tar en av dem som hela svaret.

Myten om den enda VPN-flaggan

Föreställningen är att det någonstans i SDK:t finns en egenskap som rapporterar om enheten är i en tunnel, ungefär som en nåbarhetsflagga rapporterar om en värd svarar. En sådan offentlig egenskap finns inte. Och även om den gjorde det är «det finns en tunnel» och «min trafik använder den» olika påståenden, och för de flesta appar spelar bara det andra roll.

Just denna klyfta är anledningen till att bibliotek som annonserar med en enradig VPN-detektor oftast läser något skört, som ett gränssnittsnamn eller en proxy-nyckel, och presenterar det som en dom.

Läs in inställningarna innan du litar på en nil

Den delade manager-instansen finns så snart du ber om den, men dess protokollegenskap förblir nil tills inläsningens callback är klar. En nil-protokoll betyder alltså «inte inläst än» minst lika ofta som «inte installerad». Gör läsningen inne i completion-blocket och avgör först efteråt: ett protokollobjekt som finns, med aktiveringsflaggan på, är hur «installerad» ser ut.

En andra signal sitter på anslutningsobjektet: det ogiltiga tillståndet, som systemet rapporterar när den här appen inte har någon installerad konfiguration. Ogiltigt tillstånd tillsammans med en nil-protokoll efter en slutförd inläsning är en verklig frånvaro, inte en tidskapplöpning.

Anslutningsändringar kommer som aviseringar

Hanterare som skickas till load och save rapporterar vad som hände med konfigurationen, inte vad tunneln gör. Att vänta på att en av dem utlöses vid anslutning är en kapplöpning som aldrig löses. Håll i stället koll på aviseringen om statusändring och läs anslutningsobjektets aktuella värde när den kommer.

När en konfiguration är installerad går anslutningstillståndet igenom en kort sekvens: frånkopplad, ansluter, ansluten, bekräftar på nytt, kopplar från. «Ansluten» beskriver tunneln och inte servern bakom den, så det är inget bevis för att trafik flödar. On-demand kan också resa en tunnel medan appen är suspenderad, och då kommer aviseringen innan du har något att uppdatera.

Den begränsade proxy-ögonblicksbilden är en ledtråd, inte en dom

CFNetwork kan ge appen systemets aktuella proxyinställningar, och inuti det resultatet finns en begränsad ordbok med nyckel efter gränssnittsnamn. Att se ett namn som börjar med tun, utun, ppp, ipsec eller tap är en ledtråd om att en tunnel finns. Det är fortfarande en ögonblicksbild av vad den här appen kan se, inte ett uttalande om vart paketen reser.

Leverantörer är oense om namngivningen, så ett saknat prefix bevisar ingenting, och ett gränssnitt som finns kan existera utan att bära trafik. Nåbarhet är ännu svagare: en lyckad begäran till en privat adress visar att vägen fungerade för den begäran i det ögonblicket, inte att ett VPN är installerat.

Simulatorn lånar Macen, och andra appar förblir osynliga

Simulatorn har ingen egen nätverksstack; varje anslutning den gör är Macens. Ett VPN som körs på värd-Macen gäller därför redan för den simulerade appen, och simulatorns egna inställningar visar ingenting. Om tunneln kom upp efter att simulatorn startade är det oftast snabbare att starta om den än att felsöka appen. En värd på en icke-standardport behöver den porten i URL:en, eller en lokal vidarebefordran som socat TCP-LISTEN:12345,fork TCP:host:12345.

Offentliga API:er kommer inte att lista VPN-profiler som tillhör andra appar eller konfigurationsprofiler. För en känd app är ett URL-schematest via canOpenURL det portabla tricket, och sedan iOS 9 måste schemat som frågas om deklareras i din Info.plist; utelämnar du det returnerar anropet false. OpenVPN Connect svarar på openvpn://, vilket gör det till ett bra exempel och en dålig allmän detektor.

Kombinera tre observationer och säg vad de betyder

Stapla tre resultat i praktiken: en konfiguration som lästes in och är aktiverad, ett anslutningstillstånd som inte är ogiltigt, och en begäran till en adress som bara nås genom tunneln. Var och en vilseleder för sig; tillsammans säger de vad appen kan veta i stället för vad användaren antar.

Skriv resultatet som tre rader i din diagnostik, inte som en enda boolean. När en användare säger att VPN:et är avstängt medan din app inte håller med, visar de tre raderna vilken observation som avvek, och det är skillnaden mellan ett supportärende du kan agera på och ett som slutar med «hos mig funkar det».