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

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

1. Bestem hva det andre hoppet skal brukes til

Skriv målet i én setning før du konfigurerer noe. Er målet at internettleverandøren din ikke skal se hvilke nettsteder du besøker, holder én tunnel. Er målet at ingen enkelt leverandør kan koble adressen din til trafikken din, trengs to. Er målet at ingen kan identifisere deg, kommer ingen mengde hopp dit.

Kjeden er bare så sterk som loggføringen til den svakere leverandøren og kontoopplysningene begge fører. Betalinger, e-post ved registrering 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 kommer opp. En ytre tilkobling i full tunnel-modus eier standardruten, så forsøket fra den indre klienten på å nå sitt eget endepunkt blir slukt av den ytre tunnelen og droppet eller sendt i løkke. Det indre endepunktet trenger en eksplisitt rute gjennom det ytre grensesnittet, lagt inn før den indre klienten starter. Ellers kappløper håndtrykket mot ruten og taper.

Hos hver peer avgjør AllowedIPs hvilke destinasjoner som går inn i den tunnelen, så et indre grensesnitt som krever hver adresse, krever også det ytre endepunktet med mindre en mer spesifikk rute vinner. Overlappende AllowedIPs over to grensesnitt er en konfigurasjon der én side taper i stillhet.

Container-kjeding gjør skillet eksplisitt og fellen innlysende. En container med eget navnerom, egen standardrute og en klient inni videresender det verten sender til den; verten begynner ikke å bruke den veien av seg selv. 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 dytter inn resolvere og verten fortsatt spør de lokale, avslører de oppslagene nøyaktig de nettstedene tunnelen skulle skjule. Kontroller med en fangst på hvert tunngrensesnitt i stedet for å stole på statuspanelet til klienten. En lekkasje her er usynlig under vanlig surfing og åpenbar i en fangst.

Split-DNS-oppsett gjør dette vanskeligere, fordi et oppslag på et lokalt navn med rette kan høre hjemme utenfor tunnelen. Skriv unntakslisten med vilje i stedet for å oppdage den via den resolveren som tilfeldigvis svarte.

4. Sett MTU før brukerne finner det ut for deg

MTU er det andre forutsigbare offeret. To innkapslinger trekker fra to headere, og en ytre tunnel som allerede har senket bane-MTU-en, gir 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 fiksen, og å klemme MSS på videresenderen er den penere. Å prøve tilkoblingen på nytt er ikke en fiks 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 akkurat i det øyeblikket du trodde du var dekket. En kill switch som stopper all trafikk er oppførselen å sikte mot. Skriv ned resultatet, for du vil ikke oppdage det på nytt midt i en hendelse.

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