Att kedja två VPN: vad det döljer och vad det kostar

Två kapslade tunnlar gör dig inte anonym. De delar observationerna mellan två leverantörer, så ingen av dem ser din hemadress och din destination samtidigt. Det är en verklig men snäv fördel, och den kommer med problem med routing, DNS och MTU som dyker upp första gången du förlitar dig på den.

1. Bestäm vad det andra hoppet ska användas till

Skriv målet i en mening innan du konfigurerar något. Gäller det att din internetleverantör inte ska se vilka webbplatser du besöker, räcker en tunnel. Gäller det att ingen enskild leverantör ska kunna koppla din adress till din trafik, behövs två. Gäller det att ingen ska kunna identifiera dig, kommer inget antal hopp dit.

Kedjan är bara så stark som den svagare leverantörens loggning och de kontouppgifter båda för. Betalningar, e-post vid registrering och apptelemetri ligger helt utanför tunneln.

2. Gör den inre ändpunkten nåbar genom den yttre tunneln

Det vanliga felet är att den inre tunneln aldrig etableras. En yttre anslutning i fulltunnel-läge äger standardrutten, så den inre klientens försök att nå sin egen ändpunkt slukas av den yttre tunneln och tappas eller hamnar i loop. Den inre ändpunkten behöver en explicit rutt genom det yttre gränssnittet, installerad innan den inre klienten startar. Annars kapplöper handskakningen mot rutten och förlorar.

WireGuard visar samma konflikt från andra hållet. Hos varje peer avgör AllowedIPs vilka destinationer som går in i den tunneln, så ett inre gränssnitt som gör anspråk på varje adress gör också anspråk på den yttre ändpunkten om inte en mer specifik rutt vinner. Överlappande AllowedIPs på två gränssnitt är en konfiguration där ena sidan tyst förlorar.

Container-kedjning gör separationen explicit och fällan uppenbar. En container med eget namnutrymme, egen standardrutt och en klient inuti vidarebefordrar det värden skickar till den; värden börjar inte använda den vägen själv. Aktivera vidarebefordran, lägg till en rutt för containerns tunnel och peka tjänsten mot containerns adress.

3. Håll DNS på samma väg

DNS måste resa dit trafiken reser. Om den inre leverantören trycker in resolvers och värden fortfarande frågar de lokala, avslöjar de uppslagen exakt de webbplatser tunneln skulle dölja. Kontrollera med en fångst på varje tunnelgränssnitt i stället för att lita på klientens statuspanel. En läcka här är osynlig vid normalt surfande och uppenbar i en fångst.

Delade DNS-upplägg gör detta svårare, eftersom en fråga om ett lokalt namn med rätta kan höra hemma utanför tunneln. Skriv undantagslistan med avsikt i stället för att upptäcka den via den resolver som råkade svara.

4. Sätt MTU innan användarna upptäcker det åt dig

MTU är det andra förutsägbara offret. Två inkapslingar drar av två huvuden, och en yttre tunnel som redan sänkt banans MTU lämnar mindre plats inuti. Symtomen är bekanta: små förfrågningar lyckas, stora överföringar och TLS-handskakningar stannar.

ip link set dev wg1 mtu 1280 är den grova lösningen, och att klämma MSS på vidarebefordraren är den snyggare. Att försöka igen med anslutningen är ingen lösning alls.

5. Testa det fel du faktiskt kommer att få

Bryt den yttre tunneln med avsikt och se vad som händer. En kedja som tyst faller tillbaka till en direkt väg när det yttre hoppet dör är värre än ingen kedja, eftersom den läcker precis i det ögonblick du trodde du var täckt. En kill switch som stoppar all trafik är beteendet att sträva efter. Anteckna resultatet, för du vill inte upptäcka det igen mitt i en incident.

Fördröjning och en andra felpunkt är de stående kostnaderna. Två hopp betyder också två supportköer när något går sönder vid en olämplig tid.