Dopo un cambio di IP del server, la regola SNAT nomina ancora quella vecchia

Il server si è spostato su un nuovo indirizzo, i client si connettono ancora e nulla di ciò che inviano raggiunge internet. Questa separazione è l'indizio: il socket in ascolto e il port forwarding sono sopravvissuti allo spostamento, quindi il tunnel sale, mentre la traduzione di origine applicata ai pacchetti inoltrati nomina ancora un indirizzo che l'host non possiede più. Le risposte a quei pacchetti riscritti vanno a una macchina che non c'è più.

Connessione e inoltro falliscono in punti diversi

La creazione dipende dall'endpoint che i client conoscono già: l'indirizzo pubblico, il port forwarding davanti e l'ascoltatore all'interno. Il traffico inoltrato dipende da una seconda decisione presa dopo che il pacchetto entra nel tunnel, quando l'host riscrive la propria origine perché le risposte trovino la via del ritorno.

Un cambio di indirizzo rompe solo la seconda decisione, ed è per questo che il sintomo si legge come "connesso ma senza internet". Spiega anche perché i soliti controlli lato client sembrano sani: l'handshake si completa, il client riceve un indirizzo e persino un ping all'indirizzo del tunnel del server può rispondere. Si perdono ore sul client per un guasto che vive dall'altra parte, perciò la tabella delle regole è il primo posto da guardare.

Leggi la regola e i suoi contatori prima di modificare

Elenca le regole di traduzione con i contatori e confronta l'origine configurata con gli indirizzi che l'host possiede davvero. Una regola riscritta verso un indirizzo morto di solito mostra traffico in ingresso, perché i pacchetti la raggiungono e vengono tradotti, e nulla al ritorno.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Controlla tre campi mentre sei lì: il pool nella corrispondenza di origine, l'interfaccia di uscita se la regola ne nomina una, e l'esclusione che impedisce al traffico tra tunnel di essere riscritto. Quell'esclusione si perde facilmente durante una modifica, e perderla fa sembrare che il traffico tra pari funzioni mentre le sue risposte prendono un percorso strano.

Se i contatori restano a zero, i pacchetti non raggiungono mai questa regola e l'indirizzo non è il problema attuale. Cerca una regola concorrente più in alto nella catena, cosa che accade quando qualcuno aggiunge una sostituzione invece di modificare l'originale. Confronta i numeri di regola con l'output che hai annotato un minuto fa. L'ordine fa parte della configurazione, non è un dettaglio estetico.

Sostituisci l'origine, o smetti di nominarne una

Quando l'host ha un indirizzo stabile, sostituisci la regola sul posto invece di aggiungerne un'altra. La sostituzione per numero di regola conserva l'ordine da cui dipende il resto della catena.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Quando l'indirizzo viene assegnato dinamicamente, non nominare alcuna origine e lascia che il kernel scelga quella corrente dall'interfaccia di uscita. Questa variante sopravvive allo spostamento successivo senza modifiche, al prezzo di nascondere quale indirizzo è stato usato.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Conferma che l'inoltro IPv4 è ancora abilitato tramite configurazione gestita, poi rendi la regola persistente con il meccanismo proprio della distribuzione. Una modifica fatta solo nel kernel in esecuzione torna al prossimo riavvio, di solito durante una finestra di manutenzione che nessuno collega al cambiamento.

Due modi per sbagliare la sostituzione

Tradurre il pool verso l'indirizzo del tunnel del server invece che verso il suo indirizzo LAN manda le risposte direttamente nel tunnel, dove vengono instradate verso un client che non le ha mai chieste. La connessione si blocca in un modo che sembra un loop di routing, perché lo è.

Impilare una seconda traduzione sopra quella vecchia è l'altro errore. Vince la prima regola corrispondente, quindi la voce obsoleta continua a gestire i pacchetti finché non viene eliminata, e i contatori della nuova regola restano a zero mentre tutti incolpano la sostituzione. Elimina il duplicato prima di aggiungere qualcosa di nuovo. Poi rileggi l'elenco e conferma che esattamente una traduzione corrisponde al pool.

Se il tunnel trasporta anche IPv6, ripeti tutta la revisione sull'altro stack. Una rotta predefinita IPv6 senza traduzione e senza prefisso instradato fallisce altrettanto silenziosamente, ed è facile dimenticarlo perché tutto ciò che sta sopra sembra identico.

I servizi in ingresso hanno bisogno della traduzione opposta

Un servizio su un client VPN che deve essere raggiungibile dall'esterno ha bisogno della traduzione di destinazione, non di origine: la porta pubblica viene riscritta verso l'indirizzo del tunnel del client prima di entrare. Il percorso di inoltro ha poi bisogno di una regola esplicita che consenta quel traffico.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Non tradurre mai la porta che trasporta il tunnel stesso, perché quella riscrittura interrompe la connessione che mantiene raggiungibile il servizio. Tieni la porta del tunnel completamente fuori dalle regole di destinazione. Verifica poi da entrambe le estremità: contatori sulla nuova regola, una breve cattura sul dispositivo del tunnel e una richiesta a un indirizzo dentro il tunnel prima di provare quella pubblica.