Configurare Ubuntu, Debian e CentOS come gateway VPC

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Decidere il ruolo del gateway prima di toccare il routing

Un gateway VPC non è solo una macchina con due interfacce: è il punto in cui il traffico cambia dominio di routing, spesso tra subnet private e rete esterna, oppure tra più segmenti interni. Se il nodo deve fare da gateway per altri host, la prima scelta non è la distro ma il comportamento atteso: inoltro puro, NAT, firewall stateful, oppure combinazione dei tre. Su Ubuntu, Debian e CentOS la base è la stessa, ma cambiano i file di persistenza e i nomi dei servizi da riavviare.Per evitare errori operativi, conviene partire da tre domande: quali reti devono passare dal gateway, se il traffico deve uscire con l’IP del gateway o con indirizzi originali, e se il gateway deve anche rispondere lui stesso ai client. Se questa distinzione non è chiara, si finisce spesso con un host che inoltra pacchetti ma non li rende raggiungibili oppure, peggio, con una macchina esposta in modo inutile.Assunzione di base: una NIC verso la rete privata, una verso la rete upstream o Internet, e un kernel Linux recente con systemd. Se il nodo sta in cloud o in una VPC gestita, verifica prima che il provider non imponga regole anti-spoofing o source/destination check, perché in quel caso il forwarding locale non basta.

Abilitare il forwarding IPv4 e, se serve, IPv6

Il requisito minimo per un gateway è l’inoltro IP attivo. Senza questo, il kernel tratta la macchina come host finale e scarta i pacchetti destinati a reti diverse. La verifica va fatta subito, prima di configurare NAT o regole firewall, perché altrimenti si inseguono sintomi falsi.Controllo rapido:

sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

Il valore atteso per IPv4 è 1. Per IPv6, abilita il forwarding solo se la tua architettura lo richiede davvero; in molte installazioni il traffico IPv6 viene lasciato terminare localmente oppure filtrato in modo separato.Per una modifica persistente, usa un file dedicato invece di sporcare /etc/sysctl.conf. Sulle tre famiglie di distro il metodo è identico come logica, cambia solo l’eventuale gestione centralizzata del profilo.

sudo tee /etc/sysctl.d/99-vpc-gateway.conf >/dev/null <<'EOF'
net.ipv4.ip_forward = 1
# Abilita solo se il gateway deve inoltrare IPv6
# net.ipv6.conf.all.forwarding = 1
EOF
sudo sysctl --system

Dopo il reload, ricontrolla il valore e verifica che non ci siano policy di sicurezza che lo sovrascrivano in boot. Se usi immagini cloud preconfigurate, a volte un tool di hardening riscrive i parametri al riavvio.

NAT, routing puro o entrambi: scegliere la topologia giusta

Se gli host dietro il gateway devono uscire su Internet senza ricevere IP pubblici, la soluzione classica è il NAT masquerade. Se invece stai collegando due reti con routing reciproco e controlli entrambi i lati, è spesso meglio evitare il NAT e propagare rotte corrette: meno complessità, meno sorprese nei log e meno problemi con applicazioni che dipendono dall’IP sorgente.Per un gateway VPC tipico, il caso più frequente è: subnet privata che esce verso Internet o verso servizi esterni passando da un IP pubblico sul gateway. In questo scenario, il NAT è normale. Se però il gateway deve anche essere raggiungibile da altre subnet o da un VPN concentrator, il routing statico va curato con attenzione, perché il return path deve tornare dalla stessa strada.Un errore comune è configurare il forward solo in uscita e dimenticare la rotta di ritorno sul lato upstream. Il risultato è un SYN che esce correttamente ma non riceve risposta, con timeout che sembrano problemi applicativi. La falsificazione più rapida è un tcpdump sulle due interfacce.

sudo tcpdump -ni eth0 host 10.10.0.20
sudo tcpdump -ni eth1 host 10.10.0.20

Se vedi il pacchetto su una sola interfaccia, il problema è di routing o di policy. Se lo vedi su entrambe ma la sessione non si chiude, spesso c’è un firewall intermedio o manca il NAT di ritorno.

Configurare il firewall con regole minime e stateful

Il gateway deve filtrare, non solo inoltrare. La regola pratica è semplice: consenti l’established/related, poi autorizza il forwarding dai segmenti interni verso l’esterno, e chiudi tutto il resto salvo eccezioni motivate. Questo riduce la superficie d’attacco e rende i log leggibili.Su Ubuntu e Debian, se usi iptables o il backend nft compatibile, puoi mantenere una configurazione semplice e persistente; su CentOS moderno spesso conviene ragionare in termini di firewalld o nftables. L’importante è non mescolare strumenti che si sovrascrivono a vicenda senza aver chiarito il backend effettivo.Esempio minimale con iptables, utile quando vuoi capire il comportamento prima di migrare a una gestione più astratta:

sudo iptables -P FORWARD DROP
sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A FORWARD -i eth1 -o eth0 -s 10.10.0.0/24 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o eth0 -j MASQUERADE

Qui eth1 è la rete interna e eth0 l’upstream. Cambia i nomi in base al tuo host, magari verificandoli con ip -br link. La parte più importante è la policy di default su FORWARD: se la lasci permissiva, il gateway diventa un router aperto.Su sistemi con firewalld, il concetto è lo stesso ma la persistenza passa da zone e masquerade. In un ambiente CentOS/RHEL-like, una configurazione tipica è assegnare l’interfaccia interna a una zona trusted o internal e abilitare il masquerade sulla zona esterna.

sudo firewall-cmd --permanent --zone=internal --add-interface=eth1
sudo firewall-cmd --permanent --zone=public --add-interface=eth0
sudo firewall-cmd --permanent --zone=public --add-masquerade
sudo firewall-cmd --reload

Se usi nftables direttamente, la logica resta identica: table nat, chain postrouting, regola masquerade. La differenza è solo sintattica, non concettuale.

Persistenza su Ubuntu, Debian e CentOS senza sorprese al reboot

La parte che si rompe più spesso non è il traffico immediato, ma la persistenza. Dopo un riavvio, il forwarding torna off, il firewall cambia backend, oppure la NAT sparisce. Qui conviene separare i tre livelli: sysctl, firewall e configurazione di rete.Su Ubuntu e Debian, se la rete è gestita da netplan, le interfacce e gli indirizzi vanno definiti lì; il forwarding invece rimane in sysctl. Se usi ifupdown, puoi agganciare script post-up o file in /etc/network/interfaces, ma oggi è più pulito tenere le responsabilità distinte.Esempio di controllo delle interfacce:

ip -br addr
ip route
networkctl status 2>/dev/null || true

Su CentOS, soprattutto in installazioni recenti, NetworkManager può riscrivere alcune impostazioni di rete. Se configuri rotte statiche, verifica che siano definite nel profilo corretto e non solo in un file temporaneo. Il comando utile è:

nmcli connection show
nmcli connection show "nome-connessione"

Se devi aggiungere una rotta persistente verso una subnet interna, fallo nel gestore di rete, non con ip route add e basta. Quest’ultimo serve per testare, non per garantire continuità.

Verificare il percorso dei pacchetti con test semplici e ripetibili

Un gateway si valida con tre prove: l’host interno raggiunge il gateway, il gateway raggiunge l’upstream, e il traffico attraversa davvero il nodo. Se ti fermi alla prima, rischi di confondere connettività locale e forwarding reale.Test consigliato dal lato client interno:

ping -c 3 10.10.0.1
curl -4I https://example.com
traceroute -n 1.1.1.1

Il primo verifica la porta di ingresso del gateway, il secondo mostra se l’uscita funziona, il terzo aiuta a capire se il salto intermedio è quello atteso. Se il traceroute si ferma al gateway ma non esce, il problema è quasi sempre su NAT, policy di forwarding o rotta di ritorno.Dal lato gateway, osserva il traffico in tempo reale:

sudo tcpdump -ni eth1 icmp or tcp port 443
sudo tcpdump -ni eth0 icmp or tcp port 443

Se il pacchetto entra su eth1 ma non esce da eth0, il blocco è locale. Se esce da entrambe le interfacce ma la risposta non rientra, cerca firewall upstream, ACL di VPC o assenza di route di ritorno.

Integrazione con VPC: rotte statiche, anti-spoofing e source/destination check

In cloud, il gateway non vive da solo. Molti provider impongono controlli che impediscono a una VM di inoltrare traffico per altri host se non disabiliti una funzione specifica sul NIC virtuale o se non registri la macchina come router. In AWS, ad esempio, il source/destination check va disattivato sul nodo che fa da router; in ambienti simili esiste un equivalente concettuale.Se la VPC usa rotte statiche, il route table deve puntare la subnet privata verso l’ENI o l’istanza gateway. Il nodo locale può essere perfetto, ma se la tabella di routing della VPC non lo indica come next hop, nessun pacchetto prenderà quella strada. Questo è uno dei casi in cui il layer cloud vince sul layer Linux.Un controllo utile è confrontare il route table del provider con la route table locale:

ip route show
ip rule show

Se il provider usa più route table o policy routing, il gateway Linux deve essere coerente con quelle decisioni. A volte serve anche un ip rule dedicato per separare traffico management e traffico transit, soprattutto quando il nodo ha più di due interfacce.

IPv6: quando abilitarlo e quando lasciarlo fuori

Molti gateway vengono configurati bene in IPv4 e lasciati incompleti in IPv6. Il problema non è teorico: se il sistema ottiene prefissi IPv6 ma non inoltra correttamente, alcuni client proveranno prima il canale v6 e sembreranno lenti o intermittenti.Se vuoi supportare IPv6 transit, abilita forwarding, definisci le rotte e verifica il firewall in parallelo. Se non vuoi supportarlo, disabilita in modo coerente la pubblicazione di prefissi e limita l’accesso in ingresso per evitare comportamenti ambigui. La regola è la stessa del resto della rete: meglio un no esplicito che un mezzo sì difficile da diagnosticare.Verifica minima:

sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 2606:4700:4700::1111

Se il ping IPv6 fallisce ma il routing IPv4 funziona, non assumere subito un guasto generico: spesso manca solo una regola firewall v6 o una route specifica per il prefisso assegnato.

Hardening minimo di un gateway che sta in produzione

Un gateway non dovrebbe esporre più servizi del necessario. Ogni demone in ascolto aggiunge superficie d’attacco e rende più difficile distinguere un problema di routing da uno di applicazione. L’obiettivo è ridurre il nodo a poche funzioni: inoltro, filtraggio, logging essenziale e amministrazione remota strettamente controllata.Controlli utili:

ss -tulpn
sudo journalctl -p warning -b
sudo nft list ruleset 2>/dev/null || sudo iptables -S

Se trovi servizi non necessari, disabilitali con criterio e verifica l’impatto prima di procedere. Mantieni accesso SSH solo da rete amministrativa o tramite bastion, usa chiavi e non password, e registra le eccezioni al firewall in modo esplicito.Per i log, è utile tenere sia quelli del firewall sia quelli del kernel, perché drop e errori di forwarding spesso finiscono lì, non nell’applicazione. Su sistemi systemd, journalctl -k e i log del firewall sono il primo posto da guardare.

Procedura pratica riassunta per Ubuntu, Debian e CentOS

Se devi mettere in piedi un gateway VPC da zero, la sequenza operativa più sicura è questa: prima identifichi interfacce e rotte, poi abiliti il forwarding, poi applichi il firewall stateful, infine testi il percorso dei pacchetti e rendi persistente la configurazione. Saltare l’ordine aumenta il rischio di perdere accesso alla macchina o di creare un router aperto.

1. Rileva le interfacce: ip -br addr e ip route.
2. Abilita net.ipv4.ip_forward=1 con /etc/sysctl.d/ e ricarica con sysctl --system.
3. Definisci policy firewall stateful e, se serve, NAT masquerade sulla interfaccia esterna.
4. Su CentOS usa firewalld o nftables; su Ubuntu e Debian puoi usare nftables, iptables o il backend del firewall scelto, ma non mescolare tool senza sapere chi comanda.
5. Verifica con tcpdump, curl, ping e un test da host interno.
6. Rendi persistenti route e policy nel gestore di rete corretto, non solo in shell temporanea.

Questa sequenza funziona perché separa i problemi di base: prima il kernel deve inoltrare, poi il firewall deve consentire, infine il provider o la rete esterna devono riconoscere il nodo come next hop valido. Se una delle tre condizioni manca, il gateway non è un gateway ma solo una VM con due cavi logici.Quando il risultato atteso è traffico stabile tra subnet o verso Internet, la metrica da osservare non è solo il ping ma anche la percentuale di sessioni riuscite, i timeout e la latenza p95 prima e dopo la modifica. Se la latenza cresce, il problema può essere nel firewall stateful, in una route non ottimale o in una saturazione della NIC.In pratica: su Ubuntu e Debian la differenza principale sta nel modo in cui persisti rete e firewall; su CentOS il punto di attenzione è spesso firewalld e la sua integrazione con NetworkManager. Il resto è Linux standard: forwarding, route, NAT, controllo del percorso e disciplina nel non aggiungere complessità dove basta una regola chiara.