Å kjede to VPN-er: hva det skjuler, og hva det koster

To innebygde tunneler gjør deg ikke anonym. De fordeler observasjonene mellom to leverandører, så ingen av dem ser hjemadressen din og destinasjonen din samtidig. Det er en reell, men smal fordel, og den kommer med ruting-, DNS- og MTU-problemer som dukker opp første gang du er avhengig av den.

1. Bestem hva det andre hoppet er til

Skriv målet i én setning før du konfigurerer noe. Hvis målet er at leverandøren din ikke kan se hvilke nettsteder du besøker, oppnår én tunnel det. Hvis målet er at ingen enkelt leverandør kan knytte adressen din til trafikken din, gjør to det. Hvis målet er at ingen kan identifisere deg, kommer ingen mengde hopp dit.

Kjeden er bare så sterk som loggene til den svakere leverandøren og kontoopplysningene begge fører. Betalinger, påmeldings-e-post og apptelemetri ligger helt utenfor tunnelen.

2. Gjør det indre endepunktet tilgjengelig gjennom den ytre tunnelen

Den vanlige feilen er at den indre tunnelen aldri etableres. En ytre forbindelse med full tunnel eier standardruten, så den indre klientens forsøk på å nå sitt eget endepunkt slukes av den ytre tunnelen og droppes eller sendes i løkke. Det indre endepunktet trenger en eksplisitt rute gjennom det ytre grensesnittet, installert før den indre klienten starter. Ellers kappløper håndtrykket med ruten og taper.

WireGuard viser den samme konflikten fra den andre siden. Hver peers AllowedIPs avgjør hvilke destinasjoner som går inn i den tunnelen, så et indre grensesnitt som gjør krav på hver adresse gjør også krav på det ytre endepunktet, med mindre en mer spesifikk rute vinner. Overlappende AllowedIPs på tvers av to grensesnitt er en konfigurasjon der den ene siden taper i stillhet.

Containerkjeding gjør skillet eksplisitt og fellen åpenbar. En container med eget navnerom, egen standardrute og en klient inni videresender det verten sender den; verten begynner ikke selv å bruke den veien. Slå på videresending, legg til en rute for containerens tunnel og pek tjenesten mot containerens adresse.

3. Hold DNS på samme vei

DNS må reise dit trafikken reiser. Hvis den indre leverandøren skyver resolvere og verten fortsatt spør de lokale, avslører de oppslagene nøyaktig de nettstedene tunnelen skulle skjule. Kontroller med en opptak på hvert tunnelgrensesnitt i stedet for å stole på klientens statuspanel. En lekkasje her er usynlig under vanlig surfing og tydelig i et opptak.

Delte DNS-design gjør dette vanskeligere, fordi en forespørsel om et lokalt navn legitimt kan høre til utenfor tunnelen. Skriv unntakslisten bevisst i stedet for å oppdage den ut fra hvilken resolver som tilfeldigvis svarte.

4. Sett MTU før brukerne oppdager det for deg

MTU er det andre forutsigbare offeret. To innkapslinger trekker fra to hoder, og en ytre tunnel som allerede har senket banens MTU, etterlater mindre plass inni. Symptomene er kjente: små forespørsler lykkes, store overføringer og TLS-håndtrykk stopper.

ip link set dev wg1 mtu 1280 er den grove løsningen, og å klemme MSS på videresenderen er den penere. Å prøve forbindelsen på nytt er ikke en løsning i det hele tatt.

5. Test feilen du faktisk kommer til å få

Bryt den ytre tunnelen med vilje og se hva som skjer. En kjede som i stillhet faller tilbake til en direkte vei når det ytre hoppet dør, er verre enn ingen kjede, fordi den lekker nøyaktig i det øyeblikket du trodde du var dekket. En kill switch som stopper all trafikk er atferden du skal sikte mot. Noter resultatet, for du vil ikke gjenoppdage det midt i en hendelse.

Forsinkelse og et andre feilpunkt er de faste kostnadene. To hopp betyr også to støttekøer når noe går i stykker på et ubeleilig tidspunkt.