VPN-yhteyden tilan tarkistaminen ilman pingiä Androidissa, iOS:ssä ja Windowsissa

Pingaus osoitteeseen 192.0.2.10 kertoo, että yksi osoite vastasi ICMP-kaikuun, eikä mitään muuta. Verkossa ilman tunnelia se voi silti onnistua, koska osoite voi olla paikallisessa aliverkossa; terveen tunnelin kanssa se voi epäonnistua, koska palvelin pudottaa ICMP:n samalla kun se palvelee HTTPS:ää. Tarkistus, jonka komentosarjasi tarvitsee, on alustan tilakysely sekä reittitesti sille kohteelle, jota sovellus käyttää. Käsittele niitä kahtena erillisenä kenttänä, älä koskaan yhtenä booleanina.

Mitä kaiun vastaus todella todistaa

ICMP on tavoitettavuusprotokolla, jolla ei ole käsitystä liittymistä tai tunneleista. Kun vastaus saapuu, ydin ilmoittaa, että isäntä vastasi; se ei kerro, mikä reitti kuljetti pyynnön tai vastauksen. Suodatus tekee signaalista vielä kohinaisemman, koska kaikupyyntöjä estävä palomuuri ei kerro mitään sen takana olevista porteista. Ja jaetun tunnelin profiili voi jättää testatun osoitteen tarkoituksella pois, kun kaikki muut kohteet toimivat.

Se mitä todella haluat tietää, onko tietty palvelu käytettävissä sitä polkua pitkin, jonka sovellus valitsee. Valitse isäntä ja portti, jota sovellus kutsuu, ja vaadi sitten vastaus sovelluskerroksessa.

Tavoitettavuus ja tunnelin tila ovat eri tosiasioita, ja kumpi tahansa voi olla tosi, kun toinen on epätosi. Niiden erillään pitäminen kertoo, kenen vika se on. Niiden sulauttaminen yhdeksi tarkistukseksi tuottaa lipun, jota kukaan ei voi reitittää.

Kysy Androidilta siirtotiestä, älä pingistä

Android vastaa tilakysymykseen suoraan ConnectivityManagerin kautta. Aktiivisen verkon ominaisuudet kantavat VPN-siirtotien lippua, joka asetetaan, kun liikenne reititetään VPN-liittymän kautta. Kutsu on paikallinen, halpa ja riippumaton siitä, vastaako mikään etäinen isäntä.

Tämä Java-versio palauttaa false sen sijaan, että heittäisi poikkeuksen, kun aktiivista verkkoa ei ole. Koska se lukee aktiivista verkkoa, se heijastaa profiilia, jonka käyttäjä valitsi Asetuksissa.

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

Muutosilmoituksia varten rekisteröi NetworkCallback sen sijaan, että kyselisit ajastimella. Älä sekoita sitä VpnService.prepareen, joka kertoo vain, antoiko käyttäjä VPN-luvan, ei sitä virtaavatko paketit. Peruutus tulee VpnService.onRevoken kautta, mutta profiilin unohtaminen Asetuksissa ei tuota lainkaan lähetystä.

iOS: liittymien nimet ovat heuristiikka, eivät sopimus

Monet iOS-katkelmat tutkivat välityspalvelinasetuksia, löytävät __SCOPED__-sanakirjan ja etsivät liittymäavaimia kuten tap, tun, utun2, ppp tai ipsec. Se lähestymistapa on nimeämiskäytäntö, ei dokumentoitu tae, joten liittymän uudelleennimeävä käyttöjärjestelmäpäivitys voi rikkoa sen. Se myös ilmoittaa herkästi tosi vanhentuneille merkinnöille, jotka elävät tunnelin ohi.

Kun sovelluksesi omistaa kokoonpanon, NEVPNManager antaa todellisen tilan. Se kuvaa tunnelin, jonka sovelluksesi käynnisti; sovelluskohtaisella VPN:llä muut sovellukset voivat olla kokonaan tuon tunnelin ulkopuolella.

Lataa asetukset uudelleen ennen tilan lukemista, koska arvo muuttuu tunnelin tullessa ja mennessä:

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

Alustan tilalippu ei silti todista, että liikenne saavuttaa vertaisen. Juuri sen aukon reittitesti kattaa, ja siksi yksi boolean ei riitä tukea varten.

Windowsin profiilit tarjoavat todellisen tilakentän

Windows seuraa VPN-profiileja erillään sovittimista, ja Get-VpnConnection näyttää ConnectionStatusin jokaiselle tuntemalleen profiilille. Windows-asiakkaan tai valmistelupaketin kautta luodut profiilit näkyvät täällä. Cmdlet ei ole yleinen tunnelinilmaisin.

Lue kenttä nimetylle profiilille ja lisää -AllUserConnection, kun profiili kuuluu kaikille käyttäjille:

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

Kolmannen osapuolen asiakkaat jäävät usein näkymättömiksi tälle cmdletille, vaikka niiden tunneli olisi päällä, joten tyhjä tulos tarkoittaa tuntematonta, ei irrotettua. Sovitinluettelot johtavat yhtä lailla harhaan: toimittajan sovitin voi säilyä joutilaana, ja jotkut sovittimet ovat olemassa vain istunnon ajan. Profiilille, jonka Windows omistaa, rasdial ilmoittaa poistumiskoodin, jonka perusteella voi haarautua. Kaikki tämä kuvaa paikallista uskomusta, ei vertaisen tavoitettavuutta.

Tila plus reitti: kaksiosainen tarkistus

Yhdistetty profiili ei kerro mitään siitä, mihin paketit menevät. Jaettu tunneli voi pitää tunnelin päällä ja jättää silti pois kohteen, josta välität. Always-on-profiilit pysyvät yhdistettyinä kuolleeseen palvelimeen, ja kill switch estää liikennettä tarkoituksella, kun tunneli putoaa.

Testaa molemmat kerrokset: varmista, että VPN-siirtotie tai profiili on aktiivinen, ja sitten että kohde ratkeaa ja vastaa tuota polkua pitkin. Linuxissa kysy ytimeltä, mitä liittymää se käyttäisi:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Kun asiakas on hallintasi ulkopuolella, kirjaa molemmat tulokset ja anna kuvion osoittaa kerrokseen. Yhdistetty plus epäonnistunut reittitesti viittaa jaettuun tunneliin, DNS:ään tai käytäntöön. Irrotettu plus toimiva reittitesti tarkoittaa, että toinen polku kuljettaa liikennettä.

Testi, jonka voit ajaa järjestyksessä

Kirjaa ensin alustan tila ennen kuin muutat mitään verkkotilaa. Ratkaise isäntänimi ja merkitse osoiteperhe, koska AAAA-tietue voi kulkea eri polkua kuin A-tietue. Avaa palvelun portti ja vaadi sovellusvastaus pelkän kättelyn sijaan. Pidä jokainen havainto omassa lokikentässään.

Linux-koneella, jossa on dig ja curl, kolme komentoa kattavat ratkaisun, reitin ja itse palvelun. Aja ne tunnelin ollessa päällä ja uudelleen sen ollessa alhaalla:

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

Neljä erillistä kenttää voittaa yhden booleanin, koska tila, DNS, reitti ja käytäntö pettävät toisistaan riippumatta ja päätyvät eri tiimeille. Päätepäätteessä ajettu ping on edelleen hyvä manuaalinen järkytarkistus. Automaatioon se on huono yhteyden määritelmä, koska siellä alustan API ja reittitesti vastaavat varsinaiseen kysymykseen.