Dove va il NAT del VPN in before.rules di UFW e come testarlo

Una regola NAT che funziona quando viene digitata in una shell fallisce quando viene incollata in before.rules, perché quel file non è uno script. È un documento in formato di ripristino con sezioni di tabella, dichiarazioni di catena e un marcatore COMMIT per ogni tabella. Una riga nel posto sbagliato o interrompe l’intero ripristino o scarta silenziosamente regole che credevate presenti. La procedura seguente colloca il frammento dove il framework lo aspetta e dimostra il risultato prima del ricaricamento successivo.

Un comando shell non è un file di ripristino

Una riga che inizia con iptables -t nat è un’istruzione per il binario iptables, mentre il file che UFW legge è la descrizione di un set di regole completo. La differenza non è cosmetica: il formato di ripristino deve sapere in quale tabella si trova, quali catene esistono e dove finisce la tabella. Un comando incollato in quel documento è o un errore di sintassi o, peggio, una regola agganciata alla tabella sbagliata. Il framework carica quei file tramite strumenti di ripristino proprio perché sono dichiarativi e non sequenziali.

Il documento viene caricato anche nel suo insieme, quindi una sezione malformata può impedire l’applicazione del resto del file. Perciò un piccolo errore in un frammento NAT trascina con sé anche le regole di filtraggio, ed è così che una modifica al firewall diventa un’interruzione.

Mettete il frammento nella sezione di tabella esistente

Un frammento NAT ha una forma, e la forma conta più del testo della regola al suo interno. L’intestazione della tabella apre la sezione, le dichiarazioni di catena impostano i contatori, seguono le regole e un COMMIT chiude la sezione.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Il pool e l’interfaccia qui sopra sono segnaposto per i vostri; la struttura è la parte che vale la pena copiare. Se il file contiene già una sezione *nat, aggiungete la regola all’interno di quella sezione invece di aprirne una seconda, perché il formato prevede un COMMIT per tabella e due sezioni per la stessa tabella sono una riparazione in attesa. Mantenete intatte le definizioni di catena della distribuzione, comprese quelle aggiunte dal fornitore per la propria integrazione. Il manuale del framework UFW documenta i file before, user e after insieme al requisito di un COMMIT corrispondente.

Se il file risulta vuoto, non riempitelo da un tutorial. Confermate quale pacchetto lo possiede e qual è davvero la politica attiva, perché un file persistente vuoto non dimostra che il kernel non contenga regole, e un set di regole caricato non dimostra che il prossimo ricaricamento avrà un file completo da leggere. Ripristinate prima la linea di base supportata, poi riapplicate sopra le modifiche del sito.

Testate il candidato senza applicarlo

Lo strumento di ripristino può analizzare e costruire un set di regole senza applicarlo, ed è il test più economico disponibile. Eseguitelo su una copia protetta invece che sul file attivo, e leggete il testo dell’errore invece del solo stato di uscita. Un errore di analisi nomina una riga e di solito una tabella, che è più di quanto vi dirà un ricaricamento fallito.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Superare quel controllo dimostra che il documento viene analizzato e nulla più. Non dimostra che il candidato contenga ancora ogni catena da cui dipende UFW, che permetta solo le sorgenti previste o che l’amministrazione remota resti raggiungibile. Sono revisioni separate, e l’ultima merita una seconda sessione aperta prima di iniziare.

Scegliete lo strumento adatto al backend installato e alla famiglia di indirizzi. Un host che esegue il backend nft tramite il livello di compatibilità ha bisogno del comando corrispondente, e le regole IPv6 vivono in un file del tutto diverso.

Tenete separati inoltro, NAT e politica di accesso

La traduzione della sorgente risolve un problema di indirizzamento e non concede nulla. L’inoltro è un’autorizzazione separata controllata da un sysctl e dalla tabella di filtraggio, ed è quella che la gente dimentica quando un tunnel instrada ma non fa passare traffico. La politica di accesso è una terza decisione su quali sorgenti possono raggiungere quali servizi, e nessuna regola NAT la esprime. Tenere separati i tre è ciò che rende un guasto diagnosticabile invece di un unico sintomo vago.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Leggete questi tre output insieme, non uno alla volta. Una regola masquerade con l’inoltro disattivato produce un client che si connette e non raggiunge nulla, il che dal lato del client sembra esattamente un guasto di instradamento e manda le persone al file sbagliato. La tabella di filtraggio è anche il luogo dove si nasconde un accept troppo ampio, quindi controllate la sua politica predefinita mentre siete lì.

Verificate un ricaricamento, un rifiuto e una perdita di VPN

Tre osservazioni compongono un test di accettazione completo: il ricaricamento riesce, un’operazione client consentita funziona e una richiesta che dovrebbe essere rifiutata viene effettivamente rifiutata. La terza è quella che si salta, ed è l’unica prova che la politica stia facendo qualcosa.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Poi provate il guasto per cui avete progettato. Fate cadere il tunnel e osservate cosa fa l’host, perché una politica che funziona solo finché la VPN è attiva è una politica con una dipendenza non dichiarata. Ricaricate ancora una volta dopo, per dimostrare che è il file, e non uno stato di esecuzione residuo, a produrre il risultato funzionante.

Il NAT IPv4 non dice nulla su IPv6, quindi indicate la copertura prevista per entrambe le famiglie nella stessa nota della regola. L’obiettivo è una politica gestita coerente, e un frammento che si è trovato analizzabile non ne è la prova.