Hvernig á að athuga stöðu VPN án ping í Android, iOS og Windows

Að pinga 192.0.2.10 segir þér aðeins að eitt vistfang hafi svarað ICMP bergmáli, og ekkert meira. Á neti án ganga getur það samt tekist, því vistfangið getur verið á staðbundnu undirneti; með heilbrigðum göngum getur það mistekist, því þjónninn hendir ICMP þegar hann þjónar HTTPS. Athugunin sem skriftan þín þarf er stöðufyrirspurn vettvangsins auk leiðarprófunar að áfangastaðnum sem forritið notar. Líttu á þær sem tvo aðskilda reiti, aldrei sem eitt bóleangildi.

Hvað bergmálssvar sannar í raun

ICMP er aðgengisregla sem þekkir hvorki tengi né göng. Þegar svar berst tilkynnir kjarninn að einn vélarþjónn hafi svarað; hann tilkynnir ekki hvaða leið bar beiðnina og hvaða leið bar svarið. Sía gerir merkið hávaðasamara enn, því eldveggur sem lokar bergmálsbeiðnum segir ekkert um tengin á bak við sig. Og snið með skiptum göngum getur viljandi útilokað prófaða vistfangið á meðan allir aðrir áfangastaðir virka.

Það sem þú vilt í raun vita er hvort tiltekin þjónusta sé nothæf á þeirri leið sem forritið fer. Veldu vélarþjóninn og tengið sem forritið kallar á, og krefstu þá svars á forritalaginu.

Aðgengi og staða ganga eru mismunandi staðreyndir, og hvor um sig getur verið sönn á meðan hin er ósönn. Að halda þeim aðskildum segir þér hver á bilunina. Að steypa þeim í eina athugun framleiðir miða sem enginn getur beint.

Spurðu Android um flutninginn, ekki um ping

Android svarar stöðuspurningunni beint gegnum ConnectivityManager. Geta virka netsins ber VPN-flutningsfána sem er settur þegar umferð er beint gegnum VPN-tengi. Kallið er staðbundið, ódýrt og óháð því hvort fjarlægur vélarþjónn svarar.

Þessi Java-útgáfa skilar false í stað þess að kasta undantekningu þegar ekkert virkt net er. Þar sem hún les virka netið endurspeglar hún sniðið sem notandinn valdi í Stillingum.

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

Fyrir tilkynningar um breytingar skaltu skrá NetworkCallback í stað þess að spyrja á tímatakka. Ekki rugla því saman við VpnService.prepare, sem aðeins segir hvort notandinn veitti VPN-heimild, ekki hvort pakkar streyma. Afturköllun kemur gegnum VpnService.onRevoke, en að gleyma sniði í Stillingum framkallar alls enga útsendingu.

iOS: tengisnöfn eru nálgun, ekki samningur

Mörg iOS-brot skoða proxy-stillingarnar, finna __SCOPED__ orðabókina og leita að tengilyklum eins og tap, tun, utun2, ppp eða ipsec. Sú nálgun er nafnvenja, ekki skjalfest ábyrgð, svo uppfærsla stýrikerfis sem endurnefnir tengi getur brotið hana. Hún hefur einnig tilhneigingu til að tilkynna true fyrir úreltar færslur sem lifa göngin.

Þegar forritið þitt á stillingarnar gefur NEVPNManager raunverulega stöðu í staðinn. Hann lýsir göngunum sem forritið þitt ræsti; með VPN á hvert forrit geta önnur forrit staðið algjörlega utan þeirra ganga.

Hladdu valkostunum aftur áður en þú lest stöðuna, því gildið breytist þegar göngin koma og fara:

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

Stöðufáni vettvangsins sannar samt ekki að umferð nái jafningjanum. Það bil er það sem leiðarprófunin nær yfir, og þess vegna er eitt bóleangildi ekki nóg fyrir stuðning.

Windows-snið sýna raunverulegan stöðureit

Windows fylgist með VPN-sniðum aðskildum frá millistykjum, og Get-VpnConnection sýnir ConnectionStatus fyrir hvert snið sem það þekkir. Snið búin til með Windows-biðlaranum eða uppsetningarpakka birtast hér. Cmdletið er ekki almennur gangaskynjari.

Lestu reitinn fyrir nefnt snið og bættu -AllUserConnection við þegar sniðið tilheyrir öllum notendum:

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

Biðlarar þriðja aðila eru oft ósýnilegir þessu cmdleti jafnvel þegar göngin þeirra eru uppi, svo tóm útkoma þýðir óþekkt, ekki aftengt. Millistykjalistar villa jafn mikið: millistykki framleiðanda getur varað á meðan það er aðgerðalaust, og sum millistykki eru aðeins til meðan á lotu stendur. Fyrir snið sem Windows á tilkynnir rasdial útgangskóða sem þú getur greint á. Allt þetta lýsir staðbundinni trú, ekki aðgengi jafningjans.

Staða plús leið: athugunin í tveimur hlutum

Tengt snið segir ekkert um hvert pakkarnir fara. Skipt göng geta haldið göngunum uppi á meðan þau útiloka áfangastaðinn sem þér er annt um. always-on snið vera tengd við dauðan þjón, og kill switch lokar umferð viljandi þegar göngin falla.

Prófaðu bæði lögin: staðfestu að VPN-flutningur eða snið sé virkt, staðfestu svo að áfangastaðurinn leysist og svari eftir þeirri leið. Í Linux skaltu spyrja kjarnann hvaða tengi hann myndi nota:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Þegar biðlarinn er utan þíns valds skaltu skrá báðar útkomur og láta mynstrið benda á lagið. Tengt plús misheppnuð leiðarprófun bendir til skiptra ganga, DNS eða stefnu. Aftengt plús leiðarprófun sem virkar þýðir að önnur leið ber umferðina.

Prófun sem þú getur keyrt í röð

Skráðu stöðu vettvangsins fyrst, áður en þú breytir nokkru netástandi. Leystu vélarþjónsnafnið og taktu eftir vistfangafjölskyldunni, því AAAA-færsla getur farið aðra leið en A-færsla. Opnaðu þjónustutengið og krefstu forritssvars frekar en bert handaband. Haltu hverri athugun í eigin loggreit.

Á Linux-vél með dig og curl ná þrjár skipanir yfir upplausn, leið og þjónustuna sjálfa. Keyrðu þær með göngin uppi og aftur þegar þau eru niðri:

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

Fjórir aðskildir reitir vinna á eitt bóleangildi, því staða, DNS, leið og stefna mistakast óháð og lenda hjá mismunandi teymum. Ping í skjáhermi er áfram góð handvirk skynsemisathugun. Það er léleg skilgreining á tengingu fyrir sjálfvirkni, þar sem API vettvangsins og leiðarprófun svara raunverulegu spurningunni.