Limitate la regola SNAT di OpenVPN prima che rompa nginx

Due guasti arrivano sempre dallo stesso tipo di host. Nel primo i client si autenticano e poi non raggiungono nulla oltre il tunnel. Nel secondo la VPN sale e il sito web del server stesso smette di rispondere, che è il più allarmante perché sembra un danno collaterale. Su un VPS basato su container entrambi risalgono di solito alla stessa breve lista di controlli, e l’ordine conta: prima il dispositivo, poi la traduzione, infine l’ambito.

Confermate che il container possa creare un dispositivo tun

Nient’altro conta se l’interfaccia del tunnel non può esistere. Verificate che /dev/net/tun sia presente e che la creazione di un dispositivo di prova riesca, perché molti fornitori disattivano tun nei container per impostazione predefinita. Nessun lavoro sul firewall compensa un dispositivo che non è mai stato creato.

Se il dispositivo manca, solo l’host o il fornitore possono abilitarlo. Spesso un altro piano è più economico di un thread di supporto aperto che dura una settimana. Confermatelo prima di leggere una sola riga del log di OpenVPN. Altrimenti passate la serata a ritoccare regole che non vedranno mai un pacchetto.

Decidete cosa fa MASQUERADE su questa interfaccia

Su una macchina virtuale ordinaria la consueta regola di uscita è POSTROUTING MASQUERADE dall’interfaccia principale. In un container OpenVZ il dispositivo visibile è spesso venet0, un’interfaccia virtuale gestita dall’host e non una NIC instradata, e MASQUERADE non si comporta sempre lì come presuppongono i tutorial.

La forma praticabile è una traduzione esplicita verso l’indirizzo che i client raggiungono già, con l’inoltro consentito in entrambe le direzioni. Sostituire il pool dalla configurazione del server conta quanto sostituire l’indirizzo. Leggete ogni riga prima di incollarla.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Senza le regole di inoltro la traduzione avviene comunque e il kernel continua a rifiutarsi di inoltrare. Questa combinazione produce lo stato confuso in cui i contatori della regola NAT salgono mentre il client non riceve nulla. Anche le due righe FORWARD devono stare prima di qualsiasi regola drop ampia nella stessa catena. L’ordine è parte della configurazione, non un dettaglio implementativo.

Limitate la regola a un pool e a una sola interfaccia

Il secondo sintomo ha un’altra causa: una regola POSTROUTING senza restrizione di origine né di uscita. Una regola così riscrive ogni pacchetto che lascia l’host.

I servizi che dipendono dall’origine originale si comportano male. Un server web dietro un proxy locale può smettere di rispondere, e riavviarlo non cambia nulla perché la regola è ancora nel percorso. Anche il traffico che l’host invia al proprio indirizzo pubblico è coinvolto, per questo il guasto può sembrare un problema di DNS o di certificato invece che di firewall. La regola è quasi certamente stata aggiunta per correggere il primo sintomo.

La soluzione è restringere la corrispondenza al pool del tunnel e all’interfaccia di uscita, poi aggiungere una regola per pool invece di allargare una singola regola per coprirne diverse.

Rendete persistenti le regole e scoprite chi altro le possiede

Le regole aggiunte a mano spariscono al riavvio, quindi salvatelle con iptables-save o gestitele tramite netfilter-persistent dove è installato. Confermate che il ripristino venga eseguito prima che OpenVPN parta. Poi riavviate una volta di proposito invece di scoprire la lacuna durante un incidente.

Su un host con container, confermate anche che il file di persistenza si trovi in uno storage del container scrivibile e che il fornitore non sostituisca il filtraggio all’avvio. Alcune piattaforme gestiscono la policy fuori dal container, dove le regole locali vengono ignorate o si scontrano con quelle dell’host stesso.

Verificate con contatori e un flusso catturato

Da un client connesso, controllate l’indirizzo pubblico che un servizio esterno riporta. Se coincide con l’indirizzo del server, la traduzione funziona; se no, il pacchetto esce da un’altra via o non esce affatto. Poi provate sia un servizio ospitato sul server sia uno su internet pubblico, perché seguono percorsi diversi attraverso lo stesso insieme di regole.

Sul server, leggete i contatori di pacchetti delle regole NAT e FORWARD con iptables -t nat -L -v -n e osservate un flusso in una cattura. Se l’indirizzo del client compare nella cattura e non segue alcuna risposta, la lacuna è sul percorso di ritorno o nel filtraggio del fornitore, non nel profilo del client. Confrontate l’origine catturata con l’indirizzo verso cui traduce la regola, perché una discrepanza significa che un’altra regola ha corrisposto prima. Un solo flusso osservato risolve più di una pagina di lettura della configurazione.

Tenete insieme pool, indirizzo tradotto e nome dell’interfaccia nel registro delle modifiche. Una regola corretta per un pool traduce male la successiva.