Encadear dúas VPN: que oculta e canto custa

Dous túneles aniñados non te fan anónimo. O que fan é repartir as observacións entre dous provedores, así que ningún ve xuntos o teu enderezo de casa e o teu destino. É un beneficio real pero estreito, e chega con problemas de encamiñamento, DNS e MTU que aparecen a primeira vez que dependes del.

1. Decide para que serve o segundo salto

Escribe o obxectivo nunha soa frase antes de configurar nada. Se é que o teu ISP non pode ver que sitios visitas, un túnel conségueo. Se é que ningún provedor pode vincular o teu enderezo co teu tráfico, dous conségueno. Se é que ninguén pode identificarte, ningún número de saltos chega alí.

A cadea é tan forte como os rexistros do provedor máis feble e as contas que ambos gardan. Os pagamentos, o correo de rexistro e a telemetría da aplicación quedan por completo fóra do túnel.

2. Fai que o extremo interior sexa alcanzable a través do túnel exterior

O fallo habitual é que o túnel interior nunca se establece. Unha conexión exterior de túnel completo posúe a ruta por defecto, así que o intento do cliente interior de chegar ao seu propio extremo queda tragado polo túnel exterior e descártase ou entra en bucle. O extremo interior necesita unha ruta explícita pola interface exterior, instalada antes de que arranque o cliente interior. Se non, o handshake compite coa ruta e perde.

WireGuard mostra o mesmo conflito desde a outra dirección. Os AllowedIPs de cada peer deciden que destinos entran nese túnel, así que unha interface interior que reclama todos os enderezos tamén reclama o extremo exterior, salvo que gañe unha ruta máis específica. Solapar AllowedIPs entre dúas interfaces é unha configuración na que un lado perde en silencio.

A encadea de contedores fai explícita a separación e obvia a trampa. Un contedor co seu propio espazo de nomes, a súa propia ruta por defecto e un cliente dentro reenvía o que o host lle envía; o host non comeza a usar ese camiño por si só. Activa o reenvío, engade unha ruta para o túnel do contedor e apunta o servizo ao enderezo do contedor.

3. Mantén o DNS no mesmo camiño

O DNS ten que viaxar por onde viaxa o tráfico. Se o provedor interior empuxa resolutores e o host segue consultando os locais, esas consultas revelan exactamente os sitios que o túnel debía ocultar. Compróbao cunha captura en cada interface de túnel en vez de fiarte do panel de estado do cliente. Unha fuga aquí é invisible durante a navegación normal e evidente nunha captura.

Os deseños de DNS dividido dificúltano, porque unha consulta dun nome local pode pertencer lexitimamente fóra do túnel. Escribe a lista de excepcións a propósito en lugar de descubrila segundo que resolutor respondeu.

4. Axusta o MTU antes de que os usuarios o descubran por ti

O MTU é a outra vítima previsible. Dous encapsulamentos restan dúas cabeceiras, e un túnel exterior que xa baixou o MTU da ruta deixa menos espazo dentro. Os síntomas son coñecidos: as peticións pequenas pasan, as transferencias grandes e os handshakes TLS atópanse.

ip link set dev wg1 mtu 1280 é a solución contundente, e limitar o MSS no reenviador é a máis pulida. Reintentar a conexión non é solución ningunha.

5. Proba o fallo que de verdade vas ter

Racha o túnel exterior a propósito e observa que pasa. Unha cadea que cae en silencio a un camiño directo cando morre o salto exterior é peor que non ter cadea, porque filtra xusto no momento en que crías estar cuberto. O comportamento desexable é un kill switch que deteña todo o tráfico. Anota o resultado, porque non quererás redescubrilo no medio dun incidente.

A latencia e un segundo punto de fallo son o custo permanente. Dous saltos tamén significan dúas colas de soporte cando algo se rompe a unha hora incómoda.