Slik oppdager du en aktiv VPN-tunnel fra kode på enhver plattform
Finnes tunnelen, går denne destinasjonen gjennom den, eller svarer den fjerne enden? Det er tre forskjellige kontroller og tre forskjellige signaler.
«Er VPN-en oppe?» er egentlig tre spørsmål i én setning. Hvilket av dem koden din trenger, er den første beslutningen, og det er den de fleste implementasjoner hopper over. Finnes det en tunnel på denne enheten, går trafikken til denne destinasjonen ut gjennom den, eller svarer den fjerne enden med identiteten du forventer. Velg egenskapen, velg deretter signalet som måler den, og skriv til slutt i loggen hvilket du faktisk målte.
Tre egenskaper, tre signaler
Komprimert til én linje hver har de tre spørsmålene tre forskjellige svar. Tabellen nedenfor er selve beslutningen, ikke et sammendrag av 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 |
Les den siste raden langsomt. En privat vert som svarer beviser at noe svarte, ikke at svaret kom gjennom tunnelen, og den sier ingenting om hvem som er i den andre enden. Hvis egenskapen du trenger er veien, mål veien.
Eksistens: plattformens egen tilstand
Windows svarer på dette for opprinnelige profiler via Remote Access Service API. RasEnumConnections lister opp hva som er tilkoblet, RasGetConnectStatus rapporterer tilstanden til én oppføring, og RasGetLinkStatistics legger til hastighet, byttetellere og tilkoblingens alder. Grensene er poenget: OpenVPN, WireGuard og leverandørklienter registrerer aldri en RAS-tilkobling, så en sunn tunnel av den typen viser en tom liste, og naiv kode rapporterer den som nede.
Linux-skrivebord eksponerer den samme egenskapen via NetworkManager på D-Bus, der PropertiesChanged på VPN-tilkoblingsobjektet gjør kontrollen til en hendelse, og egenskapen State rapporterer når lenken når tilkoblet. Fra et skall leser nmcli connection show --active de samme opplysningene, og det er det du vil ha under feilsøking. macOS holder den listen i System Configuration-rammeverket, med scutil som sin kommandolinjevisning. Alle tre beskriver en tilkobling plattformen styrer, og alle tre tier om en tunnel den ikke styrer.
Veien: hvor pakken faktisk går
Navnematching er snarveien alle griper etter først: list opp grensesnitt, test strengen mot tun, tap, ppp eller ipsec, og ta et treff som bevis. Det er en heuristikk, og grensesnittsettet kan se likt ut uansett om noe beveger seg gjennom det. Eldre iOS-bygg svarte slik, og senere sluttet, fordi de synlige grensesnittene ikke lenger skilte de to tilstandene.
Det som erstattet det der, er systemets proxy-ordbok. Mens en VPN er tilkoblet, returnerer kallet til proxy-innstillingene nøkler begrenset til grensesnittene som er knyttet til tunnelen, og når ingenting er tilkoblet kommer ordboken tom tilbake. Det er en svakere påstand enn den høres ut som, fordi den registrerer en systemoverbevisning om at en tunnel finnes, ikke hvilken destinasjon som bruker den.
Android har sin egen versjon av fellen: vpn.connectivity-utsendelsen når mottakere som er deklarert i manifestet på noen bygg, og kjøretidsregistrerte mottakere på andre. Behandle det som beste innsats, og hold en direkte sonde bak det.
Når destinasjonen er det som betyr noe, spør rutetabellen i stedet for adapterlisten. Standardgateway-heuristikker bryter sammen på maskiner med flere nettverk og på tunneler som installerer sin egen gateway.
Identitet: undersøk den fjerne enden
En løkke som sender ICMP-ekko til den fjerne enden hvert par sekunder, er den billigste kontrollen av denne typen, og den feiler i en nyttig retning. Rett den mot en adresse som bare finnes inne i det private nettverket, fordi en offentlig en svarer over enhver fungerende oppkobling og beviser ingenting. Der ICMP filtreres, gjør en kort TCP-tilkobling til tjenesteporten samme nytten.
En kontroll på serversiden har nøyaktig ett signal tilgjengelig: kildeadressen på tilkoblingen. Å vedlikeholde områdeinventaret er vedlikeholdsarbeid, og det kan ikke skille en tunnel fra ethvert annet nettverk som tilfeldigvis bruker samme blokk.
Grov politikk kan leve med det. Identitet kan ikke, så autentiser klienten i stedet for å stole på hvor pakkene dens ser ut til å komme fra.
Logg kategorien, ikke dommen
Hold feilkategoriene fra hverandre i loggen: ingen grensesnitt i det hele tatt, grensesnitt til stede men destinasjonen utilgjengelig, destinasjon tilgjengelig men autentisering avvist. Det er tre forskjellige eiere, og hver av dem åpner en annen undersøkelse.
Å slå dem sammen til én «VPN nede» sender rapporten til et team som ikke kan rette det. Kategorien er det nyttige resultatet; dommen er det som gjør det feil.