Encadenar dues VPN: què amaga i quant costa

Dos túnels imbricats no us fan anònims. El que fan és repartir les observacions entre dos proveïdors, de manera que cap dels dos no veu alhora la vostra adreça de casa i la vostra destinació. És un benefici real però estret, i arriba amb problemes d'encaminament, DNS i MTU que es manifesten la primera vegada que hi confieu.

1. Decidiu per a què serveix el segon salt

Escriviu l'objectiu en una sola frase abans de configurar res. Si és que el vostre ISP no pugui veure quins llocs visiteu, un túnel ho aconsegueix. Si és que cap proveïdor pugui lligar la vostra adreça amb el vostre trànsit, dos ho fan. Si és que ningú no us pugui identificar, cap nombre de salts hi arriba.

La cadena és tan forta com els registres del proveïdor més feble i els comptes que tots dos guarden. Els pagaments, el correu de registre i la telemetria de l'aplicació queden completament fora del túnel.

2. Feu que l'extrem interior sigui abastable a través del túnel exterior

La fallada habitual és que el túnel interior no s'estableixi mai. Una connexió exterior de túnel complet posseeix la ruta per defecte, així que l'intent del client interior d'arribar al seu propi extrem queda engolit pel túnel exterior i es descarta o es posa en bucle. L'extrem interior necessita una ruta explícita per la interfície exterior, instal·lada abans que arrenqui el client interior. Si no, l'handshake competeix amb la ruta i perd.

WireGuard mostra el mateix conflicte des de l'altre costat. El paràmetre AllowedIPs de cada peer decideix quines destinacions entren en aquell túnel, així que una interfície interior que reclama totes les adreces també reclama l'extrem exterior, tret que guanyi una ruta més específica. Solapar AllowedIPs entre dues interfícies és una configuració en què un costat perd en silenci.

L'encadenament de contenidors fa explícita la separació i òbvia la trampa. Un contenidor amb el seu propi espai de noms, la seva pròpia ruta per defecte i un client a dins reenvia el que l'amfitrió li envia; l'amfitrió no comença a fer servir aquell camí per si sol. Activeu el reenviament, afegiu una ruta per al túnel del contenidor i adreceu el servei a l'adreça del contenidor.

3. Manteniu el DNS al mateix camí

El DNS ha de viatjar on viatja el trànsit. Si el proveïdor interior us envia resolvers i l'amfitrió encara consulta els locals, aquestes consultes revelen exactament els llocs que el túnel havia d'amagar. Comproveu-ho amb una captura a cada interfície de túnel en lloc de confiar en el panell d'estat del client. Aquí una fuita és invisible durant la navegació normal i evident en una captura.

Els dissenys de DNS dividit ho fan més difícil, perquè una consulta d'un nom local pot pertànyer legítimament a fora del túnel. Escriviu la llista d'excepcions deliberadament en lloc de descobrir-la segons quin resolver hagi respost.

4. Fixeu l'MTU abans que els usuaris ho descobreixin per vosaltres

L'MTU és l'altra víctima previsible. Dues encapsulacions resten dues capçaleres, i un túnel exterior que ja ha baixat l'MTU del camí deixa menys espai a dins. Els símptomes són coneguts: les peticions petites passen, les transferències grans i els handshakes TLS s'encallen.

ip link set dev wg1 mtu 1280 és la solució contundent, i limitar l'MSS al reenviador és la més polida. Tornar a provar la connexió no és cap solució.

5. Proveu la fallada que realment tindreu

Trenqueu el túnel exterior expressament i mireu què passa. Una cadena que cau en silenci a un camí directe quan mor el salt exterior és pitjor que no tenir cadena, perquè filtra just en el moment que creieu estar cobert. El comportament que voleu és un kill switch que aturi tot el trànsit. Anoteu el resultat, perquè no voldreu redescobrir-lo enmig d'un incident.

La latència i un segon punt de fallada són el cost permanent. Dos salts també volen dir dues cues de suport quan alguna cosa es trenca a una hora incòmoda.