Så kontrollerar du VPN-status utan ping på Android, iOS och Windows

Ett ping bevisar bara att en värd svarade, inte att tunneln är uppe. Fråga status-API:erna i Android, iOS och Windows och verifiera sedan den rutt som din app faktiskt behöver.

Ett ping mot 192.0.2.10 säger bara att en adress svarade på ett ICMP-eko, och inget mer. I ett nätverk utan tunnel kan det ändå lyckas, eftersom adressen kan ligga i det lokala subnätet; med en frisk tunnel kan det misslyckas, eftersom servern släpper ICMP medan den levererar HTTPS. Den kontroll som ditt skript behöver är en statusfråga till plattformen plus ett rutt-test mot destinationen som appen använder. Behandla dem som två separata fält, aldrig som ett enda booleskt värde.

Vad ett eko-svar faktiskt bevisar

ICMP är ett nåbarhetsprotokoll som inte har något begrepp om gränssnitt eller tunnlar. När ett svar kommer rapporterar kärnan att en värd svarade; den rapporterar inte vilken rutt som bar fram förfrågan eller vilken som bar tillbaka svaret. Filtrering gör signalen ännu brusigare, eftersom en brandvägg som blockerar eko-förfrågningar inte säger något om portarna bakom den. Och en profil med delad tunnel kan medvetet utesluta den testade adressen medan alla andra destinationer fungerar.

Det du egentligen vill veta är om en viss tjänst är användbar på den väg appen tar. Välj värden och porten som appen anropar och kräv sedan ett svar på applikationsnivå.

Nåbarhet och tunnelstatus är olika fakta, och den ena kan vara sann medan den andra är falsk. Håller du dem åtskilda vet du vems felet är. Slår du ihop dem till en enda kontroll får du ett ärende som ingen kan dirigera.

Fråga Android om transporten, inte om ping

Android svarar direkt på statusfrågan via ConnectivityManager. Det aktiva nätverkets förmågor bär en VPN-transportflagga som sätts när trafiken dirigeras genom ett VPN-gränssnitt. Anropet är lokalt, billigt och oberoende av om någon fjärrvärd svarar.

Den här Java-versionen returnerar false i stället för att kasta ett undantag när det inte finns något aktivt nätverk. Eftersom den läser det aktiva nätverket speglar den profilen som användaren valde i Inställningar.

ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

För ändringsaviseringar registrerar du en NetworkCallback i stället för att polla med en timer. Blanda inte ihop det med VpnService.prepare, som bara rapporterar om användaren gav tillstånd för VPN, inte om paketen flödar. Återkallelse kommer via VpnService.onRevoke, men att glömma en profil i Inställningarna ger ingen sändning alls.

iOS: gränssnittsnamn är en heuristik, inte ett kontrakt

Många iOS-utdrag undersöker proxyinställningarna, hittar __SCOPED__-ordboken och letar efter gränssnittsnycklar som tap, tun, utun2, ppp eller ipsec. Det angreppssättet är en namnkonvention, inte en dokumenterad garanti, så en OS-uppdatering som byter namn på ett gränssnitt kan bryta det. Det tenderar också att rapportera true för inaktuella poster som överlever tunneln.

När din app äger konfigurationen ger NEVPNManager en riktig status. Den beskriver tunneln som din app startade; med VPN per app kan andra appar stå helt utanför den tunneln.

Ladda om inställningarna innan du läser statusen, eftersom värdet ändras när tunneln går upp och ner:

let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
    let up = manager.connection.status == .connected
    print(up)
}

En statusflagga från plattformen bevisar fortfarande inte att trafiken når peeren. Det gapet täcker rutt-testet, och därför räcker inte ett enda booleskt värde för support.

Windows-profiler exponerar ett riktigt statusfält

Windows spårar VPN-profiler separat från adaptrar, och Get-VpnConnection exponerar en ConnectionStatus för varje profil den känner till. Profiler som skapats via Windows-klienten eller ett etableringspaket visas här. Cmdleten är ingen generell tunneldetektor.

Läs fältet för en namngiven profil och lägg till -AllUserConnection när profilen tillhör alla användare:

Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress

Tredjepartsklienter förblir ofta osynliga för den här cmdleten även när deras tunnel är uppe, så ett tomt resultat betyder okänt, inte frånkopplat. Adapterlistor vilseleder lika mycket: en leverantörsadapter kan bestå medan den är inaktiv, och vissa adaptrar finns bara under en session. För en profil som Windows äger rapporterar rasdial en utgångskod som du kan förgrena på. Allt detta beskriver lokal tro, inte peerns nåbarhet.

Status plus rutt: den tvådelade kontrollen

En ansluten profil säger ingenting om vart paketen tar vägen. Delad tunnling kan hålla tunneln uppe medan den utesluter destinationen du bryr dig om. Always-on-profiler förblir anslutna med en död server, och en kill switch blockerar trafik med avsikt när tunneln faller.

Testa båda lagren: bekräfta att en VPN-transport eller profil är aktiv och bekräfta sedan att destinationen löses upp och svarar längs den vägen. I Linux, fråga kärnan vilket gränssnitt den skulle använda:

ip route get 192.0.2.10
resolvectl query intranet.example.test

När klienten ligger utanför din kontroll loggar du båda resultaten och låter mönstret peka på lagret. Ansluten plus ett misslyckat rutt-test antyder delad tunnling, DNS eller policy. Frånkopplad plus ett fungerande rutt-test betyder att en annan väg bär trafiken.

Ett test du kan köra i ordning

Registrera plattformens status först, innan du ändrar något nätverksläge. Lös upp värdnamnet och notera adressfamiljen, eftersom en AAAA-post kan ta en annan väg än en A-post. Öppna tjänstens port och kräv ett applikationssvar i stället för bara ett handskak. Håll varje observation i sitt eget loggfält.

På en Linux-maskin med dig och curl täcker tre kommandon uppslagning, rutt och själva tjänsten. Kör dem med tunneln uppe och igen när den är nere:

dig +short intranet.example.test
ip route get 198.51.100.20
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 https://intranet.example.test/health

Fyra separata fält slår ett booleskt värde, eftersom status, DNS, rutt och policy fallerar oberoende av varandra och hamnar hos olika team. Ett ping i terminalen är fortfarande en bra manuell kontroll. Det är en dålig definition av anslutning för automatisering, där plattformens API och ett rutt-test svarar på den verkliga frågan.

Relaterade artiklar