Concatenare due VPN: cosa nasconde e quanto costa

Due tunnel annidati non ti rendono anonimo. Il loro effetto è ripartire le osservazioni tra due fornitori, così nessuno dei due vede insieme il tuo indirizzo di casa e la tua destinazione. È un beneficio reale ma stretto, e arriva con problemi di routing, DNS e MTU che si presentano la prima volta che ci fai affidamento.

1. Decidi a cosa serve il secondo salto

Scrivi l'obiettivo in una sola frase prima di configurare qualsiasi cosa. Se l'obiettivo è che il tuo ISP non veda quali siti visiti, un tunnel lo ottiene. Se è che nessun fornitore singolo possa collegare il tuo indirizzo al tuo traffico, due lo ottengono. Se è che nessuno possa identificarti, nessun numero di salti ci arriva.

La catena è forte solo quanto i registri del fornitore più debole e i dati dell'account che entrambi conservano. Pagamenti, email di iscrizione e telemetria dell'app restano del tutto fuori dal tunnel.

2. Rendi raggiungibile l'estremità interna attraverso il tunnel esterno

Il guasto abituale è che il tunnel interno non si stabilisce mai. Una connessione esterna a tunnel completo possiede la rotta predefinita, quindi il tentativo del client interno di raggiungere la propria estremità viene inghiottito dal tunnel esterno e scartato o messo in loop. L'estremità interna ha bisogno di una rotta esplicita attraverso l'interfaccia esterna, installata prima che il client interno parta. Altrimenti l'handshake fa la corsa con la rotta e perde.

WireGuard mostra lo stesso conflitto dal lato opposto. Le AllowedIPs di ogni peer decidono quali destinazioni entrano in quel tunnel, quindi un'interfaccia interna che rivendica ogni indirizzo rivendica anche l'estremità esterna, a meno che non vinca una rotta più specifica. La sovrapposizione di AllowedIPs su due interfacce è una configurazione in cui un lato perde in silenzio.

Il concatenamento dei container rende esplicita la separazione e ovvia la trappola. Un container con il proprio namespace, la propria rotta predefinita e un client al suo interno inoltra ciò che l'host gli invia; l'host non inizia da solo a usare quel percorso. Attiva l'inoltro, aggiungi una rotta per il tunnel del container e punta il servizio all'indirizzo del container.

3. Tieni il DNS sullo stesso percorso

Il DNS deve viaggiare dove viaggia il traffico. Se il fornitore interno spinge i resolver e l'host interroga ancora quelli locali, quelle risoluzioni rivelano esattamente i siti che il tunnel doveva nascondere. Verifica con una cattura su ogni interfaccia del tunnel invece di fidarti del pannello di stato del client. Una fuga qui è invisibile durante la normale navigazione e ovvia in una cattura.

Le configurazioni DNS divise rendono tutto più difficile, perché una query per un nome locale può legittimamente appartenere fuori dal tunnel. Scrivi la lista delle eccezioni di proposito invece di scoprirla in base a quale resolver ha risposto.

4. Imposta l'MTU prima che gli utenti lo scoprano per te

L'MTU è l'altra vittima prevedibile. Due incapsulamenti tolgono due intestazioni, e un tunnel esterno che ha già abbassato l'MTU del percorso lascia meno spazio all'interno. I sintomi sono noti: le richieste piccole passano, i trasferimenti grandi e gli handshake TLS si bloccano.

ip link set dev wg1 mtu 1280 è la correzione brutale, e limitare l'MSS sull'inoltro è quella più pulita. Riprovare la connessione non è affatto una correzione.

5. Prova il guasto che avrai davvero

Interrompi il tunnel esterno di proposito e guarda cosa succede. Una catena che ricade in silenzio su un percorso diretto quando muore il salto esterno è peggiore di nessuna catena, perché perde proprio nel momento in cui credevi di essere coperto. Il comportamento da cercare è un kill switch che ferma tutto il traffico. Annota il risultato, perché non vorrai riscoprirlo nel mezzo di un incidente.

La latenza e un secondo punto di guasto sono il costo permanente. Due salti significano anche due code di assistenza quando qualcosa si rompe a un'ora scomoda.