Slik oppdagar du ein aktiv VPN-tunnel frå kode på kva plattform som helst
Finst tunnelen, går denne destinasjonen gjennom han, eller svarar den fjerne enden? Det er tre ulike kontrollar og tre ulike signal.
«Er VPN-en oppe?» er eigentleg tre spørsmål i éin setning. Kva for eitt av dei koden din treng, er den første avgjerda, og det er den dei fleste implementasjonane hoppar over. Finst det ein tunnel på denne eininga, går trafikken til denne destinasjonen ut gjennom han, eller svarar den fjerne enden med identiteten du ventar. Vel eigenskapen, vel så signalet som måler han, og skriv til slutt i loggen kva for eitt du faktisk målte.
Tre eigenskapar, tre signal
Komprimert til éi linje kvar har dei tre spørsmåla tre ulike svar. Tabellen nedanfor er sjølve avgjerda, ikkje eit samandrag av ho.
| 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 rada sakte. Ein privat vert som svarar beviser at noko svara, ikkje at svaret kom gjennom tunnelen, og han seier ingenting om kven som er i den andre enden. Viss eigenskapen du treng er vegen, mål vegen.
Eksistens: plattforma sin eigen tilstand
Windows svarar på dette for opphavlege profilar via Remote Access Service API. RasEnumConnections listar opp kva som er tilkopla, RasGetConnectStatus rapporterer tilstanden til éin oppføring, og RasGetLinkStatistics legg til fart, bytteteljarar og alderen på tilkoplinga. Grensene er poenget: OpenVPN, WireGuard og leverandørklientar registrerer aldri ei RAS-tilkopling, så ein sunn tunnel av den typen viser ei tom liste, og naiv kode rapporterer han som nede.
Linux-skrivebord eksponerer den same eigenskapen via NetworkManager på D-Bus, der PropertiesChanged på VPN-tilkoplingsobjektet gjer kontrollen til ei hending, og eigenskapen State rapporterer når lenkja når tilkopla. Frå eit skal les nmcli connection show --active dei same opplysningane, og det er det du vil ha under feilsøking. macOS held den lista i System Configuration-rammeverket, med scutil som kommandolinjevisninga si. Alle tre skildrar ei tilkopling plattforma styrer, og alle tre teier om ein tunnel ho ikkje styrer.
Vegen: kvar pakken faktisk går
Navnematching er snarvegen alle grip etter først: list opp grensesnitt, test strengen mot tun, tap, ppp eller ipsec, og ta eit treff som bevis. Det er ein heuristikk, og grensesnittsettet kan sjå likt ut uansett om noko rører seg gjennom det. Eldre iOS-bygg svara slik, og seinare slutta dei, fordi dei synlege grensesnitta ikkje lenger skilde dei to tilstandane.
Det som erstatta det der, er proxy-ordboka til systemet. Medan ein VPN er tilkopla, returnerer kallet til proxy-innstillingane nøklar avgrensa til grensesnitta som er knytte til tunnelen, og når ingenting er tilkopla kjem ordboka tom tilbake. Det er ein svakare påstand enn han høyrest ut som, fordi han registrerer ei systemovertyding om at ein tunnel finst, ikkje kva destinasjon som brukar han.
Android har sin eigen versjon av fella: vpn.connectivity-utsendinga når mottakarar som er deklarerte i manifestet på nokre bygg, og køyretidsregistrerte mottakarar på andre. Handsame det som beste innsats, og hald ein direkte sonde bak det.
Når destinasjonen er det som tel, spør rutetabellen i staden for adapterlista. Standardgateway-heuristikkar bryt saman på maskinar med fleire nettverk og på tunnelar som installerer sin eigen gateway.
Identitet: undersøk den fjerne enden
Ei løkke som sender ICMP-ekko til den fjerne enden kvart par sekund, er den billegaste kontrollen av denne typen, og ho feilar i ei nyttig retning. Rett ho mot ei adresse som berre finst inne i det private nettverket, fordi ei offentleg ei svarar over kva som helst fungerande oppkopling og beviser ingenting. Der ICMP blir filtrert, gjer ei kort TCP-tilkopling til tenesteporten same nytten.
Ein kontroll på serversida har nøyaktig eitt signal tilgjengeleg: kjeldeadressa på tilkoplinga. Å vedlikehalde områdeinventaret er vedlikehaldsarbeid, og det kan ikkje skilje ein tunnel frå kva som helst anna nettverk som tilfeldigvis brukar same blokk.
Grov politikk kan leve med det. Identitet kan ikkje, så autentiser klienten i staden for å stole på kvar pakkane hans ser ut til å kome frå.
Logg kategorien, ikkje dommen
Hald feilkategoriane frå kvarandre i loggen: ingen grensesnitt i det heile, grensesnitt til stades men destinasjonen utilgjengeleg, destinasjon tilgjengeleg men autentisering avvist. Det er tre ulike eigarar, og kvar av dei opnar ei anna gransking.
Å slå dei saman til éin «VPN nede» sender rapporten til eit team som ikkje kan rette det. Kategorien er det nyttige resultatet; dommen er det som gjer det feil.