Hogyan ellenőrizzük a VPN állapotát ping nélkül Androidon, iOS-en és Windows-on

A 192.0.2.10 pingelése csak azt mondja meg, hogy egy cím válaszolt egy ICMP-visszhangra, és semmi többet. Alagút nélküli hálózaton mégis sikerülhet, mert a cím a helyi alhálózaton lehet; egészséges alagút mellett viszont meghiúsulhat, mert a kiszolgáló eldobja az ICMP-t, miközben HTTPS-t szolgál ki. A szkriptednek szükséges ellenőrzés egy platformállapot-lekérdezés és egy útvonal-teszt az alkalmazás által használt célállomás felé. Ezeket két külön mezőként kezeld, soha ne egyetlen logikai értékként.

Mit bizonyít valójában egy visszhangválasz

Az ICMP egy elérhetőségi protokoll, amely nem ismeri az interfészeket vagy az alagutakat. Amikor válasz érkezik, a kernel azt jelenti, hogy egy hoszt válaszolt; azt nem, hogy melyik útvonal vitte a kérést, és melyik hozta a választ. A szűrés még zajosabbá teszi a jelet, mert a visszhangkéréseket blokkoló tűzfal semmit sem mond a mögötte lévő portokról. Egy osztott alagútú profil pedig szándékosan kizárhatja a tesztelt címet, miközben minden más célállomás működik.

Amit valójában tudni szeretnél, az az, hogy egy adott szolgáltatás használható-e azon az útvonalon, amelyen az alkalmazás halad. Válaszd ki a hosztot és a portot, amelyet az alkalmazás hív, majd követeld meg a választ az alkalmazási rétegen.

Az elérhetőség és az alagút állapota külön tény, és bármelyik igaz lehet, miközben a másik hamis. Ha külön tartod őket, kiderül, kié a hiba. Ha egyetlen ellenőrzésbe olvasztod őket, olyan ticket lesz belőle, amelyet senki sem tud továbbítani.

Androidtól a szállítást kérdezd, ne a pinget

Az Android közvetlenül megválaszolja az állapot kérdését a ConnectivityManageren keresztül. Az aktív hálózat képességei VPN-szállítási jelzőt hordoznak, amely akkor áll be, amikor a forgalom VPN-interfészen keresztül halad. A hívás helyi, olcsó, és független attól, hogy válaszol-e valamelyik távoli hoszt.

Ez a Java-változat false értéket ad vissza ahelyett, hogy kivételt dobna, ha nincs aktív hálózat. Mivel az aktív hálózatot olvassa, azt a profilt tükrözi, amelyet a felhasználó a Beállításokban választott.

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

Változásértesítésekhez NetworkCallbacket regisztrálj ahelyett, hogy időzítővel kérdeznél le. Ne keverd ezt a VpnService.prepare-rel, amely csak azt jelenti, hogy a felhasználó engedélyt adott-e VPN-re, nem azt, hogy folynak-e a csomagok. A visszavonás a VpnService.onRevoke-on keresztül érkezik, ám egy profil elfelejtése a Beállításokban egyáltalán nem vált ki sugárzást.

iOS: az interfésznevek heurisztikák, nem szerződés

Sok iOS-kódrészlet megvizsgálja a proxybeállításokat, megtalálja a __SCOPED__ szótárt, és olyan interfészkulcsokat keres, mint a tap, tun, utun2, ppp vagy ipsec. Ez a megközelítés elnevezési konvenció, nem dokumentált garancia, ezért egy interfészt átnevező rendszerfrissítés eltörheti. Hajlamos továbbá true értéket jelenteni olyan elavult bejegyzésekre, amelyek túlélik az alagutat.

Amikor az alkalmazásod birtokolja a konfigurációt, a NEVPNManager valódi állapotot ad. Azt az alagutat írja le, amelyet az alkalmazásod indított; alkalmazásonkénti VPN esetén más alkalmazások teljesen ezen az alagúton kívül lehetnek.

A státusz olvasása előtt töltsd újra a beállításokat, mert az érték változik, ahogy az alagút fel- és lejön:

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

A platform állapotjelzője még mindig nem bizonyítja, hogy a forgalom eléri a partnert. Ezt a rést fedi le az útvonal-teszt, és ezért nem elég egyetlen logikai érték a támogatáshoz.

A Windows-profilok valódi állapotmezőt tárnak fel

A Windows az adapterektől külön követi a VPN-profilokat, és a Get-VpnConnection ConnectionStatusot tesz elérhetővé minden ismert profilhoz. A Windows-ügyféllel vagy kiépítési csomaggal létrehozott profilok itt jelennek meg. A parancsmag nem általános alagútérzékelő.

Olvasd ki a mezőt egy megnevezett profilhoz, és add hozzá a -AllUserConnection kapcsolót, ha a profil minden felhasználóé:

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

A harmadik féltől származó ügyfelek gyakran láthatatlanok maradnak e parancsmag számára akkor is, amikor az alagútjuk él, így az üres eredmény ismeretlent jelent, nem pedig megszakadt kapcsolatot. Az adapterlisták ugyanilyen félrevezetők: egy gyártói adapter tétlenül is fennmaradhat, és egyes adapterek csak egy munkamenet idejére léteznek. Egy Windows által birtokolt profilhoz a rasdial olyan kilépési kódot ad, amelyre elágazhatsz. Mindez helyi meggyőződést ír le, nem a partner elérhetőségét.

Állapot plusz útvonal: a kétrészes ellenőrzés

Egy csatlakoztatott profil semmit sem mond arról, hová mennek a csomagok. Az osztott alagút életben tarthatja az alagutat, miközben kizárja a számodra fontos célállomást. Az always-on profilok egy halott kiszolgálóval is csatlakozva maradnak, a kill switch pedig szándékosan blokkolja a forgalmat, amikor az alagút leesik.

Teszteld mindkét réteget: igazold, hogy egy VPN-szállítás vagy profil aktív, majd igazold, hogy a célállomás feloldódik és válaszol azon az útvonalon. Linuxon kérdezd meg a kernelt, melyik interfészt használná:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Amikor az ügyfél az ellenőrzéseden kívül esik, naplózd mindkét eredményt, és hagyd, hogy a minta mutasson a rétegre. Csatlakozva és sikertelen útvonal-teszt osztott alagútra, DNS-re vagy házirendre utal. Szétkapcsolva és működő útvonal-teszt azt jelenti, hogy más útvonal viszi a forgalmat.

Egy teszt, amelyet sorrendben futtathatsz

Először a platform állapotát rögzítsd, mielőtt bármilyen hálózati állapotot megváltoztatnál. Oldd fel a hosztnevet, és jegyezd fel a címcsaládot, mert az AAAA-rekord más útvonalat vehet, mint az A-rekord. Nyisd meg a szolgáltatás portját, és alkalmazásválaszt követelj, ne puszta kézfogást. Minden megfigyelést a saját naplómezőjében tarts.

Egy dig és curl programmal rendelkező Linux-gépen három parancs lefedi a feloldást, az útvonalat és magát a szolgáltatást. Futtasd őket élő alagúttal, majd újra kikapcsolt állapotban:

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

Négy külön mező jobb egyetlen logikai értéknél, mert az állapot, a DNS, az útvonal és a házirend egymástól függetlenül hibázik, és különböző csapatokhoz kerül. A terminálban futtatott ping továbbra is jó kézi ellenőrzés. Gyenge meghatározása a kapcsolódásnak automatizáláshoz, ahol a platform API-ja és egy útvonal-teszt válaszol a valódi kérdésre.