Kuidas kontrollida VPN-i olekut ilma pingita Androidis, iOS-is ja Windowsis

Pingimine aadressile 192.0.2.10 ütleb teile, et üks aadress vastas ICMP kajale, ja rohkem mitte. Tunnelita võrgus võib see siiski õnnestuda, sest aadress võib asuda kohalikus alavõrgus; terve tunneliga võib see aga ebaõnnestuda, sest server viskab ICMP kõrvale, samal ajal kui teenindab HTTPS-i. Kontroll, mida teie skript vajab, on platvormi olekupäring pluss marsruuditest sihtkohale, mida rakendus kasutab. Käsitlege neid kahe eraldi väljana, mitte kunagi ühe booleanina.

Mida kaja vastus tegelikult tõestab

ICMP on kättesaadavuse protokoll, millel puudub arusaam liidestest ja tunnelitest. Vastuse saabudes teatab tuum, et host vastas; see ei ütle, milline marsruut kandis päringut või vastust. Filtreerimine muudab signaali veelgi mürahõngulisemaks, sest kaja päringuid blokeeriv tulemüür ei ütle midagi selle taga olevate portide kohta. Ja split-tunneli profiil võib testitava aadressi meelega välja jätta, samal ajal kui kõik muud sihtkohad töötavad.

Mida te tegelikult teada tahate, on see, kas konkreetne teenus on kasutatav mööda teed, mille rakendus valib. Valige host ja port, mida rakendus kutsub, ning seejärel nõudke vastust rakenduse tasandil.

Kättesaadavus ja tunneli olek on erinevad faktid ning kumb tahes võib olla tõene, samal ajal kui teine on väär. Nende lahus hoidmine ütleb teile, kelle oma on tõrge. Nende ühte kontrolli ühendamine annab pileti, mida keegi ei saa marsruutida.

Küsige Androidilt transporti, mitte pingi kohta

Android vastab olekuküsimusele otse ConnectivityManageri kaudu. Aktiivse võrgu võimekused kannavad VPN-transpordi lippu, mis seatakse, kui liiklus suunatakse VPN-liidese kaudu. Kutse on kohalik, odav ja sõltumatu sellest, kas mõni kaugem host vastab.

See Java versioon tagastab false, selle asemel et visata erind, kui aktiivset võrku pole. Kuna see loeb aktiivset võrku, peegeldab see profiili, mille kasutaja seadetes valis.

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

Muudatusteatiste jaoks registreerige NetworkCallback, selle asemel et taimeriga küsida. Ärge ajage seda segi VpnService.prepare-iga, mis teatab ainult, kas kasutaja andis VPN-ile loa, mitte seda, kas paketid liiguvad. Tühistamine tuleb VpnService.onRevoke kaudu, kuid profiili unustamine seadetes ei tekita üldse ühtki saatet.

iOS: liidese nimed on heuristika, mitte leping

Paljud iOS-i katked uurivad puhverserveri seadeid, leiavad sõnastiku __SCOPED__ ja otsivad liidese võtmeid nagu tap, tun, utun2, ppp või ipsec. See lähenemine on nimetamise konventsioon, mitte dokumenteeritud garantii, seega OS-i uuendus, mis liidese ümber nimetab, võib selle katki teha. See kipub ka teatama tõest aegunud kirjete puhul, mis tunnelist üle elavad.

Kui konfiguratsioon kuulub teie rakendusele, annab NEVPNManager teile tõelise oleku. See kirjeldab tunnelit, mille teie rakendus käivitas; rakendusepõhise VPN-i korral võivad teised rakendused jääda täiesti väljapoole seda tunnelit.

Laadige eelistused enne oleku lugemist uuesti, sest väärtus muutub, kui tunnel tõuseb ja langeb:

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

Platvormi oleku lipp ei tõesta ikkagi, et liiklus jõuab partnerini. Just selle lünga katab marsruuditest ja seepärast ei piisa toe jaoks ühest booleanist.

Windowsi profiilid pakuvad tõelist olekuvälja

Windows jälgib VPN-profiile adapteritest eraldi ja Get-VpnConnection näitab ConnectionStatus-i iga teadaoleva profiili kohta. Siin ilmuvad Windowsi kliendi või ettevalmistuspaketiga loodud profiilid. See cmdlet ei ole üldine tunnelidetektor.

Lugege välja nimetatud profiili jaoks, lisades -AllUserConnection, kui profiil kuulub kõigile kasutajatele:

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

Kolmandate osapoolte kliendid jäävad selle cmdleti jaoks sageli nähtamatuks ka siis, kui nende tunnel töötab, seega tühi tulemus tähendab teadmata, mitte ühendamata. Adapterite loendid eksitavad sama palju: tootja adapter võib püsida ka jõudeolekus ning mõned adapterid eksisteerivad ainult sessiooni ajal. Profiili puhul, mille Windows omab, teatab rasdial väljumiskoodi, mille peale saab haruneda. Kõik see kirjeldab kohalikku uskumust, mitte partneri kättesaadavust.

Olek pluss marsruut: kaheosaline kontroll

Ühendatud profiil ei ütle midagi selle kohta, kuhu paketid lähevad. Split tunneling võib hoida tunnelit üleval, jättes samal ajal välja sihtkoha, mis teile tähtis on. Always-on profiilid jäävad surnud serveriga ühendatuks ja kill switch blokeerib liikluse meelega, kui tunnel langeb.

Testige mõlemat kihti: kinnitage, et VPN-transport või profiil on aktiivne, ja seejärel, et sihtkoht laheneb ja vastab sellel teel. Linuxis küsige tuumalt, millist liidest see kasutaks:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Kui klient on väljaspool teie kontrolli, logige mõlemad tulemused ja laske mustril osutada kihile. Ühendatud pluss ebaõnnestunud marsruuditest viitab split tunnelingule, DNS-ile või põhimõttele. Ühendamata pluss töötav marsruuditest tähendab, et liiklust kannab teine tee.

Test, mida saate järjekorras käivitada

Registreerige esmalt platvormi olek, enne kui muudate ükskõik millist võrgu olekut. Lahendage hostinimi ja märkige aadressipere, sest AAAA-kirje võib minna teist teed kui A-kirje. Avage teenuse port ja nõudke rakenduse vastust, mitte paljast kätlust. Hoidke iga vaatlus oma logiväljas.

Linuxi masinas, kus on dig ja curl, katavad kolm käsku lahendamise, marsruudi ja teenuse enda. Käivitage need tunneliga üleval ja uuesti sellega maas:

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

Neli eraldi välja löövad ühe boolean, sest olek, DNS, marsruut ja põhimõte nurjuvad sõltumatult ning maanduvad erinevatesse meeskondadesse. Ping terminalis jääb heaks käsitsi mõistlikkuse kontrolliks. Automatiseerimise jaoks on see halb ühenduse määratlus, kus platvormi API ja marsruuditest vastavad tegelikule küsimusele.