Entrambi i firewall possono filtrare il traffico VPN inoltrato, e collegano le regole al percorso dei pacchetti in modi diversi. iptables ha catene predefinite dentro una tabella, quindi FORWARD esiste come punto di hook con un nome. nftables separa il nome di una catena dal suo tipo, hook e priorità, il che significa che una catena normale chiamata FORWARD non filtra nulla. Confrontare i due modelli spiega perché una voce che sembra corretta in uno strumento non ha alcun effetto nell'altro.

Una catena è un contenitore. Se il kernel la consulta dipende dall'implementazione e da come il set di regole la collega.

Due modelli, due collegamenti diversi

In iptables la tabella filter arriva con tre catene predefinite, INPUT, FORWARD e OUTPUT, e -N crea una catena definita dall'utente che ha effetto solo quando si salta su di essa da una di quelle. Il manuale di nftables definisce invece le base chain, che dichiarano tipo, hook e priorità, e le catene normali, che non lo fanno. Una base chain può portare qualsiasi nome, e una catena normale chiamata FORWARD non ottiene alcuna proprietà dalla sua etichetta. Questa è tutta la differenza, ed è invisibile in un tutorial che mostra solo il testo delle regole.

I backend di compatibilità aggiungono una seconda ragione per non dedurre il comportamento dal nome di un comando. La documentazione di iptables segnala operazioni diverse sotto iptables-nft, quindi tratta nftables nativo, iptables-nft e un set di regole legacy come tre sistemi e non come tre grafie di uno solo.

Leggi l'errore nel suo contesto reale

Una tabella mancante, un errore di permessi, una funzione del kernel non disponibile e una catena con nome mancante sono quattro riscontri diversi, e solo uno riguarda la catena. Registra la versione dello strumento, la famiglia di indirizzi e la tabella richiesta, il namespace di rete e il primo errore esatto. Poi verifica quale componente possiede il set di regole: un servizio firewall o un gateway gestito da un prodotto può generare catene e ordinamento propri. Aggiungere una catena nativa accanto a loro lascia la policy gestita intatta e l'inventario più confuso.

Il namespace di un container può contenere un set di regole diverso da quello dell'host, quindi un comando eseguito nel contesto sbagliato non può mostrare quale catena ha visto un pacchetto inoltrato. Alzare i privilegi perché una catena attesa non era visibile non è una diagnosi.

I contatori provano il raggiungimento, non il verdetto

I contatori delle regole ti dicono che una regola è stata raggiunta. Non ti dicono che una regola successiva ha permesso l'operazione, e non provano che ogni percorso alternativo sia stato negato. Leggili durante un unico flusso autorizzato e innocuo, insieme all'ordine delle regole e al collegamento della catena, e trattali come una singola osservazione invece che come un verdetto. Un contatore diverso da zero su una regola di drop significa che il traffico l'ha colpita; non dice nulla sul traffico che non l'ha colpita.

L'inoltro IP del kernel è un'impostazione del tutto separata. L'esistenza di una catena non abilita l'inoltro, e l'assenza di un'etichetta familiare non significa che l'inoltro si sia fermato.

Descrivi il flusso che vuoi proteggere

Scrivi una richiesta client dopo la decapsulazione: la sua origine, la sua destinazione, la famiglia di indirizzi e se termina al gateway o lo attraversa. L'input di un servizio locale e il traffico inoltrato si osservano in punti diversi, quindi richiedono regole e test diversi. Per una VPN in bridge verifica anche il percorso del bridge, perché una catena a livello IP non controlla automaticamente i frame Ethernet.

Preserva un accesso di ripristino indipendente prima di modificare un gateway remoto. Poi conferma il flusso previsto e i dinieghi necessari sotto lo stesso set di regole. Una nuova catena vuota con un nome familiare non è una riparazione.

Il confronto finisce in una domanda: quale hook chiama davvero il kernel per questo pacchetto? Rispondi a questo, e il nome della catena smette di contare.

Articoli correlati