Ako skontrolovať stav VPN bez ping v systémoch Android, iOS a Windows

Ping na 192.0.2.10 vám povie len to, že jedna adresa odpovedala na echo ICMP, a nič viac. V sieti bez tunela môže napriek tomu uspieť, pretože adresa môže byť v lokálnej podsieti; so zdravým tunelom môže zlyhať, pretože server zahadzuje ICMP, kým obsluhuje HTTPS. Kontrola, ktorú váš skript potrebuje, je dopyt na stav platformy plus test trasy k cieľu, ktorý aplikácia používa. Berte ich ako dve samostatné polia, nikdy ako jednu booleovskú hodnotu.

Čo odpoveď na echo skutočne dokazuje

ICMP je protokol dostupnosti, ktorý nepozná rozhrania ani tunely. Keď príde odpoveď, jadro oznámi, že host odpovedal; neoznámi, ktorá trasa niesla požiadavku a ktorá niesla odpoveď. Filtrovanie robí signál ešte hlučnejším, pretože firewall, ktorý blokuje echo požiadavky, nič nehovorí o portoch za ním. A profil s rozdeleným tunelom môže zámerne vylúčiť testovanú adresu, kým všetky ostatné ciele fungujú.

V skutočnosti chcete vedieť, či je konkrétna služba použiteľná po ceste, ktorou aplikácia ide. Vyberte host a port, ktoré aplikácia volá, a potom žiadajte odpoveď na aplikačnej vrstve.

Dostupnosť a stav tunela sú odlišné fakty a jeden môže byť pravdivý, kým druhý je nepravdivý. Ak ich držíte oddelene, viete, čí je to porucha. Ak ich zlejete do jednej kontroly, vznikne tiket, ktorý nikto nedokáže smerovať.

Pýtajte sa Androidu na transport, nie na ping

Android odpovedá na otázku stavu priamo cez ConnectivityManager. Možnosti aktívnej siete nesú príznak transportu VPN, ktorý sa nastaví, keď sa prevádzka smeruje cez rozhranie VPN. Volanie je lokálne, lacné a nezávisí od toho, či nejaký vzdialený host odpovedá.

Táto verzia v Jave vracia false namiesto výnimky, keď neexistuje aktívna sieť. Keďže číta aktívnu sieť, odráža profil, ktorý používateľ vybral v Nastaveniach.

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

Pre oznámenia o zmenách zaregistrujte NetworkCallback namiesto dopytovania časovačom. Nezamieňajte to s VpnService.prepare, ktorý hlási len to, či používateľ udelil povolenie pre VPN, nie či pakety prúdia. Odvolanie prichádza cez VpnService.onRevoke, no zabudnutý profil v Nastaveniach nevyvolá žiadne vysielanie.

iOS: názvy rozhraní sú heuristika, nie kontrakt

Mnohé úryvky pre iOS skúmajú nastavenia proxy, nájdu slovník __SCOPED__ a hľadajú kľúče rozhraní ako tap, tun, utun2, ppp alebo ipsec. Tento prístup je konvencia pomenovania, nie dokumentovaná záruka, takže aktualizácia systému, ktorá rozhranie premenuje, ho môže pokaziť. Má tiež sklon hlásiť true pre zastarané záznamy, ktoré prežijú tunel.

Keď konfiguráciu vlastní vaša aplikácia, NEVPNManager dáva skutočný stav. Opisuje tunel, ktorý spustila vaša aplikácia; pri VPN pre každú aplikáciu môžu iné aplikácie stáť úplne mimo tohto tunela.

Pred čítaním stavu znova načítajte preferencie, pretože hodnota sa mení, keď tunel stúpa a klesá:

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

Príznak stavu platformy stále nedokazuje, že prevádzka dorazí k partnerovi. Práve tú medzeru pokrýva test trasy, a preto jedna booleovská hodnota nestačí na podporu.

Profily Windows odhaľujú skutočné pole stavu

Windows sleduje profily VPN oddelene od adaptérov a Get-VpnConnection odhaľuje ConnectionStatus pre každý známy profil. Profily vytvorené cez klienta Windows alebo balík na prípravu sa objavia tu. Tento cmdlet nie je univerzálny detektor tunelov.

Prečítajte pole pre pomenovaný profil a pridajte -AllUserConnection, keď profil patrí všetkým používateľom:

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

Klienti tretích strán často zostávajú pre tento cmdlet neviditeľní, aj keď ich tunel beží, takže prázdny výsledok znamená neznáme, nie odpojené. Zoznamy adaptérov klamú rovnako: adaptér dodávateľa môže pretrvávať, kým je nečinný, a niektoré adaptéry existujú len počas relácie. Pre profil, ktorý vlastní Windows, rasdial hlási návratový kód, na ktorý sa dá vetviť. Všetko to opisuje lokálne presvedčenie, nie dostupnosť partnera.

Stav plus trasa: kontrola v dvoch častiach

Pripojený profil nič nehovorí o tom, kam pakety idú. Rozdelený tunel môže udržať tunel aktívny a vylúčiť cieľ, na ktorom vám záleží. Profily always-on zostávajú pripojené s mŕtvym serverom a kill switch zámerne blokuje prevádzku, keď tunel padne.

Testujte obe vrstvy: potvrďte, že transport VPN alebo profil je aktívny, potom potvrďte, že cieľ sa rozlíši a odpovedá po tejto ceste. V Linuxe sa opýtajte jadra, ktoré rozhranie by použilo:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Keď je klient mimo vašej kontroly, zapíšte oba výsledky a nechajte vzor ukázať na vrstvu. Pripojené a neúspešný test trasy naznačuje rozdelený tunel, DNS alebo politiku. Odpojené a fungujúci test trasy znamená, že prevádzku nesie iná cesta.

Test, ktorý môžete spustiť v poradí

Najprv zaznamenajte stav platformy, skôr než zmeníte akýkoľvek stav siete. Rozlíšte názov hosta a poznamenajte rodinu adries, pretože záznam AAAA môže ísť inou cestou než záznam A. Otvorte port služby a žiadajte odpoveď aplikácie, nie len podanie ruky. Každé pozorovanie držte vo vlastnom poli záznamu.

Na stroji s Linuxom, dig a curl tri príkazy pokrývajú rozlíšenie, trasu a samotnú službu. Spustite ich s dvihnutým tunelom a znova so spusteným:

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

Štyri oddelené polia porážajú jednu booleovskú hodnotu, pretože stav, DNS, trasa a politika zlyhávajú nezávisle a končia v rôznych tímoch. Ping v termináli zostáva dobrou manuálnou kontrolou. Je to slabá definícia konektivity pre automatizáciu, kde API platformy a test trasy odpovedajú na skutočnú otázku.