nftables: inserire la regola di autorizzazione VPN prima dell’handle di drop

Mettete una regola di autorizzazione nel posto sbagliato e si comporta come se non esistesse alcuna regola. In nftables la scelta tra insert e add decide su quale lato di una regola referenziata finisce la nuova istruzione, e un handle nomina la regola nel set di regole attivo anziché il suo numero di riga. Se il posizionamento è sbagliato, il pacchetto raggiunge prima il drop.

Il confronto qui sotto usa un peer fisso e uno scambio di listener esterno. È volutamente ristretto; sostituire un’intera catena è un’altra modifica, con un altro profilo di rischio.

Due posizionamenti, due esiti diversi

insert colloca una regola prima della regola referenziata. add la colloca dopo. Se la regola referenziata è il drop terminale del flusso, questi due comandi producono risultati opposti anche quando il testo della regola è identico.

Omettere una posizione ha il proprio comportamento predefinito, un’altra ragione per non copiare un comando da un forum senza leggere a cosa è ancorato. L’ancora è tutta la decisione. Annotate il lato previsto prima di digitare il comando. insert e add differiscono di una parola nel file.

Il posizionamento è relativo a una regola in una catena specifica. Spostare la stessa istruzione in un’altra catena o in un’altra priorità di hook cambia quali pacchetti vede, anche quando la sintassi della regola sembra corretta.

Un handle identifica una regola, non un numero di riga

Un handle come 42 è un identificatore nello stato attuale del set di regole. Non è la quarantaduesima regola e non è stabile tra host, ricostruzioni o un gestore che ricarica la propria configurazione.

Individuate la catena e il drop terminale effettivo prima di scegliere l’ancora. Poi confermate l’handle su quella regola nello stesso elenco che mostra il drop, così che numero e regola si leggano insieme. Un handle letto da un elenco vecchio può già appartenere a un’altra regola. Rileggetelo nella sessione che applicherà la modifica.

iptables --version
nft -a list ruleset

La versione di iptables indica quale backend è in uso. Un set di regole iptables-nft e una tabella nativa gestita in modo indipendente possono coesistere, quindi un elenco da un solo frontend non è automaticamente l’immagine completa del filtraggio. Controllate entrambe le viste prima di scegliere una catena.

Trovate la catena e la regola che effettivamente fa drop

Leggete l’hook di input, la priorità della catena e la regola che rifiuta questo flusso di listener. Una tabella inet può portare entrambe le famiglie di indirizzi, ma una singola regola può ancora corrispondere solo a IPv4.

Prendete un peer approvato, usando 198.51.100.25 dell’intervallo di documentazione come esempio. Un file nativo rivisto potrebbe collocare un’autorizzazione esterna prima dell’handle 42:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Sostituite famiglia, tabella, catena, handle, interfaccia di ingresso e peer dopo l’ispezione. L’esempio usa la forma di posizionamento per handle documentata per nft 1.0.9, e appartiene a un file di input; il quoting delle graffe è una questione separata quando il comando viene digitato in modo interattivo.

Mantenete chiaro il proprietario della configurazione. Un gestore che ricostruisce le proprie regole può sovrascrivere una modifica a runtime, e uno script di avvio che codifica un handle obsoleto fallirà o si aggancerà alla regola sbagliata.

L’autorizzazione è limitata, il drop è terminale

Un verdetto di autorizzazione termina la valutazione sul percorso attuale, ma una catena base applicabile in seguito può ancora scartare il pacchetto. Un verdetto di drop è terminale. Per questo un contatore di autorizzazioni crescente non è prova che il flusso sia riuscito.

Esaminate tutte le priorità di hook rilevanti invece di una catena isolata. Un pacchetto può superare un filtro di input ed essere comunque rifiutato dall’hook di un’altra tabella a una priorità diversa. Elencate ogni catena base che può vedere il flusso.

Quella regola copre solo lo scambio del listener esterno. ESP incapsulato nel trasporto, ESP nativo, peer IPv6 e il traffico decifrato dentro il tunnel hanno tutti bisogno di proprie politiche. Non è un firewall VPN di sito completo.

Controllate il file, poi verificate il risultato attivo

Eseguite un controllo di sintassi e transazione sul file rivisto prima di applicarlo. La modalità di controllo indica se nft può analizzare e preparare la modifica; non la applica e non dimostra che un altro hook consentirà il pacchetto. Il file resta una proposta finché il proprietario non lo applica:

nft -c -f reviewed-vpn-rule.nft

Applicatelo tramite il processo controllato del proprietario e preservate l’accesso di ripristino. Se la regola è sbagliata, il drop che cercavate di precedere può anche tagliare il percorso che usate per correggerla.

Dopo la modifica, osservate un nuovo tentativo di peer consentito e verificate che le sorgenti fuori dal peer approvato siano ancora rifiutate. Spostate la regola durevole nel gestore che possiede il set di regole, perché gli handle a runtime individuano gli oggetti correnti invece di identificarli tra un avvio e l’altro.