Marcature nftables e routing VPN: quale regola vince davvero

Una marcatura impostata in nftables dovrebbe inviare una classe di traffico attraverso il tunnel, e il traffico continua a uscire dall’interfaccia fisica. L’insieme di regole sembra corretto isolatamente. Ciò che di solito è successo è che qualcos’altro ha scritto la stessa marcatura, oppure che la regola di routing corrisponde a una maschera che il nuovo valore non soddisfa più.

Verifica 1: leggete la regola a cui il kernel corrisponde

Cominciate dalla regola di policy anziché dal firewall. Il kernel consulta le regole in ordine di priorità e la prima corrispondenza decide la tabella. Leggete il valore fwmark e la maschera dalla regola stessa, poi confermate che un pacchetto con la marcatura che avete impostato vi corrisponda davvero. Una regola che si aspetta un valore completo a 32 bit non corrisponderà a un pacchetto che porta un solo bit.

Poi confermate quale tabella seleziona quella regola e cosa contiene la tabella. Una regola che punta a una tabella vuota produce un errore di ricerca, che su molti sistemi significa che il pacchetto ricade sulla regola successiva ed esce dall’interfaccia fisica.

Due comandi risolvono la questione: l’elenco delle regole e la ricerca di rotta per la destinazione in quella tabella.

Verifica 2: marcatura del pacchetto o marcatura della connessione

nftables può impostare una marcatura sul pacchetto e una marcatura sulla voce di tracciamento delle connessioni, e sono oggetti diversi. La marcatura del pacchetto vive per la passata di elaborazione del pacchetto, mentre la marcatura della connessione persiste per il flusso e deve essere copiata deliberatamente. Impostarne una e aspettarsi l’altra è una mezza correzione comune.

Se la regola di routing si basa sulla marcatura del pacchetto, ripristinare la marcatura della connessione più avanti nel percorso non cambia nulla per quella decisione, perché la decisione è già stata presa.

Decidete quale oggetto possiede il segnale di routing, poi impostarlo nel punto in cui viene presa la decisione di routing.

Verifica 3: chi altro scrive quella marcatura

Gli strumenti di WireGuard marcano i propri pacchetti UDP perché il trasporto cifrato non venga instradato di nuovo nel tunnel a cui appartiene. Se il vostro insieme di regole assegna un valore non correlato allo stesso campo, quell’esclusione scompare e il traffico esterno del tunnel tenta di entrare in se stesso. Il sintomo è un tunnel che si stabilisce e poi smette di far passare traffico.

Le marcature sono usate anche da altri strumenti firewall, dalla rete dei container e dal routing basato su policy per altri scopi, quindi due sottosistemi che scrivono tutto il campo sono in conflitto anche quando ciascuno è corretto separatamente.

Elencate gli scrittori prima di aggiungerne un altro.

Verifica 4: la maschera decide cosa conservate

Una marcatura è un campo di 32 bit, e le maschere sono il modo in cui più proprietari lo condividono. Impostare un valore con una maschera preserva i bit che non possedete; impostare l’intero campo distrugge quelli di tutti gli altri. Leggete la maschera in ogni regola che tocca il campo, comprese quelle che non avete scritto.

Documentate l’allocazione dei bit accanto all’insieme di regole.

Altrimenti la persona successiva riutilizzerà un valore che ha già un proprietario, e un conflitto qui sembra un bug di routing mentre è un bug di indirizzamento. La documentazione nftables sui metadati dei pacchetti descrive le operazioni di marcatura stesse.

Verifica 5: verificate con un flusso reale, non con una ricerca

Una semplice ricerca di rotta non porta alcuna marcatura, quindi può mostrare un percorso diverso dal pacchetto reale. Generare il traffico che vi interessa e osservate i contatori, la voce di tracciamento delle connessioni e l’interfaccia da cui esce davvero. Provate sia la classe inclusa sia la classe esclusa, perché una marcatura troppo ampia rompe l’esclusione pur sembrando riuscita. Se la classe inclusa funziona e la classe esclusa entra anch’essa nel tunnel, la marcatura è troppo ampia e non troppo stretta.

Evitate di svuotare lo stato delle connessioni per forzare un aggiornamento durante una sessione attiva, dato che i flussi nuovi ed esistenti possono legittimamente prendere percorsi diversi.

Registrate marcatura, maschera e tabella in un unico posto, e la prossima modifica diventa verificabile.