iptables: far raggiungere ai client VPN un solo host

Due ticket di assistenza che sembrano scollegati finiscono per condividere una sola causa. Nel primo, un amministratore vuole che il server accetti connessioni solo dal tunnel; nel secondo, gli utenti VPN dovrebbero raggiungere un unico host interno e nulla di più. Entrambe le politiche appartengono a FORWARD, ed entrambe vengono di solito tentate in INPUT. Il risultato sembra un firewall e si comporta come un segnaposto.

Quale catena risponde alla tua domanda

I pacchetti che un client VPN invia a un host della LAN, o più avanti verso internet, vengono inoltrati dal kernel e valutati in FORWARD. INPUT e OUTPUT vedono solo il traffico che termina sul server stesso o che ne ha origine. Un rifiuto per tutto ciò che non arriva su tun0 protegge quindi i listener del server, e porrà fine anche alla tua sessione SSH se i flussi stabiliti non vengono ammessi prima. Non cambia nulla su dove i client possono andare.

Dai un nome alla domanda: chi può raggiungere il server, o dove possono andare i client. La maggior parte delle reti ha bisogno di entrambe le risposte, in catene diverse.

Prima lo stato, poi il permesso, poi il rifiuto

Una lista di autorizzati funziona solo se il permesso specifico sta sopra il rifiuto generale e se il traffico di ritorno è ammesso sopra entrambi. Inserisci le regole in posizioni esplicite, poi stampa la catena con iptables -S FORWARD così che l’ordine sia visibile e non dato per scontato.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Due dettagli decidono se questo sopravvive al contatto con il traffico reale. Senza la regola di stato, le risposte alle connessioni appena consentite vengono esse stesse valutate contro il rifiuto e scartate. Una regola LOG senza limite può esaurire una partizione piccola la prima volta che una scansione la colpisce, quindi aggiungi -m limit --limit 10/min prima di continuare a registrare. REJECT restituisce subito un errore, il che è più gentile mentre si mette a punto la lista; DROP scarta in silenzio, perciò ogni errore si presenta come un timeout. Scegline uno di proposito e scrivi la scelta nel registro delle modifiche.

L’inoltro e il NAT devono già funzionare

Il filtraggio non può dimostrare che un percorso esista. Conferma prima che il kernel inoltri del tutto, e rendi persistente questa impostazione invece di un comando una tantum nella shell. Il filtro è l’ultimo strato, non il primo.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Dove va il masquerading dipende da dove escono i client. Se escono verso una rete remota attraverso il tunnel, la regola NAT va su quell’interfaccia e non sull’interfaccia WAN. Poi guarda i contatori: se il contatore POSTROUTING non si muove mai mentre il numero di accettazioni in FORWARD sale, il percorso di ritorno è rotto e il filtro è a posto. Quella lettura risparmia un pomeriggio passato a riscrivere regole che non erano mai il problema.

Il blocco della posta sta una catena più in là

Bloccare la porta 25 in INPUT ferma solo la posta indirizzata al server VPN. Un client compromesso che invia posta attraverso il tunnel viene inoltrato, quindi il blocco deve stare in FORWARD accanto a 465 e 587. Se un’applicazione inoltra legittimamente la posta, metti la sua destinazione e la sua porta sopra quella regola.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Lascia girare il contatore dei rifiuti per una settimana prima di stringere qualsiasi altra cosa. Il numero che smette di salire è il flusso legittimo che hai appena rotto.

Rileggilo, poi dimostralo da un client

Leggi il set di regole come lo riporta il kernel, non come l’ha scritto il tuo script. Inizia con iptables -S FORWARD, poi la tabella NAT con iptables -t nat -L POSTROUTING -n -v, poi la voce conntrack del flusso che stai verificando. Tieni a portata di mano un comando di rollback o uno svuotamento pianificato finché il lavoro dura. Ogni chiamata ha bisogno di -w, altrimenti due amministratori si scontreranno sul lock di xtables. Niente di tutto ciò è facoltativo durante una finestra di modifica.

Chiudi provando da un client dentro il pool e da uno fuori. Una regola che funziona solo dalla macchina su cui l’hai digitata non è una politica.