Hva en VPN-tunnel er, og hvor beskyttelsen stopper

Klienten sier tilkoblet, hengelåsen er låst, og et nettsted logger fortsatt adressen til leiligheten din. Ingenting har feilet. En tunnel erstatter ikke Wi-Fi eller mobilforbindelsen din; den legger en annen konvolutt rundt utvalgte pakker og sender den konvolutten over nettet du allerede hadde. Å forstå trikset handler mest om å følge én forespørsel og legge merke til hvor konvolutten åpnes, fordi nesten hvert forvirrende symptom, fra en lekket hjemadresse til en fastlåst stor nedlasting, kommer fra den grensen.

To konvolutter, én fysisk lenke

Den bærbare datamaskinen beholder sin normale forbindelse til ruteren, og ruteren beholder sin normale forbindelse til leverandøren. Ingenting på den veien endres når en tunnel kommer opp. Det som endres, er at utvalgte pakker overleveres til et virtuelt grensesnitt, pakkes inn i en ny pakke adressert til VPN-partneren og sendes som vanlig trafikk over den fysiske lenken.

Mottakerenden er en enhet som åpner konvolutten og videresender den opprinnelige pakken mot målet sitt. Mellom de to endene ser en observatør den ytre overskriften og ingenting om den indre, med mindre protokollen krypterer den, noe de fleste forbrukerprotokoller gjør og den generelle teknikken ikke krever.

Derfor er det virtuelle grensesnittet både virkelig og villedende. Det finnes som et kjerneobjekt med en adresse og en maksimal overføringsenhet, og operativsystemet ruter trafikk inn i det som i ethvert annet grensesnitt. Det er ikke en kabel, og dets eksistens beviser bare at en komponent er installert. Om nettleseren din bruker det, avgjøres av ruter, ikke av at grensesnittet er oppe.

Følg én forespørsel på reisen

Velg et mål og spør kjernen hvilket grensesnitt den vil bruke. Denne ene kommandoen avgjør de fleste diskusjoner om hvorvidt tunnelen gjør noe:

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

Hvis ruteutskriften navngir tunnelgrensesnittet, blir pakken pakket inn. Hvis den navngir det fysiske grensesnittet, blir den ikke det, og ingen omstart av klienten endrer det. Den andre kommandoen viser begge grensesnittene side ved side, og det er slik du oppdager en tunnel som kom opp uten adresse eller med en adresse fra feil familie.

Se deretter på det første hoppet inne fra konvolutten, og sammenlign det med det første hoppet utenfor:

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

Inne i tunnelen er det første hoppet partnerens indre adresse, ikke ruteren din. Opptaket på tunnelgrensesnittet viser de indre pakkene, det er trafikken applikasjonen tror den sender. Opptak samtidig på det fysiske grensesnittet viser de ytre pakkene, og de to sammen er den tydeligste demonstrasjonen av hva en tunnel faktisk gjør.

Tre adresser, og bare én sees av nettstedet

Folk forveksler disse hele tiden, og forvirringen lager falske lekkasjerapporter. Det er forskjellige felt i forskjellige overskrifter med forskjellig levetid.

Nummeret ved siden av den virtuelle adapteren er den andre raden. Det er ikke adressen et nettsted registrerer, og å sitere det som din offentlige IP er rett og slett feil. Adressen et nettsted ser, tildeles av utgangen, og for en tunnel til et privat nettverk er det kanskje ingen offentlig utgang i det hele tatt, fordi målet ligger inne i organisasjonen og ikke på internett.

En tunnel mellom lokasjoner er den samme mekanismen med andre endepunkter. To rutere pakker trafikk inn mellom nettverk, og ingen enkelt enhet har en klient installert. Konvolutten er identisk i prinsippet, den administrative grensen er det ikke.

Hvor konvolutten åpnes, og hva som overlever den

Tunnelen ender ved partneren sin. Hvis applikasjonens egen kryptering rekker lenger, overlever den den grensen, noe som er det normale tilfellet for HTTPS: nettleserens sesjon avsluttes på nettstedet, så utgangen videresender chiffertekst den ikke kan lese.

Ingenting annet overlever som standard. En ukryptert forespørsel er lesbar ved utgangen akkurat slik den var lesbar på kafeenes Wi-Fi, og tunnelen legger ikke til beskyttelse applikasjonen aldri hadde. På samme måte avgjør utgangens brannmurregler og videresendingspolicy hva som skjer videre; et vellykket håndtrykk er et faktum om partnerforbindelsen, ikke om resten av reisen.

Overhead er den andre synlige konsekvensen. Hver pakke bærer en ekstra overskrift, og den ytre transporten kan legge til sin egen, så den brukbare nyttelasten per pakke krymper. På en vei med fast maksimal overføringsenhet er det nettopp derfor en tunnel kan slippe gjennom en ping og stoppe en stor opplasting.

Kontroller veien applikasjonen faktisk tok

Det siste trinnet er å bekrefte den konkrete applikasjonen, ikke maskinen generelt. Slå opp målet, se på ruten for den adressen, og observer deretter forbindelsen mens den er åpen:

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

Hvis ruten navngir tunnelen, men socket-listen viser en forbindelse med en kildeadresse fra det fysiske grensesnittet, er applikasjonen bundet til noe spesifikt, eller en annen tunnel konkurrerer om standardruten. Det er et rutingspørsmål, og det kan besvares fra disse tre utskriftene i stedet for klientens statusskjerm.

RFC 4301 sikkerhetsarkitektur beskriver IP-lagsversjonen av denne innpakningen for IPsec, og den samme laglogikken gjelder for WireGuard og OpenVPN. Når du først kan peke på den indre pakken og den ytre pakken som separate objekter, slutter det meste av tunnelatferd å være mystisk og blir en rutingtabell du kan lese.