Sådan registrerer du en aktiv VPN-tunnel fra kode på enhver platform
Findes tunnelen, går denne destination gennem den, eller svarer den fjerne ende? Det er tre forskellige kontroller og tre forskellige signaler.
„Er VPN’en oppe?“ er i virkeligheden tre spørgsmål i én sætning. Hvilket af dem din kode har brug for, er den første beslutning, og det er den, de fleste implementeringer springer over. Findes der en tunnel på denne enhed, forlader trafik til denne destination den gennem tunnelen, eller svarer den fjerne ende med den identitet, du forventer. Vælg egenskaben, vælg derefter det signal, der måler den, og skriv til sidst i loggen, hvilket af dem du faktisk målte.
Tre egenskaber, tre signaler
Komprimeret til én linje hver har de tre spørgsmål tre forskellige svar. Tabellen nedenfor er selve beslutningen, ikke et resumé af den.
| 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 |
Læs den sidste række langsomt. En privat vært, der svarer, beviser, at noget svarede, ikke at svaret kom gennem tunnelen, og den siger intet om, hvem der er i den anden ende. Hvis den egenskab, du har brug for, er vejen, så mål vejen.
Eksistens: platformens egen tilstand
Windows svarer på dette for oprindelige profiler via Remote Access Service API. RasEnumConnections viser, hvad der er forbundet, RasGetConnectStatus rapporterer tilstanden for en post, og RasGetLinkStatistics tilføjer hastighed, byttetællere og forbindelsens alder. Begrænsningerne er pointen: OpenVPN, WireGuard og leverandørklienter registrerer aldrig en RAS-forbindelse, så en sund tunnel af den type viser en tom liste, og naiv kode rapporterer den som nede.
Linux-skriveborde blotlægger den samme egenskab via NetworkManager på D-Bus, hvor PropertiesChanged på VPN-forbindelsesobjektet gør kontrollen til en hændelse, og egenskaben State rapporterer, hvornår linket når forbundet. Fra en shell læser nmcli connection show --active de samme oplysninger, og det er det, du vil have under fejlfinding. macOS holder den liste i System Configuration-rammeværket med scutil som sin kommandolinjevisning. Alle tre beskriver en forbindelse, som platformen styrer, og alle tre tier om en tunnel, den ikke styrer.
Vej: hvor pakken faktisk går hen
Navnematching er den genvej, alle griber efter først: tæl grænseflader op, test strengen mod tun, tap, ppp eller ipsec, og tag et hit som bevis. Det er en heuristik, og grænsefladesættet kan se ens ud, uanset om der bevæger sig noget gennem det. Ældre iOS-builds svarede sådan, og senere holdt op, fordi de synlige grænseflader ikke længere skelnede de to tilstande.
Det, der erstattede det der, er systemets proxy-ordbog. Mens en VPN er forbundet, returnerer proxy-indstillingskaldet nøgler, der er afgrænset til de tunnelrelaterede grænseflader, og når intet er forbundet, kommer ordbogen tom tilbage. Det er en svagere udtalelse, end det lyder, fordi den registrerer en systemoverbevisning om, at der findes en tunnel, snarere end hvilken destination der bruger den.
Android har sin egen version af fælden: vpn.connectivity-udsendelsen når modtagere, der er erklæret i manifestet, på nogle builds og kørselstidsregistrerede modtagere på andre. Behandl det som bedste indsats, og hold en direkte sonde bag det.
Når destinationen er det, der betyder noget, så spørg routingtabellen i stedet for adapterlisten. Standardgateway-heuristikker brækker på maskiner med flere netværk og på tunneler, der installerer deres egen gateway.
Identitet: undersøg den fjerne ende
En løkke, der sender ICMP-ekko til den fjerne ende hvert par sekunder, er den billigste kontrol af denne slags, og den fejler i en nyttig retning. Ret den mod en adresse, der kun findes inde i det private netværk, fordi en offentlig en svarer over enhver fungerende uplink og beviser intet. Hvor ICMP filtreres, gør en kort TCP-forbindelse til tjenestens port den samme nytte.
En kontrol på serversiden har præcis ét signal til rådighed: kildeadressen på forbindelsen. At vedligeholde interval-inventaret er vedligeholdelsesarbejde, og det kan ikke skelne en tunnel fra ethvert andet netværk, der tilfældigvis bruger den samme blok.
Grov politik kan leve med det. Identitet kan ikke, så autentificer klienten i stedet for at stole på, hvor dens pakker ser ud til at komme fra.
Log kategorien, ikke dommen
Hold fejlkategorierne adskilt i loggen: ingen grænseflade overhovedet, grænseflade til stede, men destinationen utilgængelig, destination tilgængelig, men godkendelse afvist. Det er tre forskellige ejere, og hver især åbner en anden undersøgelse.
At slå dem sammen til én „VPN nede“ sender rapporten til et team, der ikke kan rette det. Kategorien er det nyttige output; dommen er det, der gør det forkert.