Com detectar un túnel VPN actiu des del codi a qualsevol plataforma
Existeix el túnel, aquesta destinació hi passa, o respon l’extrem remot? Són tres comprovacions diferents i tres senyals diferents.
«El VPN està actiu?» són en realitat tres preguntes en una sola frase. Quina d’elles necessita el vostre codi és la primera decisió, i és la que la majoria d’implementacions s’estalvien. Existeix un túnel en aquest dispositiu, el trànsit cap a aquesta destinació en surt a través, o respon l’extrem remot amb la identitat que espereu. Trieu la propietat, després trieu el senyal que la mesura i, finalment, digueu al registre quin heu mesurat realment.
Tres propietats, tres senyals
Comprimides a una línia cadascuna, les tres preguntes tenen tres respostes diferents. La taula de sota és la decisió mateixa, no un resum.
| 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 |
Llegiu l’última fila a poc a poc. Un amfitrió privat que respon demostra que alguna cosa ha respost, no que la resposta hagi arribat pel túnel, i no diu res sobre qui hi ha a l’altre extrem. Si la propietat que necessiteu és el camí, mesureu el camí.
Existència: l’estat propi de la plataforma
Windows ho respon per als perfils natius mitjançant l’API de Remote Access Service. RasEnumConnections llista què està connectat, RasGetConnectStatus informa de l’estat d’una entrada i RasGetLinkStatistics afegeix velocitat, comptadors de bytes i edat de la connexió. Els límits són el punt clau: OpenVPN, WireGuard i els clients de fabricants mai no registren una connexió RAS, així que un túnel sa d’aquest tipus mostra una llista buida i el codi ingenu el declara aturat.
Els escriptoris Linux exposen la mateixa propietat mitjançant NetworkManager sobre D-Bus, on PropertiesChanged a l’objecte de connexió VPN converteix la comprovació en un esdeveniment i la propietat State informa de quan l’enllaç arriba a connectat. Des d’una consola, nmcli connection show --active llegeix la mateixa informació, que és el que voleu mentre depureu. macOS guarda aquesta llista al marc System Configuration, amb scutil com a vista de línia d’ordres. Les tres descriuen una connexió que gestiona la plataforma, i les tres callen per a un túnel que no gestiona.
Camí: on va realment el paquet
La coincidència de noms és la drecera a què tothom recorre primer: enumereu interfícies, proveu la cadena contra tun, tap, ppp o ipsec i tracteu una coincidència com a prova. És una heurística, i el conjunt d’interfícies pot semblar el mateix tant si hi passa alguna cosa com si no. Les versions antigues d’iOS responien així i les posteriors van deixar de fer-ho, perquè les interfícies visibles ja no distingien els dos estats.
El que ho va substituir allà és el diccionari de proxy del sistema. Mentre hi ha un VPN connectat, la crida de configuració de proxy retorna claus vinculades a les interfícies relacionades amb el túnel, i amb res connectat el diccionari torna buit. És una afirmació més feble del que sembla, perquè enregistra la creença del sistema que existeix un túnel, no quina destinació el fa servir.
Android té la seva pròpia versió del parany: la difusió vpn.connectivity arriba als receptors declarats al manifest en algunes compilacions i als receptors registrats en temps d’execució en altres. Tracteu-la com a millor esforç i manteniu una sonda directa al darrere.
Quan la destinació és el que importa, pregunteu a la taula d’encaminament en lloc de la llista d’adaptadors. Les heurístiques de porta d’enllaç per defecte fallen en màquines amb diverses xarxes i en túnels que instal·len la seva pròpia porta d’enllaç.
Identitat: sondar l’extrem remot
Un bucle que fa ICMP a l’extrem remot cada pocs segons és la comprovació més barata d’aquest tipus, i falla en una direcció útil. Apunteu-lo a una adreça que només existeix dins de la xarxa privada, perquè una de pública respon per qualsevol enllaç ascendent que funcioni i no demostra res. On es filtra ICMP, una connexió TCP curta al port del servei fa la mateixa feina.
Una comprovació al costat del servidor té exactament un senyal disponible: l’adreça d’origen de la connexió. Mantenir l’inventari de rangs és feina de manteniment i no pot separar un túnel de qualsevol altra xarxa que faci servir el mateix bloc.
La política grollera pot conviure amb això. La identitat no, així que autentiqueu el client en lloc de confiar en d’on semblen venir els seus paquets.
Registreu la categoria, no el veredicte
Manteniu les categories de fallada separades al registre: cap interfície, interfície present però destinació inabastable, destinació abastable però autenticació rebutjada. Són tres propietaris diferents, i cadascun obre una investigació diferent.
Col·lapsar-les en un sol «VPN caigut» envia l’informe a un equip que no ho pot arreglar. La categoria és la sortida útil; el veredicte és el que el fa incorrecte.