Kako provjeriti status VPN-a bez pinga na Androidu, iOS-u i Windowsu

Ping na 192.0.2.10 kaže samo da je jedna adresa odgovorila na ICMP odjek i ništa više. Na mreži bez tunela može ipak uspjeti jer se adresa može nalaziti na lokalnoj podmreži; uz zdrav tunel može i pasti jer poslužitelj odbacuje ICMP dok poslužuje HTTPS. Provjera koju vaša skripta treba jest upit o statusu platforme plus test rute prema odredištu koje aplikacija koristi. Tretirajte ih kao dva odvojena polja, nikada kao jedan boolean.

Što odgovor na odjek doista dokazuje

ICMP je protokol dostupnosti koji ne poznaje sučelja ni tunele. Kad odgovor stigne, kernel javlja da je neki host odgovorio; ne javlja kojom je rutom otišao zahtjev ni kojom je stigao odgovor. Filtriranje signal čini još šumnijim jer vatrozid koji blokira odjek zahtjeve ne govori ništa o priključcima iza sebe. A profil s podijeljenim tunelom može namjerno izuzeti testiranu adresu dok sva ostala odredišta rade.

Ono što zapravo želite znati jest je li određena usluga upotrebljiva putem rute kojom aplikacija prolazi. Odaberite host i priključak koje aplikacija poziva, pa zahtijevajte odgovor na aplikacijskom sloju.

Dostupnost i stanje tunela različite su činjenice i jedna može biti istinita dok je druga lažna. Ako ih držite odvojeno, znate kome pripada kvar. Ako ih spojite u jednu provjeru, dobivate tiket koji nitko ne može usmjeriti.

Pitajte Android za transport, ne za ping

Android izravno odgovara na pitanje o statusu preko ConnectivityManager. Sposobnosti aktivne mreže nose zastavicu VPN transporta, postavljenu kad se promet usmjerava kroz VPN sučelje. Poziv je lokalan, jeftin i neovisan o tome odgovara li neki udaljeni host.

Ova Java verzija vraća false umjesto da baci iznimku kad nema aktivne mreže. Budući da čita aktivnu mrežu, odražava profil koji je korisnik odabrao u Postavkama.

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

Za obavijesti o promjenama registrirajte NetworkCallback umjesto da anketirate po timeru. Nemojte to miješati s VpnService.prepare koji samo javlja je li korisnik dao dopuštenje za VPN, ne teku li paketi. Opoziv dolazi kroz VpnService.onRevoke, ali zaboravljanje profila u Postavkama ne proizvodi nikakvo emitiranje.

iOS: nazivi sučelja su heuristika, ne ugovor

Mnogi iOS isječci pregledavaju postavke proxyja, pronalaze rječnik __SCOPED__ i traže ključeve sučelja poput tap, tun, utun2, ppp ili ipsec. Taj je pristup konvencija imenovanja, a ne dokumentirano jamstvo, pa ga ažuriranje sustava koje preimenuje sučelje može slomiti. Također rado javlja true za zastarjele zapise koji nadžive tunel.

Kad vaša aplikacija posjeduje konfiguraciju, NEVPNManager daje pravi status. Opisuje tunel koji je vaša aplikacija pokrenula; uz VPN po aplikaciji, druge aplikacije mogu stajati posve izvan tog tunela.

Ponovno učitajte postavke prije čitanja statusa jer se vrijednost mijenja kako tunel dolazi i odlazi:

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

Zastavica statusa platforme ipak ne dokazuje da promet stiže do partnera. Taj jaz pokriva test rute i zato jedan boolean nije dovoljan za podršku.

Windows profili izlažu pravo polje statusa

Windows prati VPN profile odvojeno od adaptera, a Get-VpnConnection izlaže ConnectionStatus za svaki profil koji poznaje. Profili stvoreni kroz Windows klijent ili paket za dodjelu pojavljuju se ovdje. Cmdlet nije opći detektor tunela.

Pročitajte polje za imenovani profil, dodajući -AllUserConnection kad profil pripada svim korisnicima:

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

Klijenti trećih strana često ostaju nevidljivi ovom cmdletu čak i dok im tunel radi, pa prazan rezultat znači nepoznato, a ne prekinuto. Popisi adaptera jednako zavode: adapter dobavljača može postojati dok miruje, a neki adapteri postoje samo tijekom sesije. Za profil koji Windows posjeduje, rasdial javlja izlazni kôd na koji možete granati. Sve to opisuje lokalno uvjerenje, ne dostupnost partnera.

Status plus ruta: provjera u dva dijela

Povezani profil ne govori ništa o tome kamo paketi idu. Podijeljeni tunel može držati tunel aktivnim dok izuzima odredište do kojeg vam je stalo. always-on profili ostaju povezani s mrtvim poslužiteljem, a kill switch namjerno blokira promet kad tunel padne.

Testirajte oba sloja: potvrdite da je VPN transport ili profil aktivan, pa potvrdite da se odredište razrješava i odgovara tim putem. Na Linuxu pitajte kernel koje bi sučelje upotrijebio:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Kad je klijent izvan vaše kontrole, zabilježite oba rezultata i pustite uzorak da pokaže na sloj. Povezano plus neuspješan test rute upućuje na podijeljeni tunel, DNS ili pravilo. Prekinuto plus uspješan test rute znači da promet nosi druga ruta.

Test koji možete izvesti po redu

Prvo zabilježite status platforme, prije nego promijenite bilo kakvo stanje mreže. Razriješite ime hosta i zabilježite obitelj adresa jer AAAA zapis može ići drugom rutom od A zapisa. Otvorite priključak usluge i zahtijevajte odgovor aplikacije, a ne puko rukovanje. Držite svako opažanje u vlastitom polju zapisa.

Na Linux stroju s dig i curl, tri naredbe pokrivaju razrješavanje, rutu i samu uslugu. Pokrenite ih s aktivnim tunelom i ponovno kad je isključen:

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

Četiri odvojena polja pobjeđuju jedan boolean jer status, DNS, ruta i pravilo padaju neovisno i završavaju u različitim timovima. Ping u terminalu ostaje dobra ručna provjera. Loša je definicija povezivosti za automatizaciju, gdje API platforme i test rute odgovaraju na stvarno pitanje.