Cum să detectați un tunel VPN activ din cod pe orice platformă
Tunelul există, această destinație trece prin el sau răspunde capătul îndepărtat? Sunt trei verificări diferite și trei semnale diferite.
„Este VPN-ul activ?” sunt de fapt trei întrebări într-o singură propoziție. Pe care dintre ele are nevoie codul dumneavoastră este prima decizie, și exact pe aceasta o sar majoritatea implementărilor. Există un tunel pe acest dispozitiv, traficul către această destinație iese prin el, sau capătul îndepărtat răspunde cu identitatea pe care o așteptați. Alegeți proprietatea, apoi alegeți semnalul care o măsoară, iar la final scrieți în jurnal pe care ați măsurat-o efectiv.
Trei proprietăți, trei semnale
Comprimate la o singură linie fiecare, cele trei întrebări au trei răspunsuri diferite. Tabelul de mai jos este decizia însăși, nu rezumatul ei.
| Property | Signal that answers it | What it still leaves open |
|---|---|---|
| Existence | The platform's own connection state: RAS on Windows, NetworkManager on D-Bus on Linux, scutil on macOS | Tunnels of a type the platform does not manage, which includes most third-party clients |
| Path | A route lookup for the one destination, or a scoped proxy or interface key that names the tunnel | Whether the far end is the peer you trust |
| Identity | An authenticated response from the far end, or a source-address policy applied on the server | Which local interface carried the packets |
Citiți încet ultimul rând. Un host privat care răspunde dovedește că ceva a răspuns, nu că răspunsul a venit prin tunel, și nu spune nimic despre cine este la celălalt capăt. Dacă proprietatea de care aveți nevoie este calea, măsurați calea.
Existență: starea proprie a platformei
Windows răspunde la aceasta pentru profilurile native prin Remote Access Service API. RasEnumConnections enumeră ce este conectat, RasGetConnectStatus raportează starea unei intrări, iar RasGetLinkStatistics adaugă viteza, contoarele de octeți și vechimea conexiunii. Limitele sunt miezul: OpenVPN, WireGuard și clienții producătorilor nu înregistrează niciodată o conexiune RAS, așa că un tunel sănătos de acel tip afișează o listă goală, iar codul naiv îl raportează ca oprit.
Desktopurile Linux expun aceeași proprietate prin NetworkManager pe D-Bus, unde PropertiesChanged pe obiectul conexiunii VPN transformă verificarea într-un eveniment, iar proprietatea State raportează când legătura ajunge în starea conectat. Dintr-un shell, nmcli connection show --active citește aceleași informații, și exact asta vreți în timpul depanării. macOS păstrează lista în frameworkul System Configuration, cu scutil ca vizualizare din linia de comandă. Toate trei descriu o conexiune gestionată de platformă, și toate trei tac despre un tunel pe care nu îl gestionează.
Cale: unde ajunge de fapt pachetul
Potrivirea numelor este scurtătura la care apelează toți mai întâi: enumerați interfețele, testați șirul împotriva tun, tap, ppp sau ipsec și luați o potrivire drept dovadă. Este o euristică, iar setul de interfețe poate arăta la fel indiferent dacă trece ceva prin el sau nu. Versiunile mai vechi de iOS răspundeau astfel, iar cele mai noi au încetat, pentru că interfețele vizibile nu mai distingeau cele două stări.
Ceea ce a înlocuit-o acolo este dicționarul de proxy al sistemului. Cât timp un VPN este conectat, apelul setărilor de proxy returnează chei limitate la interfețele legate de tunel, iar când nimic nu este conectat dicționarul revine gol. Este o afirmație mai slabă decât sună, pentru că înregistrează convingerea sistemului că există un tunel, nu care destinație îl folosește.
Android are propria versiune a capcanei: difuzarea vpn.connectivity ajunge la receptori declarați în manifest pe unele versiuni și la receptori înregistrați la rulare pe altele. Tratați-o ca efort maxim și păstrați o sondă directă în spatele ei.
Când destinația este ce contează, întrebați tabelul de rutare în locul listei de adaptoare. Euristicile de gateway implicit se strică pe mașinile cu mai multe rețele și pe tunelurile care instalează propriul gateway.
Identitate: sondați capătul îndepărtat
O buclă care trimite un ecou ICMP la capătul îndepărtat la fiecare câteva secunde este cea mai ieftină verificare de acest tip și eșuează într-o direcție utilă. Îndreptați-o către o adresă care există doar în interiorul rețelei private, pentru că una publică răspunde prin orice legătură superioară funcțională și nu dovedește nimic. Unde ICMP este filtrat, o conexiune TCP scurtă la portul serviciului face aceeași treabă.
O verificare pe partea de server are exact un semnal disponibil: adresa sursă a conexiunii. Întreținerea inventarului de intervale este muncă de mentenanță și nu poate separa un tunel de orice altă rețea care folosește din întâmplare același bloc.
O politică grosieră poate trăi cu asta. Identitatea nu poate, așa că autentificați clientul în loc să vă bazați pe de unde par să vină pachetele lui.
Înregistrați categoria, nu verdictul
Țineți categoriile de eșec separate în jurnal: nicio interfață, interfață prezentă dar destinația inaccesibilă, destinație accesibilă dar autentificare respinsă. Sunt trei proprietari diferiți, iar fiecare deschide o anchetă diferită.
Prăbușirea lor într-un singur „VPN căzut” trimite raportul către o echipă care nu îl poate repara. Categoria este ieșirea utilă; verdictul este ceea ce îl face greșit.