Si të kontrolloni statusin e VPN pa ping në Android, iOS dhe Windows
Ping dëshmon vetëm se një host u përgjigj, jo se tuneli është aktiv. Pyetni API-të e statusit të Android, iOS dhe Windows, pastaj verifikoni rrugën që aplikacioni juaj ka vërtet nevojë.
Ping drejt 192.0.2.10 ju tregon vetëm se një adresë u përgjigj ndaj një ekoje ICMP, dhe asgjë më shumë. Në një rrjet pa tunel mund të ketë sukses gjithsesi, sepse adresa mund të jetë në nënrrjetin lokal; me një tunel të shëndetshëm mund të dështojë, sepse serveri hedh poshtë ICMP ndërsa shërben HTTPS. Kontrolli që i nevojitet skriptit tuaj është një pyetje për statusin e platformës plus një test rruge drejt destinacionit që përdor aplikacioni. Trajtojini si dy fusha të veçanta, kurrë si një vlerë logjike të vetme.
Çfarë dëshmon vërtet një përgjigje ekoje
ICMP është një protokoll arritshmërie që nuk ka nocion të ndërfaqeve ose tuneleve. Kur mbërrin një përgjigje, kerneli raporton se një host u përgjigj; nuk raporton cila rrugë e barti kërkesën dhe as cila e barti përgjigjen. Filtrimi e bën sinjalin edhe më të zhurmshëm, sepse një firewall që bllokon kërkesat eko nuk thotë asgjë për portat pas tij. Dhe një profil me tunel të ndarë mund të përjashtojë me qëllim adresën e testuar ndërsa të gjitha destinacionet e tjera funksionojnë.
Ajo që ju vërtet dëshironi të dini është nëse një shërbim i caktuar është i përdorshëm në rrugën që ndjek aplikacioni. Zgjidhni hostin dhe portin që thërret aplikacioni, pastaj kërkoni një përgjigje në shtresën e aplikacionit.
Arritshmëria dhe statusi i tunelit janë fakte të ndryshme, dhe njëri mund të jetë i vërtetë ndërsa tjetri i rremë. T'i mbash të ndara të thotë kujt i përket dështimi. T'i bashkosh në një kontroll të vetëm prodhon një biletë që askush nuk mund ta drejtojë.
Pyetni Android-in për transportin, jo për ping
Android-i i përgjigjet drejtpërdrejt pyetjes së statusit përmes ConnectivityManager. Aftësitë e rrjetit aktiv mbajnë një flamur transporti VPN, i cili vendoset kur trafiku drejtohet përmes një ndërfaqeje VPN. Thirrja është lokale, e lirë dhe e pavarur nga fakti nëse ndonjë host i largët përgjigjet.
Ky version Java kthen false në vend që të hedhë një përjashtim kur nuk ka rrjet aktiv. Meqenëse lexon rrjetin aktiv, pasqyron profilin që përdoruesi zgjodhi në Cilësimet.
ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);
Për njoftimet e ndryshimit, regjistroni një NetworkCallback në vend që të pyesni me një kohëmatës. Mos e ngatërroni atë me VpnService.prepare, i cili raporton vetëm nëse përdoruesi dha leje për VPN, jo nëse paketat po rrjedhin. Anulimi vjen përmes VpnService.onRevoke, por harresa e një profili në Cilësimet nuk prodhon asnjë transmetim.
iOS: emrat e ndërfaqeve janë një heuristikë, jo një kontratë
Shumë fragmente iOS inspektojnë cilësimet e proxy-t, gjejnë fjalorin __SCOPED__ dhe kërkojnë çelësa ndërfaqeje si tap, tun, utun2, ppp ose ipsec. Ky qasje është një konventë emërtimi, jo një garanci e dokumentuar, kështu që një përditësim i sistemit që riemërton një ndërfaqe mund ta thyejë atë. Gjithashtu, ka tendencë të raportojë true për zëra të vjetruar që mbijetojnë tunelin.
Kur aplikacioni juaj zotëron konfigurimin, NEVPNManager jep një status të vërtetë. Ai përshkruan tunelin që nisi aplikacioni juaj; me një VPN për aplikacion, aplikacionet e tjera mund të qëndrojnë plotësisht jashtë atij tuneli.
Ringarkoni preferencat përpara se të lexoni statusin, sepse vlera ndryshon ndërsa tuneli ngrihet dhe zbret:
let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
let up = manager.connection.status == .connected
print(up)
}
Flamuri i statusit të platformës prapë nuk dëshmon se trafiku arrin te piri. Pikërisht atë boshllëk mbulon testi i rrugës, dhe për këtë arsye një vlerë logjike nuk mjafton për mbështetjen.
Profilet e Windows zbulojnë një fushë të vërtetë statusi
Windows i ndjek profilet VPN veçmas nga përshtatësit, dhe Get-VpnConnection zbulon një ConnectionStatus për çdo profil që njeh. Këtu shfaqen profilet e krijuara përmes klientit Windows ose një pakete furnizimi. Ky cmdlet nuk është një zbulues i përgjithshëm tunelesh.
Lexoni fushën për një profil me emër, duke shtuar -AllUserConnection kur profili u përket të gjithë përdoruesve:
Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress
Klientët e palëve të treta shpesh mbeten të padukshëm për këtë cmdlet edhe kur tuneli i tyre është aktiv, kështu që një rezultat bosh do të thotë i panjohur, jo i shkëputur. Edhe listat e përshtatësve mashtrojnë njësoj: një përshtatës i furnizuesit mund të vazhdojë ndërsa është i papunë, dhe disa përshtatës ekzistojnë vetëm gjatë një sesioni. Për një profil që Windows zotëron, rasdial raporton një kod daljeje mbi të cilin mund të degëzoni. Të gjitha këto përshkruajnë një besim lokal, jo arritshmërinë e pirit.
Status plus rrugë: kontrolli në dy pjesë
Një profil i lidhur nuk thotë asgjë për atë se ku shkojnë paketat. Tuneli i ndarë mund ta mbajë tunelin aktiv duke përjashtuar destinacionin që ju intereson. Profilet always-on mbeten të lidhura me një server të vdekur, dhe një kill switch bllokon qëllimisht trafikun kur tuneli bie.
Testoni të dy shtresat: konfirmoni se një transport VPN ose profil është aktiv, pastaj konfirmoni se destinacioni zgjidhet dhe përgjigjet përgjatë asaj rruge. Në Linux, pyetni kernelin se cilën ndërfaqe do të përdorte:
ip route get 192.0.2.10
resolvectl query intranet.example.test
Kur klienti është jashtë kontrollit tuaj, regjistroni të dy rezultatet dhe lini modelin të tregojë shtresën. I lidhur plus një test rruge i dështuar sugjeron tunel të ndarë, DNS ose politikë. I shkëputur plus një test rruge që funksionon do të thotë se një rrugë tjetër po e barti trafikun.
Një test që mund ta ekzekutoni me radhë
Regjistroni fillimisht statusin e platformës, përpara se të ndryshoni çdo gjendje rrjeti. Zgjidhni emrin e hostit dhe shënoni familjen e adresave, sepse një regjistrim AAAA mund të ndjekë një rrugë të ndryshme nga një regjistrim A. Hapni portin e shërbimit dhe kërkoni një përgjigje aplikacioni në vend të një shtrëngimi duarsh të thjeshtë. Mbani çdo vëzhgim në fushën e tij të regjistrit.
Në një makinë Linux me dig dhe curl, tre komanda mbulojnë zgjidhjen, rrugën dhe vetë shërbimin. Ekzekutoni ato me tunelin lart dhe përsëri me atë poshtë:
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
Katër fusha të veçanta mundin një vlerë logjike, sepse statusi, DNS, rruga dhe politika dështojnë në mënyrë të pavarur dhe përfundojnë në ekipe të ndryshme. Një ping në terminal mbetet një kontroll i mirë manual. Është një përkufizim i dobët i lidhshmërisë për automatizimin, ku API i platformës dhe një test rruge i përgjigjen pyetjes së vërtetë.