At kæde to VPN'er sammen: hvad det skjuler, og hvad det koster

To indlejrede tunneler gør dig ikke anonym. De deler observationerne mellem to udbydere, så ingen af dem ser din hjemadresse og din destination samtidig. Det er en ægte, men snæver fordel, og den kommer med routing-, DNS- og MTU-problemer, som dukker op første gang, du er afhængig af den.

1. Beslut, hvad det andet hop skal bruges til

Skriv målet i én sætning, før du konfigurerer noget. Hvis målet er, at din udbyder ikke kan se, hvilke websteder du besøger, opnår én tunnel det. Hvis målet er, at ingen enkelt udbyder kan knytte din adresse til din trafik, gør to det. Hvis målet er, at ingen kan identificere dig, kommer ingen mængde hop derhen.

Kæden er kun så stærk som den svagere udbyders logfiler og de konti, de begge fører. Betalinger, tilmeldings-e-mail og app-telemetri ligger helt uden for tunnelen.

2. Gør det indre endepunkt tilgængeligt gennem den ydre tunnel

Den sædvanlige fejl er, at den indre tunnel aldrig etableres. En ydre forbindelse med fuld tunnel ejer standardruten, så den indre klients forsøg på at nå sit eget endepunkt sluges af den ydre tunnel og droppes eller sendes i ring. Det indre endepunkt har brug for en eksplicit rute gennem det ydre interface, installeret før den indre klient starter. Ellers løber handshaket om kap med ruten og taber.

WireGuard viser den samme konflikt fra den anden side. Hver peers AllowedIPs afgør, hvilke destinationer der går ind i den tunnel, så et indre interface, der gør krav på hver adresse, gør også krav på det ydre endepunkt, medmindre en mere specifik rute vinder. Overlappende AllowedIPs på tværs af to interfaces er en konfiguration, hvor den ene side taber i stilhed.

Containerkæder gør adskillelsen eksplicit og fælden indlysende. En container med sit eget namespace, sin egen standardrute og en klient indeni videresender det, værten sender til den; værten begynder ikke selv at bruge den vej. Slå videresendelse til, tilføj en rute til containerens tunnel, og peg tjenesten mod containerens adresse.

3. Hold DNS på samme vej

DNS skal rejse, hvor trafikken rejser. Hvis den indre udbyder sender resolvere, og værten stadig spørger de lokale, afslører de opslag præcis de websteder, tunnelen skulle skjule. Kontroller med en optagelse på hver tunnel-interface i stedet for at stole på klientens statuspanel. En lækage her er usynlig under normal browsing og tydelig i en optagelse.

Delte DNS-design gør det sværere, fordi en forespørgsel på et lokalt navn sagtens kan høre til uden for tunnelen. Skriv undtagelseslisten bevidst i stedet for at opdage den ud fra, hvilken resolver der tilfældigvis svarede.

4. Sæt MTU, før brugerne opdager det for dig

MTU er det andet forudsigelige offer. To indkapslinger trækker to headers fra, og en ydre tunnel, der allerede har sænket stiens MTU, efterlader mindre plads indeni. Symptomerne er velkendte: små forespørgsler lykkes, store overførsler og TLS-handshakes går i stå.

ip link set dev wg1 mtu 1280 er den grove løsning, og at klemme MSS på videresenderen er den pænere. At prøve forbindelsen igen er slet ikke en løsning.

5. Test den fejl, du faktisk kommer til at få

Bryd den ydre tunnel med vilje, og se, hvad der sker. En kæde, der i stilhed falder tilbage til en direkte vej, når det ydre hop dør, er værre end ingen kæde, fordi den lækker præcis i det øjeblik, du troede, du var dækket. En kill switch, der stopper al trafik, er den adfærd, du skal sigte efter. Notér resultatet, for du vil ikke genopdage det midt i en hændelse.

Latenstid og et andet fejlpunkt er de faste omkostninger. To hop betyder også to supportkøer, når noget går i stykker på et ubelejligt tidspunkt.