Hoe om ’n aktiewe VPN-tonnel vanuit kode op enige platform op te spoor
Bestaan die tonnel, loop hierdie bestemming daardeur, of antwoord die verre kant? Dit is drie verskillende toetse en drie verskillende seine.
“Is die VPN aan?” is eintlik drie vrae in een sin. Watter van hulle jou kode nodig het, is die eerste besluit, en dit is die een wat die meeste implementasies oorslaan. Bestaan daar ’n tonnel op hierdie toestel, verlaat verkeer na hierdie bestemming deur dit, of antwoord die verre kant met die identiteit wat jy verwag. Kies die eienskap, kies dan die sein wat dit meet, en sê dan in die log watter een jy werklik gemeet het.
Drie eienskappe, drie seine
Saamgepers tot een reël elk, het die drie vrae drie verskillende antwoorde. Die tabel hieronder is die besluit, nie ’n opsomming daarvan nie.
| 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 |
Lees die laaste ry stadig. ’n Privaat gasheer wat antwoord, bewys dat iets geantwoord het, nie dat die antwoord deur die tonnel gekom het nie, en dit sê niks oor wie aan die ander kant is nie. As die eienskap wat jy nodig het die pad is, meet die pad.
Bestaan: die platform se eie toestand
Windows antwoord dit vir inheemse profiele deur die Remote Access Service API. RasEnumConnections lys wat gekoppel is, RasGetConnectStatus rapporteer die toestand van een inskrywing, en RasGetLinkStatistics voeg spoed, greptellers en verbindingsouderdom by. Die grense is die punt: OpenVPN, WireGuard en handelaarkliënte registreer nooit ’n RAS-verbinding nie, so ’n gesonde tonnel van daardie soort wys ’n leë lys en naïve kode rapporteer dit as af.
Linux-rekenaars stel dieselfde eienskap bloot deur NetworkManager op D-Bus, waar PropertiesChanged op die VPN-verbindingsobjek die toets in ’n gebeurtenis verander en die State-eienskap rapporteer wanneer die skakel verbind bereik. Vanuit ’n dop lees nmcli connection show --active dieselfde inligting, en dit is wat jy tydens ontfouting wil hê. macOS hou daardie lys in die System Configuration-raamwerk, met scutil as sy opdragreël-aansig. Al drie beskryf ’n verbinding wat die platform bestuur, en al drie word stil vir ’n tonnel wat dit nie bestuur nie.
Pad: waar die pakkie werklik gaan
Naam-passing is die kortpad waarna almal eerste gryp: lys koppelvlakke, toets die string teen tun, tap, ppp of ipsec, en beskou ’n treffer as bewys. Dit is ’n heuristiek, en die koppelvlakversameling kan dieselfde lyk of enigiets daardeur beweeg of nie. Ouer iOS-bouers het so geantwoord en latere het opgehou, want die sigbare koppelvlakke het nie meer die twee toestande onderskei nie.
Wat dit daar vervang het, is die stelsel-proksiewoordeboek. Terwyl ’n VPN gekoppel is, gee die proksinstellings-oproep sleutels wat aan die tonnelverwante koppelvlakke gekoppel is, en met niks gekoppel nie kom die woordeboek leeg terug. Dit is ’n swakker stelling as wat dit klink, want dit teken ’n stelseloortuiging dat ’n tonnel bestaan, eerder as watter bestemming dit gebruik.
Android het sy eie weergawe van die lokval: die vpn.connectivity-uitsending bereik ontvangers wat in die manifest verklaar is op sommige bouers en tydregistrasie-ontvangers op ander. Behandel dit as beste poging, en hou ’n direkte ondersoek agter dit.
Wanneer die bestemming is wat saak maak, vra die roetebeheerder eerder as die adapterlys. Verstek-gateway-heuristieke breek op masjiene met veelvuldige netwerke en op tonnele wat hul eie gateway installeer.
Identiteit: ondersoek die verre kant
’n Lus wat elke paar sekondes die verre kant ping, is die goedkoopste toets van hierdie soort, en dit faal in ’n nuttige rigting. Rig dit op ’n adres wat net binne die privaat netwerk bestaan, want ’n openbare een antwoord oor enige werkende opverbinding en bewys niks. Waar ICMP gefiltreer word, doen ’n kort TCP-verbinding na die dienspoort dieselfde werk.
’n Kontrole aan die bedienerskant het presies een sein beskikbaar: die bronadres op die verbinding. Om die reeksinventaris te onderhou is instandhoudingswerk, en dit kan nie ’n tonnel skei van enige ander netwerk wat toevallig dieselfde blok gebruik nie.
Growwe beleid kan daarmee saamleef. Identiteit kan nie, so verifieer die kliënt eerder as om te vertrou waar sy pakkies skynbaar vandaan kom.
Teken die kategorie aan, nie die uitspraak nie
Hou die foutkategorieë apart in die log: geen koppelvlak hoegenaamd, koppelvlak teenwoordig maar die bestemming onbereikbaar, bestemming bereikbaar maar verifikasie verwerp. Dit is drie verskillende eienaars, en elkeen open ’n ander ondersoek.
Om hulle in een “VPN af” saam te voeg, stuur die verslag na ’n span wat dit nie kan regmaak nie. Die kategorie is die nuttige uitset; die uitspraak is wat dit verkeerd maak.