Twee VPN's koppelen: wat het verbergt en wat het kost

Twee geneste tunnels maken je niet anoniem. Ze verdelen de waarnemingen over twee providers, zodat geen van beide je thuisadres en je bestemming tegelijk ziet. Dat is een echt maar smal voordeel, en het komt met routerings-, DNS- en MTU-problemen die pas blijken wanneer je er echt op vertrouwt.

1. Bepaal waarvoor de tweede hop dient

Schrijf het doel in één zin op voordat je iets configureert. Gaat het erom dat je ISP niet ziet welke sites je bezoekt, dan volstaat één tunnel. Gaat het erom dat geen enkele provider jouw adres aan je verkeer kan koppelen, dan zijn het er twee. Gaat het erom dat niemand je kan identificeren, dan kom je met geen enkel aantal hops daar.

De ketting is maar zo sterk als de logging van de zwakkere provider en de accountgegevens die beide bijhouden. Betalingen, e-mailadres bij aanmelding en apptelemetrie vallen volledig buiten de tunnel.

2. Maak het binnenste eindpunt bereikbaar via de buitenste tunnel

De gebruikelijke storing is dat de binnenste tunnel nooit tot stand komt. Een buitenste verbinding in volledige-tunnelmodus bezit de standaardroute, dus de poging van de binnenste client om zijn eigen eindpunt te bereiken wordt door de buitenste tunnel opgeslokt en weggegooid of in een lus gestuurd. Het binnenste eindpunt heeft een expliciete route via de buitenste interface nodig, ingesteld voordat de binnenste client start. Anders racet de handshake tegen de route en verliest.

WireGuard laat hetzelfde conflict vanuit de andere richting zien. De AllowedIPs van elke peer bepaalt welke bestemmingen die tunnel in gaan, dus een binnenste interface die elk adres opeist, eist ook het buitenste eindpunt op, tenzij een specifiekere route wint. Overlappende AllowedIPs op twee interfaces is een configuratie waarin één kant stilletjes verliest.

Container-ketening maakt de scheiding expliciet en de valkuil zichtbaar. Een container met een eigen namespace, een eigen standaardroute en een client erin stuurt door wat de host hem toewijst; de host gaat die route niet vanzelf gebruiken. Zet forwarding aan, voeg een route toe voor de tunnel van de container en wijs de dienst naar het adres van de container.

3. Houd DNS op hetzelfde pad

DNS moet reizen waar het verkeer reist. Als de binnenste provider resolvers pusht en de host nog de lokale raadpleegt, verraden die opzoekingen precies de sites die de tunnel moest verbergen. Controleer met een capture op elke tunnelinterface in plaats van het statuspaneel van de client te vertrouwen. Een lek hier is onzichtbaar tijdens normaal browsen en overduidelijk in een capture.

Split-DNS-ontwerpen maken dit lastiger, omdat een query voor een lokale naam terecht buiten de tunnel kan horen. Schrijf de uitzonderingenlijst bewust op in plaats van hem te ontdekken via welke resolver toevallig antwoordde.

4. Stel MTU in voordat gebruikers het voor je ontdekken

MTU is het andere voorspelbare slachtoffer. Twee inkapselingen trekken twee headers af, en een buitenste tunnel die de pad-MTU al verlaagd heeft, laat binnen minder ruimte over. De symptomen zijn bekend: kleine verzoeken slagen, grote overdrachten en TLS-handshakes blijven hangen.

ip link set dev wg1 mtu 1280 is de botte oplossing, en MSS knijpen op de forwarder is de nettere. De verbinding opnieuw proberen is helemaal geen oplossing.

5. Test de storing die je echt krijgt

Breek de buitenste tunnel expres en kijk wat er gebeurt. Een ketting die stilletjes terugvalt op een direct pad wanneer de buitenste hop sterft, is erger dan geen ketting, omdat hij lekt precies op het moment dat je dacht gedekt te zijn. Een kill switch die al het verkeer stopt, is het gedrag om naar te streven. Leg het resultaat vast, want je wilt het niet midden in een incident opnieuw ontdekken.

Latentie en een tweede storingspunt zijn de vaste kosten. Twee hops betekenen ook twee supportrijen wanneer er iets op een onhandig uur stukgaat.