Wat een VPN-tunnel is, en waar de bescherming ophoudt

De client zegt verbonden, het slotje is dicht, en een site registreert nog steeds het adres van je flat. Niets is mislukt. Een tunnel vervangt je Wi-Fi of je mobiele verbinding niet; hij legt een tweede envelop om bepaalde pakketten en stuurt die envelop over het netwerk dat je al had. De truc begrijpen draait vooral om één verzoek volgen en opmerken waar de envelop wordt geopend, want bijna elk verwarrend symptoom, van een weglekkend thuisadres tot een vastgelopen grote download, komt van die grens.

Twee enveloppen, één fysieke verbinding

Je laptop houdt zijn normale verbinding met de router, en de router houdt zijn normale verbinding met de provider. Niets op dat pad verandert wanneer er een tunnel opkomt. Wat verandert, is dat geselecteerde pakketten aan een virtuele interface worden gegeven, in een nieuw pakket verpakt dat aan de VPN-partner is geadresseerd, en als gewoon verkeer over de fysieke verbinding worden gestuurd.

De ontvangende kant is een apparaat dat de envelop opent en het oorspronkelijke pakket naar zijn bestemming doorstuurt. Tussen de twee uiteinden ziet een waarnemer de buitenste kop en niets over de binnenste, tenzij het protocol die versleutelt, wat de meeste consumentenprotocollen doen en de algemene techniek niet vereist.

Daarom is de virtuele interface zowel echt als misleidend. Hij bestaat als een kernelobject met een adres en een maximale transmissie-eenheid, en het besturingssysteem routeert verkeer erin zoals in elke andere interface. Het is geen kabel, en zijn bestaan bewijst alleen dat een component is geïnstalleerd. Of je browser hem gebruikt, bepalen routes, niet of de interface omhoog staat.

Volg één verzoek op reis

Kies een bestemming en vraag de kernel welke interface hij zal gebruiken. Dit ene commando beslecht de meeste discussies over of de tunnel iets doet:

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

Als de route-uitvoer de tunnelinterface noemt, wordt het pakket ingepakt. Als hij de fysieke interface noemt, gebeurt dat niet, en geen herstart van de client verandert dat. Het tweede commando toont beide interfaces naast elkaar, en zo merk je een tunnel op die omhoogkwam zonder adres of met een adres uit de verkeerde familie.

Kijk dan naar de eerste hop van binnen de envelop en vergelijk die met de eerste hop van buiten:

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

Binnen de tunnel is de eerste hop het binnenadres van de peer, niet je router. De capture op de tunnelinterface toont de binnenste pakketten, dat is het verkeer dat de applicatie denkt te verzenden. Tegelijk op de fysieke interface capturen toont de buitenste pakketten, en samen zijn ze de duidelijkste demonstratie van wat een tunnel werkelijk doet.

Drie adressen, en de site ziet er maar één

Mensen halen deze constant door elkaar, en de verwarring levert valse lekrapporten op. Het zijn verschillende velden in verschillende koppen met verschillende levensduur.

Het nummer naast de virtuele adapter is de tweede rij. Het is niet het adres dat een site vastlegt, en het als je publieke IP noemen is simpelweg fout. Het adres dat een site ziet, wordt door de uitgang toegewezen, en bij een tunnel naar een privénetwerk is er misschien helemaal geen openbare uitgang, omdat de bestemming binnen de organisatie ligt en niet op internet.

Een tunnel tussen locaties is hetzelfde mechanisme met andere eindpunten. Twee routers pakken verkeer tussen netwerken in, en geen enkel afzonderlijk apparaat heeft een client geïnstalleerd. De envelop is in principe identiek, de administratieve grens niet.

Waar de envelop wordt geopend, en wat die overleeft

De tunnel eindigt bij zijn peer. Als de versleuteling van de applicatie zelf verder reikt, overleeft die deze grens, wat het normale geval bij HTTPS is: de sessie van de browser eindigt bij de site, dus de uitgang stuurt cijfertekst door die hij niet kan lezen.

Niets anders overleeft standaard. Een onversleuteld verzoek is bij de uitgang leesbaar precies zoals het op de Wi-Fi van het café leesbaar was, en de tunnel voegt geen bescherming toe die de applicatie nooit had. Evenzo bepalen de firewallregels en het doorstuurbeleid van de uitgang wat er daarna gebeurt; een geslaagde handshake is een feit over de peerverbinding, niet over de rest van de reis.

Overhead is het andere zichtbare gevolg. Elk pakket draagt een extra kop, en het buitenste transport kan de zijne toevoegen, waardoor de bruikbare payload per pakket krimpt. Op een pad met een vaste maximale transmissie-eenheid is dat precies waarom een tunnel een ping doorlaat en een grote upload laat vastlopen.

Controleer het pad dat de applicatie echt heeft genomen

De laatste stap is de specifieke applicatie bevestigen, niet de machine in het algemeen. Los de bestemming op, kijk naar de route voor dat adres, en observeer dan de verbinding terwijl die open is:

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

Als de route de tunnel noemt maar de socketlijst een verbinding toont met een bronadres van de fysieke interface, is de applicatie aan iets specifieks gebonden, of concurreert een tweede tunnel om de standaardroute. Dat is een routingvraag, en die is te beantwoorden uit deze drie uitvoer, niet uit het statusscherm van de client.

De beveiligingsarchitectuur RFC 4301 beschrijft de IP-laagversie van deze inkapseling voor IPsec, en dezelfde laaglogica geldt voor WireGuard en OpenVPN. Zodra je het binnenste pakket en het buitenste pakket als afzonderlijke objecten kunt aanwijzen, houdt het meeste tunnelgedrag op mysterieus te zijn en wordt het een routingtabel die je kunt lezen.