Kiel kontroli VPN-statuson sen ping ĉe Android, iOS kaj Windows

Ping pruvas nur, ke unu gastigo respondis, ne ke la tunelo funkcias. Demandu la statusajn API-ojn de Android, iOS kaj Windows, poste kontrolu la itineron, kiun via aplikaĵo vere bezonas.

Pingi 192.0.2.10 diras al vi, ke unu adreso respondis al ICMP-echo, kaj tio estas ĉio. En reto sen tunelo ĝi povas ankoraŭ sukcesi, ĉar la adreso povas troviĝi en la loka subreto; kun sana tunelo ĝi povas malsukcesi, ĉar la servilo forĵetas ICMP dum ĝi servas HTTPS. La kontrolo, kiun via skripto bezonas, estas statusdemando de la platformo plus itinertesto por la celo, kiun la aplikaĵo uzas. Traktu ilin kiel du apartajn kampojn, neniam kiel unu boolean.

Kion respondo al echo vere pruvas

ICMP estas protokolo de atingeblo sen nocio pri interfacoj aŭ tuneloj. Kiam respondo alvenas, la kerno raportas, ke gastigo respondis; ĝi ne raportas, kiun itineron portis la peton aŭ la respondon. Filtrado igas la signalon eĉ pli brua, ĉar fajroŝirmilo, kiu blokas echo-petojn, diras nenion pri la pordoj malantaŭ ĝi. Kaj profilo kun dividita tunelo povas intence ekskludi la testitan adreson, dum ĉiu alia celo funkcias.

Kion vi vere volas scii, estas ĉu difinita servo estas uzebla laŭ la vojo, kiun la aplikaĵo prenas. Elektu la gastigon kaj pordon, kiujn la aplikaĵo vokas, poste postulu respondon ĉe la aplikaĵ-nivelo.

Atingeblo kaj tunela stato estas malsamaj faktoj, kaj ĉiu el ili povas esti vera dum la alia estas malvera. Teni ilin apartaj diras al vi, al kiu apartenas la paneo. Kunfandi ilin en unu kontrolon produktas bileton, kiun neniu povas itinerigi.

Demandu Android pri la transporto, ne pri ping

Android respondas la statusdemandon rekte per ConnectivityManager. La kapabloj de la aktiva reto portas flagon de VPN-transporto, kiu estas agordata kiam trafiko estas itinerigita tra VPN-interfaco. La voko estas loka, malmultekosta kaj sendependa de tio, ĉu iu fora gastigo respondas.

Ĉi tiu Java-versio redonas false anstataŭ ĵeti escepton kiam ne estas aktiva reto. Ĉar ĝi legas la aktivan reton, ĝi spegulas la profilon, kiun la uzanto elektis en Agordoj.

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

Por sciigoj pri ŝanĝoj, registru NetworkCallback anstataŭ enketi per tempigilo. Ne konfuzu tion kun VpnService.prepare, kiu nur raportas, ĉu la uzanto permesis VPN, ne ĉu pakaĵoj fluas. Revoko alvenas per VpnService.onRevoke, sed forgesi profilon en Agordoj tute ne produktas dissendon.

iOS: interfacaj nomoj estas heŭristiko, ne kontrakto

Multaj iOS-fragmentoj ekzamenas la prokseajn agordojn, trovas la vortaron __SCOPED__ kaj serĉas interfacajn ŝlosilojn kiel tap, tun, utun2, ppp aŭ ipsec. Tiu aliro estas nomiga konvencio, ne dokumentita garantio, do ĝisdatigo de la operaciumo, kiu renomas interfacon, povas rompi ĝin. Ĝi ankaŭ emas raporti veron por malnovaj enskriboj, kiuj postvivas la tunelon.

Kiam via aplikaĵo posedas la agordon, NEVPNManager donas al vi veran statuson. Ĝi priskribas la tunelon, kiun via aplikaĵo lanĉis; kun VPN por unuopa aplikaĵo, aliaj aplikaĵoj povas resti tute ekster tiu tunelo.

Reŝargu la preferojn antaŭ ol legi la statuson, ĉar la valoro ŝanĝiĝas dum la tunelo venas kaj foriras:

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

Platforma statusflago ankoraŭ ne pruvas, ke trafiko atingas la kunulon. Tiun breĉon kovras la itinertesto, kaj tial unu boolean ne sufiĉas por subteno.

Windows-profiloj montras veran statuskampon

Windows spuras VPN-profilojn aparte de adaptiloj, kaj Get-VpnConnection montras ConnectionStatus por ĉiu konata profilo. Profiloj kreitaj per la Windows-kliento aŭ provizpakaĵo aperas ĉi tie. La cmdlet ne estas ĝenerala tuneldetektilo.

Legu la kampon por nomita profilo, aldonante -AllUserConnection kiam la profilo apartenas al ĉiuj uzantoj:

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

Tripersonaj klientoj ofte restas nevideblaj al ĉi tiu cmdlet eĉ dum ilia tunelo funkcias, do malplena rezulto signifas nekonatan, ne malkonektitan. Adaptilaj listoj same trompas: vendista adaptilo povas daŭri dum ĝi estas senokupa, kaj kelkaj adaptiloj ekzistas nur dum sesio. Por profilo, kiun Windows posedas, rasdial raportas elirkodon, sur kiun vi povas branĉi. Ĉio ĉi priskribas lokan kredon, ne atingeblon de la kunulo.

Statuso plus itinero: la dutupa kontrolo

Konektita profilo diras nenion pri tio, kien pakaĵoj iras. Dividita tunelo povas teni la tunelon supren dum ĝi ekskludas la celon, pri kiu vi zorgas. Always-on-profiloj restas konektitaj al morta servilo, kaj kill switch intence blokas trafikon kiam la tunelo falas.

Testu ambaŭ tavolojn: konfirmu, ke VPN-transporto aŭ profilo estas aktiva, poste ke la celo solviĝas kaj respondas laŭ tiu vojo. En Linux, demandu la kernon, kiun interfacon ĝi uzus:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Kiam la kliento estas ekster via kontrolo, protokolu ambaŭ rezultojn kaj lasu la ŝablonon montri la tavolon. Konektita plus malsukcesa itinertesto sugestas dividitan tunelon, DNS aŭ regularon. Malkonektita plus funkcianta itinertesto signifas, ke alia vojo portas la trafikon.

Testo, kiun vi povas ruli laŭorde

Unue registru la platforman statuson, antaŭ ol vi ŝanĝi iun ajn retan staton. Solvu la gastigan nomon kaj notu la adresan familion, ĉar AAAA-enskribo povas preni alian vojon ol A-enskribo. Malfermu la pordon de la servo kaj postulu aplikaĵan respondon anstataŭ nura manpremo. Tenu ĉiun observon en sia propra protokola kampo.

Sur Linux-maŝino kun dig kaj curl, tri komandoj kovras solvon, itineron kaj la servon mem. Rulu ilin kun la tunelo supren kaj denove kun ĝi malsupren:

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

Kvar apartaj kampoj venkas unu boolean, ĉar statuso, DNS, itinero kaj regularo paneas sendepende kaj finiĝas ĉe malsamaj teamoj. Ping en terminalo restas bona permana sanokontrolo. Ĝi estas malbona difino de konekteco por aŭtomatigo, kie la platforma API kaj itinertesto respondas la veran demandon.

Rilataj artikoloj