Å kjetta to VPN-ar: kva det skjuler og kva det kostar
Nøsta tunnelar endrar kven som ser kva endepunkt, ikkje kven som ser deg. Leie det indre endepunktet gjennom den ytre tunnelen og kontroller deretter DNS, MTU og fallback.
To nøsta tunnelar gjer deg ikkje anonym. Dei fordel observasjonane mellom to leverandørar, så ingen av dei ser heimeadressa di og destinasjonen din samstundes. Det er ein reell, men smal føremon, og han kjem med rutings-, DNS- og MTU-problem som dukkar opp første gongen du er avhengig av han.
1. Avgjer kva det andre hoppet skal brukast til
Skriv målet i éi setning før du konfigurerer noko. Er målet at nettpakkeleverandøren din ikkje skal sjå kva nettstader du vitjar, held éin tunnel. Er målet at ingen einaste leverandør kan kopla adressa di til trafikken din, trengst to. Er målet at ingen kan identifisera deg, kjem ingen mengd hopp dit.
Kjeda er berre så sterk som loggføringa til den svakare leverandøren og kontoopplysningane begge fører. Betalingar, e-post ved registrering og apptelemetri ligg heilt utanfor tunnelen.
2. Gjer det indre endepunktet tilgjengeleg gjennom den ytre tunnelen
Den vanlege feilen er at den indre tunnelen aldri kjem opp. Ei ytre tilkopling i full tunnel-modus eig standardruta, så forsøket til den indre klienten på å nå sitt eige endepunkt blir slukt av den ytre tunnelen og droppa eller sendt i løkke. Det indre endepunktet treng ei eksplisitt rute gjennom det ytre grensesnittet, lagd inn før den indre klienten startar. Elles kapplaupar handtrykket mot ruta og tapar.
Hjå kvar peer avgjer AllowedIPs kva destinasjonar som går inn i den tunnelen, så eit indre grensesnitt som krev kvar adresse, krev òg det ytre endepunktet med mindre ei meir spesifikk rute vinn. Overlappande AllowedIPs over to grensesnitt er ein konfigurasjon der éi side tapar i stillheit.
Container-kjeding gjer skiljet eksplisitt og fella openberr. Ein container med eige namnerom, eiga standardrute og ein klient inni videresender det verten sender til han; verten byrjar ikkje å bruka den vegen av seg sjølv. Slå på videresending, legg til ei rute for tunnelen til containeren og peik tenesta mot adressa til containeren.
3. Hald DNS på same veg
DNS må reisa dit trafikken reiser. Viss den indre leverandøren dyttar inn resolvarar og verten framleis spør dei lokale, røpar dei oppslaga nøyaktig dei nettstadene tunnelen skulle skjula. Kontroller med ein fangst på kvart tunngrensesnitt i staden for å stola på statuspanelet til klienten. Ein lekkasje her er usynleg under vanleg surfing og openberr i ein fangst.
Split-DNS-oppsett gjer dette vanskelegare, fordi eit oppslag på eit lokalt namn med rette kan høyra heime utanfor tunnelen. Skriv unntakslista med vilje i staden for å oppdaga ho via den resolvaren som tilfeldigvis svara.
4. Set MTU før brukarane finn det ut for deg
MTU er det andre føreseielege offeret. To innkapslingar trekkjer frå to headarar, og ein ytre tunnel som alt har senka bane-MTU-en, gir mindre plass inni. Symptoma er kjende: små førespurnader lukkast, store overføringar og TLS-handtrykk stoppar.
ip link set dev wg1 mtu 1280 er den grove fiksen, og å klemma MSS på videresendaren er den penare. Å prøva tilkoplinga på nytt er ikkje ein fiks i det heile.
5. Test feilen du faktisk kjem til å få
Bryt den ytre tunnelen med vilje og sjå kva som skjer. Ei kjede som i stillheit fell tilbake til ein direkte veg når det ytre hoppet døyr, er verre enn inga kjede, fordi ho lekk akkurat i det augneblinken du trudde du var dekt. Ein kill switch som stoggar all trafikk er åtferda å sikta mot. Skriv ned resultatet, for du vil ikkje oppdaga det på nytt midt i ei hending.
Forsinking og eit andre feilpunkt er dei faste kostnadene. To hopp tyder òg to støttekøar når noko ryker på eit ubeleileg tidspunkt.