Kva ein VPN-tunnel er, og kvar vernet stoppar

Klienten seier tilkopla, hengelåsen er låst, og eit nettstad loggar framleis adressa til leilegheita di. Ingenting har feila. Ein tunnel erstattar ikkje Wi-Fi eller mobilsambandet ditt; han legg ein annan konvolutt rundt utvalde pakkar og sender den konvolutten over nettet du alt hadde. Å forstå trikset handlar mest om å følgje éin førespurnad og leggje merke til kvar konvolutten blir opna, fordi nesten kvart forvirrande symptom, frå ei lekkande heimeadresse til ei fastlåst stor nedlasting, kjem frå den grensa.

To konvoluttar, éin fysisk lenkje

Den berebne datamaskina held si normale tilkopling til ruteren, og ruteren held si normale tilkopling til leverandøren. Ingenting på den vegen endrar seg når ein tunnel kjem opp. Det som endrar seg, er at utvalde pakkar blir overleverte til eit virtuelt grensesnitt, pakka inn i ein ny pakke adressert til VPN-partnaren og sende som vanleg trafikk over den fysiske lenkja.

Mottakaranden er eining som opnar konvolutten og sender den opphavlege pakken vidare mot målet sitt. Mellom dei to endane ser ein observatør den ytre overskrifta og ingenting om den indre, med mindre protokollen krypterer henne, noko dei fleste forbrukarprotokollar gjer og den generelle teknikken ikkje krev.

Difor er det virtuelle grensesnittet både verkeleg og villedande. Det finst som eit kjerneobjekt med ei adresse og ei maksimal overføringseining, og operativsystemet rutar trafikk inn i det som i eit kva anna grensesnitt. Det er ikkje ein kabel, og eksistensen beviser berre at ein komponent er installert. Om nettlesaren din brukar det, blir avgjort av ruter, ikkje av at grensesnittet er oppe.

Følgj éin førespurnad på reisa

Vel eit mål og spør kjernen kva grensesnitt han vil bruke. Denne eine kommandoen avgjer dei fleste diskusjonane om tunnelen gjer noko:

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

Viss ruteutskrifta nemner tunnelgrensesnittet, blir pakken pakka inn. Viss ho nemner det fysiske grensesnittet, blir han ikkje det, og ingen omstart av klienten endrar det. Den andre kommandoen viser båe grensesnitta side om side, og det er slik du oppdagar ein tunnel som kom opp utan adresse eller med ei adresse frå feil familie.

Sjå så på det første hoppet inne frå konvolutten, og samanlikn det med det første hoppet utanfor:

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

Inne i tunnelen er det første hoppet den indre adressa til partnaren, ikkje ruteren din. Opptaket på tunnelgrensesnittet viser dei indre pakkane, det er trafikken applikasjonen trur han sender. Opptak samstundes på det fysiske grensesnittet viser dei ytre pakkane, og dei to saman er den tydelegaste demonstrasjonen av kva ein tunnel faktisk gjer.

Tre adresser, og berre éi blir sett av nettstaden

Folk forvekslar desse heile tida, og forvirringa lagar falske lekkasjerapportar. Det er ulike felt i ulike overskrifter med ulik levetid.

Nummeret ved sida av den virtuelle adapteren er den andre rada. Det er ikkje adressa ein nettstad registrerer, og å sitere det som den offentlege IP-en din er rett og slett feil. Adressa ein nettstad ser, blir tildelt av utgangen, og for ein tunnel til eit privat nettverk er det kanskje ingen offentleg utgang i det heile, fordi målet ligg inne i organisasjonen og ikkje på internett.

Ein tunnel mellom lokasjonar er den same mekanismen med andre endepunkt. To rutarar pakkar trafikk inn mellom nettverk, og inga einskild eining har ein klient installert. Konvolutten er identisk i prinsippet, den administrative grensa er det ikkje.

Kvar konvolutten blir opna, og kva som overlever han

Tunnelen endar ved partnaren sin. Viss krypteringa til applikasjonen sjølv rekk lenger, overlever ho den grensa, noko som er det normale tilfellet for HTTPS: sesjonen til nettlesaren blir avslutta på nettstaden, så utgangen sender vidare chiffertekst han ikkje kan lese.

Ingenting anna overlever som standard. Ein ukryptert førespurnad er lesbar ved utgangen akkurat slik han var lesbar på Wi-Fi-en på kafeen, og tunnelen legg ikkje til vern applikasjonen aldri hadde. På same måte avgjer brannmurreglane og videresendingspolitikken til utgangen kva som skjer vidare; eit vellukka handtrykk er eit faktum om partnarsambandet, ikkje om resten av reisa.

Overhead er den andre synlege konsekvensen. Kvar pakke ber ei ekstra overskrift, og den ytre transporten kan leggje til si eiga, så den brukbare nyttelasta per pakke krympar. På ein veg med fast maksimal overføringseining er det nettopp difor ein tunnel kan sleppe gjennom ein ping og stoppe ei stor opplasting.

Kontroller vegen applikasjonen faktisk tok

Det siste steget er å stadfeste den konkrete applikasjonen, ikkje maskina generelt. Slå opp målet, sjå på ruta for den adressa, og observer så sambandet medan det er ope:

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

Viss ruta nemner tunnelen, men socket-lista viser eit samband med ei kjeldeadresse frå det fysiske grensesnittet, er applikasjonen bunden til noko spesifikt, eller ein annan tunnel konkurrerer om standardruta. Det er eit rutingspørsmål, og det kan svarast på frå desse tre utskriftene i staden for statusskjermen til klienten.

Tryggingsarkitekturen RFC 4301 skildrar IP-lagsversjonen av denne innpakkinga for IPsec, og den same laglogikken gjeld for WireGuard og OpenVPN. Når du først kan peike på den indre pakken og den ytre pakken som separate objekt, sluttar det meste av tunnelåtferd å vere mystisk og blir ein rutetabell du kan lese.