Paano suriin ang katayuan ng VPN nang walang ping sa Android, iOS at Windows

Ang pag-ping sa 192.0.2.10 ay nagsasabi lamang na may isang address na sumagot sa ICMP echo, at wala nang iba. Sa network na walang tunel matatagumpayan pa rin ito, dahil ang address ay maaaring nasa lokal na subnet; sa malusog na tunel maaari itong mabigo, dahil itinatapon ng server ang ICMP habang naghahain ng HTTPS. Ang pagsusuring kailangan ng iyong script ay isang pagtatanong sa katayuan ng platform at isang pagsubok sa ruta patungo sa destinasyong ginagamit ng app. Ituring ang mga ito na dalawang magkahiwalay na field, hindi kailanman bilang isang boolean.

Ano ang tunay na pinatutunayan ng tugon sa echo

Ang ICMP ay isang protocol ng maabot na katayuan na walang konsepto ng mga interface o tunel. Kapag may tugon na dumating, iniuulat ng kernel na may host na sumagot; hindi nito iniuulat kung aling ruta ang nagdala ng kahilingan o kung alin ang nagdala ng tugon. Ang pag-filter ay ginagawang mas maingay pa ang senyales, dahil ang firewall na humaharang sa mga kahilingang echo ay walang sinasabi tungkol sa mga port sa likod nito. At ang profile na may hatiin na tunel ay maaaring sadyang ibukod ang sinubok na address habang gumagana ang lahat ng iba pang destinasyon.

Ang talagang gusto mong malaman ay kung magagamit ang isang partikular na serbisyo sa rutang tinatahak ng app. Piliin ang host at port na tinatawag ng app, pagkatapos ay hilingin ang tugon sa antas ng aplikasyon.

Ang maabot na katayuan at katayuan ng tunel ay magkaibang katotohanan, at ang isa ay maaaring totoo habang ang isa ay hindi. Ang paghiwalay sa kanila ay nagsasabi kung kanino ang pagkabigo. Ang pagsasama sa isang pagsusuri ay gumagawa ng ticket na walang makapagruruta.

Tanungin ang Android tungkol sa transportasyon, hindi sa ping

Direktang sinasagot ng Android ang tanong sa katayuan sa pamamagitan ng ConnectivityManager. Ang mga kakayahan ng aktibong network ay may flag ng transportasyong VPN, na itinatakda kapag ang trapiko ay pinapasa sa isang interface ng VPN. Lokal ang tawag, mura, at independiyente sa kung may tumutugon na remote host.

Ang bersyon ng Java na ito ay nagbabalik ng false sa halip na maghagis ng exception kapag walang aktibong network. Dahil binabasa nito ang aktibong network, sinasalamin nito ang profile na pinili ng user sa Settings.

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

Para sa mga abiso ng pagbabago, magrehistro ng NetworkCallback sa halip na mag-poll gamit ang timer. Huwag itong ipagkamali sa VpnService.prepare, na nagsasabi lamang kung nagbigay ng pahintulot ang user para sa VPN, hindi kung dumadaloy ang mga packet. Ang pagbawi ay dumarating sa pamamagitan ng VpnService.onRevoke, ngunit ang pagkalimot sa isang profile sa Settings ay walang dulot na anumang broadcast.

iOS: ang mga pangalan ng interface ay haka-haka, hindi kontrata

Maraming snippet ng iOS ang sumusuri sa mga setting ng proxy, hinahanap ang __SCOPED__ na diksyunaryo at hinahanap ang mga key ng interface tulad ng tap, tun, utun2, ppp o ipsec. Ang paraang iyon ay isang kombensyon sa pagpapangalan, hindi isang dokumentadong garantiya, kaya ang update ng OS na magpapalit ng pangalan ng interface ay maaaring makasira nito. May tendensiya rin itong mag-ulat ng true para sa mga lumang entry na mas matagal kaysa sa tunel.

Kapag pag-aari ng iyong app ang configuration, ang NEVPNManager ay nagbibigay ng tunay na katayuan. Inilalarawan nito ang tunel na sinimulan ng iyong app; sa VPN bawat app, ang ibang app ay maaaring nasa labas mismo ng tunel na iyon.

I-reload ang mga kagustuhan bago basahin ang katayuan, dahil nagbabago ang halaga habang pumapaitaas at pababa ang tunel:

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

Ang flag ng katayuan ng platform ay hindi pa rin nagpapatunay na naaabot ng trapiko ang peer. Ang puwang na iyon ang sinasaklaw ng pagsubok sa ruta, at iyon ang dahilan kung bakit hindi sapat ang isang boolean para sa suporta.

Ang mga profile ng Windows ay naglalantad ng tunay na field ng katayuan

Sinusubaybayan ng Windows ang mga profile ng VPN nang hiwalay sa mga adapter, at ang Get-VpnConnection ay naglalantad ng ConnectionStatus para sa bawat profile na kilala nito. Dito lumilitaw ang mga profile na ginawa sa pamamagitan ng Windows client o provisioning package. Ang cmdlet na ito ay hindi pangkalahatang detektor ng tunel.

Basahin ang field para sa pinangalanang profile, at idagdag ang -AllUserConnection kapag pag-aari ng lahat ng user ang profile:

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

Ang mga third-party na client ay madalas na nananatiling hindi nakikita ng cmdlet na ito kahit gumagana ang kanilang tunel, kaya ang walang laman na resulta ay nangangahulugang hindi alam, hindi disconnected. Parehong nakakapanlinlang ang mga listahan ng adapter: ang adapter ng vendor ay maaaring manatili habang idle, at ang ilang adapter ay umiiral lamang sa panahon ng session. Para sa profile na pag-aari ng Windows, ang rasdial ay nag-uulat ng exit code na maaari mong sangahan. Inilalarawan ng lahat ng ito ang lokal na paniniwala, hindi ang maabot na katayuan ng peer.

Katayuan at ruta: ang pagsusuring may dalawang bahagi

Ang konektadong profile ay walang sinasabi tungkol sa kung saan pumupunta ang mga packet. Ang hatiin na tunel ay maaaring panatilihing aktibo ang tunel habang ibinubukod ang destinasyong mahalaga sa iyo. Ang mga always-on na profile ay nananatiling konektado sa patay na server, at ang kill switch ay sadyang humaharang sa trapiko kapag bumagsak ang tunel.

Subukan ang parehong antas: kumpirmahin na aktibo ang transportasyong VPN o profile, pagkatapos ay kumpirmahin na nare-resolve at tumutugon ang destinasyon sa rutang iyon. Sa Linux, tanungin ang kernel kung aling interface ang gagamitin nito:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Kapag nasa labas ng iyong kontrol ang client, i-log ang parehong resulta at hayaang ituro ng pattern ang antas. Konektado at nabigong pagsubok sa ruta ay nagmumungkahi ng hatiin na tunel, DNS o patakaran. Disconnected at gumaganang pagsubok sa ruta ay nangangahulugang may ibang rutang nagdadala ng trapiko.

Isang pagsubok na maaari mong patakbuhin nang sunud-sunod

Itala muna ang katayuan ng platform, bago mo baguhin ang anumang estado ng network. I-resolve ang hostname at itala ang pamilya ng address, dahil ang rekord ng AAAA ay maaaring tumahak ng ibang ruta kaysa sa rekord ng A. Buksan ang port ng serbisyo at hilingin ang tugon ng aplikasyon sa halip na basta pakikipagkamay. Itago ang bawat obserbasyon sa sarili nitong field ng log.

Sa isang Linux machine na may dig at curl, tatlong utos ang sumasaklaw sa resolution, ruta at ang serbisyo mismo. Patakbuhin ang mga ito habang nakataas ang tunel at muli kapag nakababa:

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

Apat na magkahiwalay na field ay nananalo sa isang boolean, dahil ang katayuan, DNS, ruta at patakaran ay nabibigo nang independiyente at napupunta sa magkaibang team. Ang ping sa terminal ay nananatiling mabuting manu-manong pagsusuri. Mahinang kahulugan ito ng konektibidad para sa automation, kung saan ang API ng platform at ang pagsubok sa ruta ang sumasagot sa tunay na tanong.