Hvad en VPN-tunnel er, og hvor beskyttelsen stopper

Klienten siger forbundet, hængelåsen er lukket, og et websted logger stadig adressen på din lejlighed. Intet er fejlet. En tunnel erstatter ikke dit Wi-Fi eller din mobilforbindelse; den lægger en anden konvolut om udvalgte pakker og sender den konvolut over det netværk, du allerede havde. At forstå tricket handler mest om at følge én anmodning og bemærke, hvor konvolutten åbnes, fordi næsten hvert forvirrende symptom, fra en lækket hjemadresse til en fastlåst stor download, kommer fra den grænse.

To konvolutter, ét fysisk link

Din bærbare computer beholder sin normale forbindelse til routeren, og routeren beholder sin normale forbindelse til udbyderen. Intet på den vej ændrer sig, når en tunnel kommer op. Det, der ændrer sig, er, at udvalgte pakker overgives til en virtuel grænseflade, pakkes ind i en ny pakke adresseret til VPN-modparten og sendes som almindelig trafik over det fysiske link.

Modtagerenden er en enhed, der pakker konvolutten ud og videresender den oprindelige pakke mod dens destination. Mellem de to ender ser en observatør det ydre header og intet om det indre, medmindre protokollen krypterer det, hvilket de fleste forbrugerprotokoller gør, og den generelle teknik ikke kræver.

Derfor er den virtuelle grænseflade både virkelig og vildledende. Den findes som et kerneobjekt med en adresse og en maksimal transmissionseinhed, og styresystemet sender trafik ind i den som i enhver anden grænseflade. Den er ikke et kabel, og dens eksistens beviser kun, at en komponent er installeret. Om din browser bruger den, afgøres af ruter, ikke af at grænsefladen er oppe.

Følg én anmodning på rejsen

Vælg en destination, og spørg kernen, hvilken grænseflade den vil bruge. Denne ene kommando afgør de fleste diskussioner om, hvorvidt tunnelen gør noget:

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

Hvis ruteoutputtet nævner tunnelgrænsefladen, bliver pakken pakket ind. Hvis det nævner den fysiske grænseflade, bliver den ikke, og ingen genstart af klienten ændrer det. Den anden kommando viser begge grænseflader side om side, og det er sådan, du opdager en tunnel, der kom op uden en adresse eller med en adresse fra den forkerte familie.

Se derefter på det første hop inde fra konvolutten, og sammenlign det med det første hop udenfor:

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

Inde i tunnelen er det første hop modpartens indre adresse, ikke din router. Optagelsen på tunnelgrænsefladen viser de indre pakker, og det er den trafik, som applikationen tror, den sender. Optagelse på den fysiske grænseflade samtidig viser de ydre pakker, og de to sammen er den tydeligste demonstration af, hvad en tunnel faktisk gør.

Tre adresser, og kun én ses af webstedet

Folk forveksler disse konstant, og forvirringen skaber falske lækagerapporter. Det er forskellige felter i forskellige headers med forskellige levetider.

Nummeret ved siden af den virtuelle adapter er den anden række. Det er ikke den adresse, et websted registrerer, og at citere det som din offentlige IP er simpelthen forkert. Den adresse, et websted ser, tildeles af udgangen, og for en tunnel til et privat netværk er der måske slet ingen offentlig udgang, fordi destinationen ligger inde i organisationen og ikke på internettet.

En tunnel mellem to lokaliteter er den samme mekanisme med andre endepunkter. To routere pakker trafik ind mellem netværk, og ingen enkelt enhed har en klient installeret. Konvolutten er identisk i princippet, og den administrative grænse er ikke.

Hvor konvolutten åbnes, og hvad der overlever den

Tunnelen ender ved sin modpart. Hvis applikationens egen kryptering rækker længere, overlever den den grænse, hvilket er det normale tilfælde for HTTPS: browserens session slutter på webstedet, så udgangen videresender ciphertext, den ikke kan læse.

Intet andet overlever som standard. En ukrypteret anmodning er læsbar ved udgangen præcis som den var læsbar på caféens Wi-Fi, og tunnelen tilføjer ikke beskyttelse, som applikationen aldrig havde. Tilsvarende afgør udgangens firewallregler og videresendelsespolitik, hvad der sker næste gang; et vellykket håndtryk er et faktum om modpartsforbindelsen, ikke om resten af rejsen.

Overhead er den anden synlige konsekvens. Hver pakke bærer et ekstra header, og den ydre transport kan tilføje sit eget, så den brugbare nyttelast per pakke skrumper. På en vej med en fast maksimal transmissionseinhed er det præcis derfor, en tunnel kan passere en ping og standse en stor upload.

Kontroller den vej, applikationen faktisk tog

Det sidste trin er at bekræfte den konkrete applikation frem for maskinen generelt. Slå destinationen op, se på ruten for den adresse, og observer derefter forbindelsen, mens den er åben:

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

Hvis ruten nævner tunnelen, men socketlisten viser en forbindelse med en kildeadresse fra den fysiske grænseflade, er applikationen bundet til noget bestemt, eller også konkurrerer en anden tunnel om standardruten. Det er et rutingspørgsmål, og det kan besvares ud fra disse tre output i stedet for klientens statusskærm.

RFC 4301-sikkerhedsarkitekturen beskriver IP-lagsversionen af denne indpakning for IPsec, og den samme laglogik gælder for WireGuard og OpenVPN. Når du først kan pege på den indre pakke og den ydre pakke som separate objekter, holder det meste tunneladfærd op med at være mystisk og bliver en rutingtabel, du kan læse.