Vad en VPN-tunnel är, och var skyddet slutar

Klienten säger ansluten, hänglåset är låst, och en webbplats loggar fortfarande adressen till din lägenhet. Inget har misslyckats. En tunnel ersätter inte ditt Wi-Fi eller din mobila länk; den lägger ett andra kuvert runt vissa paket och skickar det kuvertet över nätet du redan hade. Att förstå tricket handlar mest om att följa en förfrågan och lägga märke till var kuvertet öppnas, eftersom nästan varje förvirrande symptom, från en läckande hemadress till en fastnad stor nedladdning, kommer från den gränsen.

Två kuvert, en fysisk länk

Din laptop behåller sin normala anslutning till routern, och routern behåller sin normala anslutning till leverantören. Inget på den vägen ändras när en tunnel kommer upp. Det som ändras är att utvalda paket lämnas till ett virtuellt gränssnitt, lindas in i ett nytt paket adresserat till VPN-partnern och skickas som vanlig trafik över den fysiska länken.

Mottagningsänden är en enhet som öppnar kuvertet och vidarebefordrar det ursprungliga paketet mot sitt mål. Mellan de två ändarna ser en observatör den yttre rubriken och inget om den inre, om inte protokollet krypterar den, vilket de flesta konsumentprotokoll gör och den allmänna tekniken inte kräver.

Därför är det virtuella gränssnittet både verkligt och vilseledande. Det finns som ett kärnobjekt med en adress och en maximal överföringsenhet, och operativsystemet dirigerar trafik in i det som i vilket annat gränssnitt som helst. Det är inte en kabel, och dess existens bevisar bara att en komponent är installerad. Om din webbläsare använder det avgörs av rutter, inte av att gränssnittet är uppe.

Följ en förfrågan på resan

Välj ett mål och fråga kärnan vilket gränssnitt den kommer att använda. Detta enda kommando avgör de flesta diskussioner om huruvida tunneln gör något:

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

Om ruttutskriften namnger tunnelgränssnittet blir paketet inlindat. Om den namnger det fysiska gränssnittet blir det inte det, och ingen omstart av klienten ändrar det. Det andra kommandot visar båda gränssnitten sida vid sida, och det är så du upptäcker en tunnel som kom upp utan adress eller med en adress från fel familj.

Titta sedan på första hoppet inifrån kuvertet och jämför det med första hoppet utanför:

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

Inne i tunneln är första hoppet partnerns inre adress, inte din router. Avlyssningen på tunnelgränssnittet visar de inre paketen, det är trafiken som applikationen tror att den skickar. Avlyssning samtidigt på det fysiska gränssnittet visar de yttre paketen, och de två tillsammans är den tydligaste demonstrationen av vad en tunnel faktiskt gör.

Tre adresser, och webbplatsen ser bara en

Folk blandar ihop dessa hela tiden, och förvirringen skapar falska läckagerapporter. Det är olika fält i olika rubriker med olika livslängd.

Numret bredvid den virtuella adaptern är den andra raden. Det är inte adressen som en webbplats registrerar, och att citera det som din offentliga IP är helt enkelt fel. Adressen som en webbplats ser tilldelas av utgången, och för en tunnel till ett privat nätverk finns det kanske ingen offentlig utgång alls, eftersom målet ligger inne i organisationen och inte på internet.

En tunnel mellan platser är samma mekanism med andra ändpunkter. Två routrar lindar in trafik mellan nätverk, och ingen enskild enhet har en klient installerad. Kuvertet är identiskt i princip, den administrativa gränsen inte.

Var kuvertet öppnas, och vad som överlever det

Tunneln slutar vid sin partner. Om applikationens egen kryptering räcker längre överlever den den gränsen, vilket är det normala fallet för HTTPS: webbläsarens session avslutas på webbplatsen, så utgången vidarebefordrar chiffertext som den inte kan läsa.

Inget annat överlever som standard. En okrypterad förfrågan är läsbar vid utgången precis som den var läsbar på kaféets Wi-Fi, och tunneln lägger inte till skydd som applikationen aldrig hade. På samma sätt avgör utgångens brandväggsregler och vidarebefordringspolicy vad som händer härnäst; ett lyckat handslag är ett faktum om partneranslutningen, inte om resten av resan.

Overhead är den andra synliga konsekvensen. Varje paket bär en extra rubrik, och den yttre transporten kan lägga till sin egen, så den användbara nyttolasten per paket krymper. På en väg med fast maximal överföringsenhet är det precis därför en tunnel kan släppa igenom en ping och stoppa en stor uppladdning.

Kontrollera vägen som applikationen faktiskt tog

Det sista steget är att bekräfta den specifika applikationen, inte maskinen i allmänhet. Slå upp målet, titta på rutten för den adressen och observera sedan anslutningen medan den är öppen:

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

Om rutten namnger tunneln men socketlistan visar en anslutning med en källadress från det fysiska gränssnittet, är applikationen bunden till något specifikt, eller så konkurrerar en andra tunnel om standardrutten. Det är en routingfråga, och den kan besvaras från dessa tre utskrifter i stället för klientens statusskärm.

Säkerhetsarkitekturen RFC 4301 beskriver IP-lagerversionen av denna inlindning för IPsec, och samma lagerlogik gäller för WireGuard och OpenVPN. När du väl kan peka på det inre paketet och det yttre paketet som separata objekt slutar det mesta av tunnelbeteendet att vara mystiskt och blir en routingtabell som du kan läsa.