Så identifierar du en aktiv VPN-tunnel från kod på vilken plattform som helst
Finns tunneln, går den här destinationen genom den, eller svarar den bortre änden? Det är tre olika kontroller och tre olika signaler.
”Är VPN:en uppe?” är egentligen tre frågor i en enda mening. Vilken av dem din kod behöver är det första beslutet, och det är det som de flesta implementationer hoppar över. Finns det en tunnel på den här enheten, lämnar trafiken till den här destinationen genom den, eller svarar den bortre änden med den identitet du förväntar dig. Välj egenskapen, välj sedan signalen som mäter den, och skriv till sist i loggen vilken du faktiskt mätte.
Tre egenskaper, tre signaler
Komprimerade till en rad var har de tre frågorna tre olika svar. Tabellen nedan är själva beslutet, inte en sammanfattning av det.
| 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 sista raden långsamt. En privat värd som svarar bevisar att något svarade, inte att svaret kom genom tunneln, och den säger ingenting om vem som finns i andra änden. Om egenskapen du behöver är vägen, mät vägen.
Existens: plattformens eget tillstånd
Windows svarar på detta för inbyggda profiler via Remote Access Service API. RasEnumConnections listar vad som är anslutet, RasGetConnectStatus rapporterar tillståndet för en post och RasGetLinkStatistics lägger till hastighet, byträknare och anslutningens ålder. Gränserna är poängen: OpenVPN, WireGuard och leverantörernas klienter registrerar aldrig en RAS-anslutning, så en frisk tunnel av den typen visar en tom lista och naiv kod rapporterar den som nere.
Linux-skrivbord exponerar samma egenskap via NetworkManager på D-Bus, där PropertiesChanged på VPN-anslutningsobjektet förvandlar kontrollen till en händelse och egenskapen State rapporterar när länken når ansluten status. Från ett skal läser nmcli connection show --active samma information, och det är vad du vill ha under felsökning. macOS håller den listan i System Configuration-ramverket, med scutil som sin kommandoradsvy. Alla tre beskriver en anslutning som plattformen hanterar, och alla tre tiger om en tunnel den inte hanterar.
Vägen: vart paketet faktiskt tar vägen
Namnmatchning är genvägen som alla griper efter först: lista gränssnitt, testa strängen mot tun, tap, ppp eller ipsec och ta en träff som bevis. Det är en heuristik, och gränssnittsuppsättningen kan se likadan ut oavsett om något rör sig genom den. Äldre iOS-byggen svarade så och senare slutade, eftersom de synliga gränssnitten inte längre skilde de två tillstånden.
Det som ersatte det där är systemets proxy-ordbok. Medan en VPN är ansluten returnerar anropet till proxyinställningarna nycklar som är begränsade till de tunnelrelaterade gränssnitten, och när ingenting är anslutet kommer ordboken tillbaka tom. Det är ett svagare påstående än det låter, eftersom det registrerar en systemövertygelse att en tunnel finns, inte vilken destination som använder den.
Android har sin egen version av fällan: vpn.connectivity-utsändningen når mottagare som deklareras i manifestet i vissa byggen och körtidsregistrerade mottagare i andra. Behandla det som bästa ansträngning och håll en direkt sond bakom det.
När destinationen är det som spelar roll, fråga rutttabellen i stället för adapterlistan. Standardgateway-heuristiker bryts på maskiner med flera nätverk och på tunnlar som installerar sin egen gateway.
Identitet: undersök den bortre änden
En loop som skickar ICMP-eko till den bortre änden varannan sekund är den billigaste kontrollen av det här slaget, och den misslyckas i en användbar riktning. Rikta den mot en adress som bara finns inne i det privata nätverket, eftersom en offentlig svarar över vilken fungerande upplänk som helst och inte bevisar någonting. Där ICMP filtreras gör en kort TCP-anslutning till tjänstens port samma nytta.
En kontroll på serversidan har exakt en signal tillgänglig: källadressen på anslutningen. Att underhålla områdesinventariet är underhållsarbete, och det kan inte skilja en tunnel från vilket annat nätverk som helst som råkar använda samma block.
Grov policy kan leva med det. Identitet kan inte, så autentisera klienten i stället för att lita på varifrån dess paket verkar komma.
Logga kategorin, inte domen
Håll felkategorierna åtskilda i loggen: inget gränssnitt alls, gränssnitt finns men destinationen oåtkomlig, destinationen åtkomlig men autentiseringen avvisad. Det är tre olika ägare, och var och en öppnar en annan utredning.
Att slå ihop dem till ett enda ”VPN nere” skickar rapporten till ett team som inte kan åtgärda det. Kategorin är den användbara utdata; domen är det som gör den felaktig.