Går trafiken verkligen genom VPN:en? Så verifierar du det

Två fel ser likadana ut från ikonen i aktivitetsfältet: trafik som går in i tunneln och trafik som tyst går runt den. Klienten visar Connected i båda fallen, eftersom Connected bara betyder att tunnelns gränssnitt finns och att klienten installerat de rutter den ville ha. Om ett paket från en applikation använde de rutterna är en separat fråga, som besvaras någon annanstans i stacken. Fyra mätningar avgör det mesta — rutkontrollen, första hoppet, en inspelning på den fysiska adaptern och en observation utifrån — och serverns egen sessionsvy täcker resten.

Börja med rutten som paketet kommer att ta

Ruttabellen är beslutet, så fråga den om en enda destination i stället för att läsa hela och gissa. På Linux namnger ip route get gränssnittet och källadressen som kärnan valde:

ip route get 203.0.113.10
ip route get 10.20.5.7

På Windows är Find-NetRoute -RemoteIPAddress 203.0.113.10 mer användbart än route print -4 av samma skäl: det rapporterar rutten som vann, inte alla rutter som finns. Läs ändå tabellen en gång för dess 0.0.0.0-rad. Ett /1-par där betyder att en fulltunnelklient skrev om standardrutten: OpenVPN:s redirect-gateway def1 installerar 0.0.0.0/1 och 128.0.0.0/1 genom tunneln, vilket slår den befintliga 0.0.0.0/0 vid längsta prefixmatchning utan att radera den fysiska standardrutten. Därför kan två standardrutter samexistera medan allt fortfarande går in i tunneln.

Två detaljer gör tabellen lögnaktig. För det första, titta på prefixet som matchade och inte på antalet standardrutter, eftersom ett gränssnittsmetrik eller ett /1-par avgör vinnaren. För det andra behåller en anslutning som redan finns den väg den upprättades med; efter att tunneln kommit upp kan en öppen session fortsätta använda den gamla rutten tills den återställs, och därför verkar återanslutning lösa ett ruttproblem. En körande klient — ps ax | grep openvpn — bevisar bara att processen startade.

Följ ett internt och ett offentligt namn

Rutkontrollen visar avsikten; vägen visar leveransen. Följ ett namn som måste vara internt och ett namn som inte får vara det, medan du är ansluten, och jämför första hoppet:

traceroute intranet.corp.example
traceroute 1.1.1.1

Samma första hopp för båda betyder att det interna namnet aldrig kom in i tunneln och att felet ligger ovanför det, vanligen ett namn som löses upp till en offentlig adress eller en rutt som aldrig installerades. Om intern trafik går ut via 10.8.0.1 medan offentlig trafik går ut via 192.168.1.1, gör delad tunnel exakt det den konfigurerades för. Ett spår som når VPN-gatewayen och sedan bara returnerar tidsgränser är vanligen ett returvägs- eller serverbrandväggsproblem, inte en saknad vidarebefordringsrutt.

Filtrerad ICMP gör den här kontrollen lögnaktig: stjärnor på båda spåren ser ut som en död tunnel och är vanligen en brandvägg. Testa en TCP-port där du kan — traceroute -T -p 443 på Linux — och kom ihåg att spåret inte säger vilken resolver som svarade: ett namn kan lösas lokalt och ändå nås genom tunneln.

Spela in på den fysiska adaptern, inte på tunneln

Den fysiska länken är den enda platsen som visar vad nätverket faktiskt ser. Med tunneln uppe bör en session till kontoret framstå som krypterad nyttolast adresserad till VPN-servern, inte som en anslutning till 10.20.5.7:

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

Det första filtret fångar namnuppslagning som går ut lokalt, vilket är det vanligaste och tystaste läckaget — sidan laddas ändå, resolvern såg bara frågan. Det andra fångar vanlig trafik till en intern adress som bara borde finnas inne i tunneln. På Windows gör pktmon samma arbete utan drivrutin: pktmon filter add -p 53, därefter pktmon start --capture --pkt-size 128, därefter pktmon stop och pktmon format pktmon.etl -o capture.txt. Dessa flaggor skiljer sig lite mellan Windows-versioner, så kontrollera pktmon filter add /? innan du litar på syntaxen.

Spela in det fysiska gränssnittet för att hitta läckage; en inspelning på tunneln innehåller de paket du redan tror finns där, och på en server innehåller den oläsliga yttre paket vars källa är gatewayen. Byträknare på vilket gränssnitt som helst beskriver paket, inte program; att tillskriva trafik en process kräver en monitor som mappar sockets till processer.

Fråga en extern tjänst och fråga sedan igen per applikation

Den enda kontrollen som bevisar utgången är ett svar utifrån: en tjänst som ekar tillbaka den källadress den såg. Kör den från ett skal, där du kan välja gränssnitt, och kör den två gånger:

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

Olika svar ger dig bevis för båda vägarna och ett sätt att testa en viss applikation: bind den, eller kör den i ett nätverksnamnrum med en enda rutt, och se vilken adress den bortre änden registrerar. Identiska svar är det intressanta felet: antingen tog bindningen inte effekt, eller så skriver något mellan värden och den bortre änden om källadressen innan den anländer. På Windows vill curl --interface ha adapterns adress i stället för dess namn.

En webbläsare som rapporterar VPN-adressen bevisar webbläsaren. En e-postklient, en pakethanterare, en säkerhetskopieringsagent eller en andra webbläsarprofil kan var och en ta en annan väg, särskilt när en proxyinställning eller en rutt för delad tunnel täcker en av dem. En adressändring är inte bevis på läckage i sig: en lastbalanserare kan svara annorlunda beroende på vilken utgång den såg, så jämför den registrerade källadressen, inte sidan.

Använd serverns vy för att bekräfta peer-en

Servern svarar på en annan fråga: om en peer är ansluten, hur mycket den har burit och om sessionen startades om. En peer som är uppe på servern medan klientens räknare knappt rör sig betyder att applikationstrafiken inte går in i tunneln, vad klienttabellen än sa. En peer som flyttar mycket data för en användare som rapporterar att ingenting fungerar är en annan utredning.

Här ligger två fällor. En maskerad tunnel får varje flöde att se ut som om det kommer från gatewayen, så loggar och redovisning per klient kollapsar till en enda adress. Och en klient behandlas som en lokal värd, så frågan om någon kopierar filer genom VPN:en besvaras av fildelningstrafik på servern eller av värdgranskning på servern — att övervaka tunneln ger ändpunkter och volym, inte filnamn.

Skilj ett designbeslut från ett läckage

Inte allt utanför tunneln är ett läckage. Länklokal och broadcast-trafik stannar lokalt enligt design, en skrivare som hittas via multicast fortsätter annonsera på LAN:et, och DHCP måste gå ut lokalt. En applikation som är bunden till ett visst gränssnitt kringgår ruttabellen med avsikt, och bara en brandväggsregel, ett namnrum eller en policyrutt ändrar det.

IPv6 förtjänar sin egen rad på checklistan. En tunnel som bara bär IPv4 lämnar en dual-stack-värd med en andra användbar väg, och en dual-stack-destination föredrar den — även DNS, om resolvern nås över IPv6. Inaktivera IPv6 på adaptern eller bekräfta att tunneln bär det innan du betraktar ett IPv4-resultat som komplett.

När kontrollerna inte stämmer överens namnger oenigheten vanligen felet:

En ordning som fungerar: spara ruttabellen före och efter anslutning, följ ett internt och ett offentligt namn, spela in DNS på den fysiska adaptern, eka utgångsadressen från skalet för den specifika applikationen och läs sedan servern för volym. Om de fyra första stämmer bär tunneln det du tror och det återstående problemet ligger ovanför. Om två av dem inte stämmer är paret som inte stämmer felet, inte ikonen.