Gaat het verkeer echt door de VPN? Zo verifieert u het

Twee storingen zien er vanaf het pictogram in het systeemvak hetzelfde uit: verkeer dat de tunnel in gaat en verkeer dat er stilletjes omheen gaat. De client toont in beide gevallen Connected, omdat Connected alleen betekent dat de tunnelinterface bestaat en dat de client de routes heeft geïnstalleerd die hij wilde. Of één pakket van één toepassing die routes gebruikte, is een aparte vraag, die elders in de stack wordt beantwoord. Vier metingen beslechten het meeste — de routelookup, de eerste hop, een opname op de fysieke adapter en een observatie van buitenaf — en de sessieweergave op de server dekt de rest.

Begin met de route die het pakket zal nemen

De routetabel is de beslissing, dus vraag ernaar voor één bestemming in plaats van hem helemaal te lezen en te gissen. Op Linux noemt ip route get de interface en het bronadres dat de kernel koos:

ip route get 203.0.113.10
ip route get 10.20.5.7

Op Windows is Find-NetRoute -RemoteIPAddress 203.0.113.10 nuttiger dan route print -4 om dezelfde reden: het rapporteert de route die won, niet alle routes die bestaan. Lees de tabel toch één keer vanwege de regel 0.0.0.0. Een paar /1 daar betekent dat een full-tunnelclient de standaardroute heeft herschreven: de optie redirect-gateway def1 van OpenVPN installeert 0.0.0.0/1 en 128.0.0.0/1 via de tunnel, wat de bestaande 0.0.0.0/0 verslaat op de langste prefixmatch zonder de fysieke standaardroute te verwijderen. Daarom kunnen twee standaardroutes naast elkaar bestaan terwijl alles toch de tunnel in gaat.

Twee details maken de tabel leugenachtig. Ten eerste, kijk naar de prefix die overeenkwam en niet naar het aantal standaardroutes, omdat een interfacemetriek of een paar /1 de winnaar bepaalt. Ten tweede behoudt een verbinding die al bestaat het pad waarmee hij tot stand kwam; nadat de tunnel omhoog is, kan een open sessie de oude route blijven gebruiken totdat hij wordt gereset, en daarom lijkt opnieuw verbinden een routeringsprobleem op te lossen. Een draaiende client — ps ax | grep openvpn — bewijst alleen dat het proces is gestart.

Volg één interne en één openbare naam

De routelookup toont de bedoeling; het pad toont de aflevering. Volg een naam die intern moet zijn en een naam die dat niet mag zijn, terwijl u verbonden bent, en vergelijk de eerste hop:

traceroute intranet.corp.example
traceroute 1.1.1.1

Dezelfde eerste hop voor beide betekent dat de interne naam nooit de tunnel is binnengegaan en dat de fout erboven zit, meestal een naam die naar een openbaar adres oplost of een route die nooit is geïnstalleerd. Als intern verkeer via 10.8.0.1 naar buiten gaat terwijl openbaar verkeer via 192.168.1.1 naar buiten gaat, doet split tunneling precies waarvoor het is geconfigureerd. Een trace die de VPN-gateway bereikt en daarna alleen time-outs teruggeeft, is meestal een retourpad- of serverfirewallprobleem, geen ontbrekende doorstuurroute.

Gefilterde ICMP maakt deze controle leugenachtig: sterretjes op beide traces lijken op een dode tunnel en zijn meestal een firewall. Test een TCP-poort waar u kunt — traceroute -T -p 443 op Linux — en onthoud dat de trace niets zegt over welke resolver antwoordde: een naam kan lokaal oplossen en toch via de tunnel bereikbaar zijn.

Neem op op de fysieke adapter, niet op de tunnel

De fysieke verbinding is de enige plek die laat zien wat het netwerk werkelijk ziet. Met de tunnel omhoog zou een sessie naar kantoor moeten verschijnen als versleutelde lading die aan de VPN-server is geadresseerd, niet als een verbinding naar 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Het eerste filter vangt naamresolutie die lokaal naar buiten gaat, wat de meest voorkomende en stilste lekkage is — de pagina laadt toch, de resolver heeft alleen de query gezien. Het tweede vangt gewoon verkeer naar een intern adres dat alleen binnen de tunnel zou moeten bestaan. Op Windows doet pktmon hetzelfde werk zonder stuurprogramma: pktmon filter add -p 53, dan pktmon start --capture --pkt-size 128, dan pktmon stop en pktmon format pktmon.etl -o capture.txt. Die vlaggen verschillen een beetje tussen Windows-builds, dus controleer pktmon filter add /? voordat u de syntaxis vertrouwt.

Neem de fysieke interface op om lekkages te vinden; een opname op de tunnel bevat de pakketten waarvan u al denkt dat ze er zijn, en op een server bevat hij onleesbare buitenste pakketten waarvan de bron de gateway is. Byte-tellers op welke interface dan ook beschrijven pakketten, geen programma's; om verkeer aan een proces toe te schrijven is een monitor nodig die sockets aan processen koppelt.

Vraag een externe dienst, en vraag het daarna opnieuw per toepassing

De enige controle die de uitgang bewijst, is een antwoord van buitenaf: een dienst die het geziene bronadres terugstuurt. Voer hem uit vanuit een shell, waar u de interface kunt kiezen, en voer hem twee keer uit:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Verschillende antwoorden geven u bewijs voor beide paden en een manier om een specifieke toepassing te testen: bind hem, of voer hem uit in een netwerknaamruimte met één route, en kijk welk adres het verre uiteinde registreert. Identieke antwoorden zijn de interessante storing: ofwel heeft de binding niet gewerkt, ofwel herschrijft iets tussen de host en het verre uiteinde het bronadres voordat het aankomt. Op Windows wil curl --interface het adres van de adapter in plaats van de naam.

Een browser die het VPN-adres rapporteert, bewijst de browser. Een mailclient, een pakketbeheerder, een back-upagent of een tweede browserprofiel kunnen elk een ander pad nemen, vooral wanneer een proxy-instelling of een split-tunnelroute een van hen dekt. Een adreswijziging is op zichzelf geen bewijs van een lekkage: een loadbalancer kan anders antwoorden afhankelijk van de uitgang die hij zag, dus vergelijk het geregistreerde bronadres, niet de pagina.

Gebruik de serverweergave om de peer te bevestigen

De server beantwoordt een andere vraag: of een peer is verbonden, hoeveel hij heeft gedragen en of de sessie opnieuw is gestart. Een peer die op de server actief is terwijl de tellers van de client nauwelijks bewegen, betekent dat het toepassingsverkeer niet de tunnel in gaat, wat de clienttabel ook zei. Een peer die veel gegevens verplaatst voor een gebruiker die meldt dat niets werkt, is een ander onderzoek.

Hier liggen twee valkuilen. Een gemaskeerde tunnel laat elke stroom lijken alsof hij van de gateway komt, waardoor logboeken en administratie per client op één adres samenvallen. En een client wordt als lokale host behandeld, dus de vraag of iemand bestanden door de VPN kopieert, wordt beantwoord door bestandsdelingsverkeer op de server of door hostaudit op de server — de tunnel bekijken geeft eindpunten en volume, geen bestandsnamen.

Onderscheid een ontwerpbeslissing van een lekkage

Niet alles buiten de tunnel is een lekkage. Link-local en broadcast-verkeer blijft ontwerptechnisch lokaal, een printer die via multicast wordt gevonden, blijft zich op het LAN aankondigen, en DHCP moet lokaal naar buiten. Een toepassing die aan een specifieke interface is gebonden, omzeilt met opzet de routetabel, en alleen een firewallregel, een naamruimte of een beleidsroute verandert dat.

IPv6 verdient een eigen regel op de checklist. Een tunnel die alleen IPv4 draagt, laat een dual-stackhost een tweede bruikbaar pad, en een dual-stackbestemming zal dat verkiezen — inclusief DNS, als de resolver via IPv6 bereikbaar is. Schakel IPv6 uit op de adapter of bevestig dat de tunnel het draagt voordat u een IPv4-resultaat als volledig beschouwt.

Wanneer de controles het oneens zijn, noemt de onenigheid meestal de fout:

Een volgorde die werkt: sla de routetabel op vóór en na het verbinden, volg één interne en één openbare naam, neem DNS op op de fysieke adapter, geef het uitgangsadres terug vanuit de shell voor de specifieke toepassing en lees daarna de server voor volume. Als de eerste vier het eens zijn, draagt de tunnel wat u denkt en zit het resterende probleem erboven. Als twee ervan het oneens zijn, is het paar dat het oneens is de fout, niet het pictogram.