eth0:0 è un’etichetta, non un dispositivo: correggi la corrispondenza SNAT

Un contatore a zero significa che la regola nomina un’interfaccia che non può esistere. Leggi il dispositivo reale, correggi la corrispondenza -o e poi scegli deliberatamente l’indirizzo tradotto.

Una regola NAT che doveva dare a un pool di client VPN il proprio indirizzo pubblico resta a zero pacchetti, mentre lo stesso pool continua a uscire con l’origine sbagliata. Di solito la regola non sbaglia l’indirizzo; sbaglia l’interfaccia. -o eth0:0 fa riferimento a un dispositivo che non esiste, perché eth0:0 è un’etichetta associata a un indirizzo su eth0. Guardare i contatori è il modo più rapido per confermarlo, e la correzione è più piccola di quanto suggerisca l’indagine.

Controlla come il kernel chiama il dispositivo

Leggi le due viste separatamente prima di cambiare qualcosa:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

L’elenco dei link mostra le interfacce. L’elenco degli indirizzi può mostrare un secondo indirizzo IPv4 che porta l’etichetta eth0:0, e il dispositivo di quell’indirizzo è ancora eth0. Il manuale degli indirizzi di iproute2 tratta l’etichetta come un nome dell’indirizzo, non come un secondo link, ed è esattamente la distinzione su cui ruota tutto il problema.

La storia spiega la confusione. La vecchia ifconfig eth0:0 sintassi sembrava davvero una nuova interfaccia, e gli script di quell’epoca vi fanno ancora riferimento. Su un sistema attuale l’alias è un’etichetta su un indirizzo, e nulla nel percorso di routing o di netfilter lo tratta come un punto di uscita separato.

Controlla cosa ha intercettato davvero la regola

Leggi i contatori insieme all’elenco delle regole invece che a memoria:

iptables -t nat -L POSTROUTING -v -n --line-numbers

Una regola il cui contatore di pacchetti resta a zero mentre scorre traffico corrispondente non viene valutata, e una condizione sull’interfaccia di uscita che nomina eth0:0 è una causa comune. Il dispositivo di uscita scelto dalla rotta è eth0, quindi una condizione che cerca un altro nome non diventa mai vera, qualunque indirizzo di origine abbia scelto il kernel.

Cambia la condizione sul dispositivo reale e lascia fuori l’etichetta. Se devi distinguere due pool di client che condividono quel dispositivo, distinguili per prefisso di origine, non per un nome di interfaccia che non può esistere. Due regole con corrispondenze -s che non si sovrappongono sono leggibili e verificabili; una regola con un dispositivo inventato non è né l’una né l’altra. Dai a ogni regola un commento che nomini il pool, perché fra sei mesi il prefisso da solo non dirà a nessuno perché è lì.

Controlla la rotta che ha scelto il dispositivo

Il NAT di postrouting viene eseguito dopo che la rotta ha già scelto un’interfaccia di uscita, quindi l’interfaccia nella regola deve essere quella scelta dalla rotta. Chiedi direttamente al kernel con ip route get per un indirizzo client rappresentativo e leggi sia il dispositivo sia l’origine che riporta.

Se la risposta nomina eth0, la parte interfaccia della regola è risolta. Se nomina un dispositivo tunnel, il pacchetto non raggiunge mai la regola che stai modificando, e la ricerca si sposta sulla tabella di routing e sulle sue priorità. Una regola che non corrisponde mai perché il pacchetto è uscito altrove appare nell’output dei contatori identica a una regola con un dispositivo scritto male. Conferma quale dei due casi hai prima di modificare qualcosa, perché il secondo richiede un cambio di routing e non di testo.

Scegli deliberatamente l’origine tradotta

Una volta che il dispositivo è corretto, l’indirizzo di origine è una decisione separata. Questo è solo un pool IPv4 illustrativo e un indirizzo di esempio:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Scrivere un indirizzo in --to-source non fa sì che qualcuno lo instradi verso di te. Il provider a monte o il proprietario dell’indirizzo deve consegnare le risposte per quell’indirizzo a questo host, e l’indirizzo deve essere uno che sei autorizzato a usare. Se non lo è, la regola corrisponderà e tradurrà e le risposte andranno comunque altrove.

Cambiare l’indirizzo di origine non è la stessa cosa che cambiare il collegamento in salita. Quando il requisito reale è un percorso fisico diverso, la politica di routing deve prima selezionare quel percorso; poi SNAT riscrive l’origine sul dispositivo che la politica ha scelto. Aggiungere altre etichette a eth0 non fornisce né la rotta né l’autorizzazione.

Verifica con una connessione appena aperta

Apri una nuova connessione client invece di riutilizzarne una esistente. Il connection tracking conserva la traduzione registrata all’inizio del flusso, quindi una vecchia sessione può continuare a usare l’indirizzo di origine precedente e far sembrare rotta una nuova regola corretta. Osserva il contatore salire, poi guarda l’origine tradotta sul cavo o all’estremità remota.

Per più pool che condividono un’interfaccia, dai a ciascuno una corrispondenza di origine esplicita e il proprio indirizzo di traduzione, tienili nella configurazione gestita del firewall e annota l’ordine in cui vengono valutati. Poi annota ciò che hai verificato: il dispositivo da ip route get, il contatore che si è mosso e l’origine vista dal lato remoto. Quella nota risponde al prossimo rapporto senza ripetere la confusione dell’alias.

Articoli correlati