Doppio NAT e la tua VPN: il client funziona, il server no

Il tuo router sta dietro un altro router, l'indirizzo WAN è privato e il client VPN si connette comunque. Questa combinazione sorprende chi si aspetta che il doppio NAT rompa i tunnel, ma sono proprio le connessioni in uscita che la traduzione gestisce meglio. Ospitare un server VPN dietro gli stessi due strati è il caso che di solito fallisce. Disegna la direzione della connessione prima di cambiare qualcosa.

Disegna prima la direzione della connessione

Apri la pagina di stato del router interno e annota il suo indirizzo WAN, poi confrontalo con l'indirizzo che un servizio pubblico ti riporta. Se i due differiscono, almeno un traduttore si trova tra il tuo router e internet. Se l'indirizzo WAN cade dentro 100.64.0.0/10, il traduttore esterno appartiene probabilmente al tuo provider e tu non lo controlli. Questi due fatti decidono quale dei passaggi successivi può funzionare.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

Il doppio NAT non è un doppio VPN. La traduzione riscrive indirizzi e porte; non aggiunge un secondo tunnel cifrato e non cifra nulla. Tenere separate le due idee conta perché le soluzioni sono completamente diverse, e una di esse richiede una conversazione con il provider invece di una pagina di impostazioni.

In uscita: il client chiede, i traduttori mappano

Un tunnel in uscita inizia con un pacchetto dalla tua macchina, quindi ogni traduttore può creare una mappatura e lasciar rientrare la risposta. Il protocollo, la porta e i timer di inattività decidono se quella mappatura sopravvive abbastanza a lungo da essere utile. La maggior parte dei router domestici se la cava senza alcuna configurazione.

I guasti che compaiono davvero riguardano di solito timeout e supporto dei protocolli, non il numero di router. Un tunnel che cade dopo qualche minuto di silenzio è una mappatura che scade, e un keepalive è la risposta standard. IPsec dispone di estensioni NAT-traversal standard, quindi affermare che non può attraversare la traduzione è semplicemente sbagliato. Se il tunnel non si stabilisce affatto, guarda l'endpoint e le credenziali prima di dare la colpa alla topologia.

wg show
ping -c3 10.8.0.1

Fermati se il tunnel in uscita funziona da una rete e non da un'altra. Quel confronto riguarda le reti, non il numero di router.

In entrata: l'inoltro copre solo l'apparecchiatura che possiedi

Ospitare un server è la direzione opposta: una nuova connessione arriva da internet e deve raggiungere la tua macchina attraversando ogni strato. Una regola di inoltro porta sul router interno aiuta solo se il traduttore esterno consegna quel traffico anche a te. Ripetere la regola locale non dà il controllo sull'apparecchiatura del provider.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Confronta l'indirizzo WAN del router interno con l'indirizzo pubblico che hai osservato e annota da dove viene ogni valore. Se l'indirizzo WAN è privato o nell'intervallo condiviso, lo strato esterno compie una traduzione che non puoi configurare. Chiedi al provider quale raggiungibilità in entrata supporta prima di passare una serata su regole che non possono avere effetto. Rimuovere un router o disattivare ampiamente un firewall non è una diagnosi, ed è un cattivo scambio per una sola porta aperta.

Fermati se lo strato esterno è del provider e non inoltra. Allora le risposte supportate sono un altro metodo di accesso o un relay, non un'altra regola dalla tua parte.

Prova una variabile alla volta

Cambia una cosa per prova e annota il risultato, perché un percorso in doppio NAT ha più variabili di uno con un solo router. Tieni fissi profilo e dispositivo, poi confronta un'altra rete di accesso. Nota se la negoziazione fallisce, se la sessione cade dopo inattività o se falliscono solo le destinazioni private. Queste tre osservazioni indicano tre strati diversi.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Le sottoreti private sovrapposte sono una trappola a parte che nessuna quantità di traduzione sistema. Se la tua rete domestica e la rete remota usano lo stesso intervallo, compare un conflitto di rotte indipendentemente da quanti traduttori ci siano in mezzo. Rinumerare un lato è l'unica risposta duratura.

Il gateway remoto merita la stessa attenzione, perché le sue regole di inoltro e le rotte di ritorno possono essere il pezzo mancante. Un tunnel che si autentica può comunque non avere alcun percorso applicativo utilizzabile, e quel guasto appare identico dal lato client. Il percorso termina quando sai dire quale direzione fallisce e quale strato ne è responsabile.