Blocca un intervallo di destinazione per ogni pool di clienti VPN

Una regola basta a tenere un pool VPN ammesso lontano da un intervallo di destinazione senza disturbare il resto di ciò che fa il gateway. La regola in sé è breve; le parti che decidono se funziona sono l’hook in cui vive e la sua posizione nella catena. Sbagliare queste due produce un firewall che sembra corretto e si comporta in modo incoerente. Partite da ciò che fa il pacchetto quando la regola lo vede.

Che cosa confronta davvero la regola

La regola confronta tre cose insieme: un’interfaccia di ingresso, un prefisso di origine e un prefisso di destinazione. Tutte e tre devono essere vere prima che si applichi il drop, ed è questo che la tiene stretta. Leggerla come un’unica espressione è più facile che leggerla come tre politiche separate.

La corrispondenza dell’interfaccia è ciò che distingue il traffico dei clienti inoltrato dalle connessioni proprie del gateway. Senza di essa, una regola che nominasse solo il pool di origine colpirebbe anche i pacchetti che il gateway stesso genera da quell’indirizzo, se mai lo fa. Il prefisso di origine limita la politica ai clienti ammessi, e il prefisso di destinazione la limita a un solo intervallo. Leggete la regola come un’intersezione e non come un elenco.

Annotate i tre valori prima di modificare qualsiasi cosa: il nome dell’interfaccia del tunnel, il pool che il server assegna e il prefisso che intendete negare. Un errore di battitura in uno di essi produce una regola che viene analizzata senza errori e non protegge nulla. Tenete quei tre valori nel registro delle modifiche accanto alla regola.

L’hook decide a chi si applica la regola

Una catena netfilter è collegata a un hook, e l’hook decide quali pacchetti la catena vede davvero. L’hook forward vede il traffico instradato attraverso il gateway, cioè proprio il traffico da cliente a destinazione. Tutto il resto della catena è rivolto a un altro pubblico.

L’hook input vede il traffico indirizzato al gateway stesso, quindi una regola collocata lì governa l’accesso ai suoi servizi e non il transito. L’hook output vede il traffico che il gateway origina, cioè l’opposto di ciò che serve a una politica di pool di clienti. I nomi delle catene sono etichette arbitrarie scelte da chi ha scritto il set di regole, quindi non deducete l’hook dal nome. Verificate dove è agganciata la catena prima di supporre cosa possa confrontare.

Leggere l’aggancio è un controllo di una riga che impedisce a una regola di finire in una catena che non vede mai il pacchetto.

Mettete la regola prima dell’accept ampio

Le regole sono valutate in ordine e il primo verdetto vince. Un accept ampio più in alto nella catena termina la valutazione per i pacchetti che confronta, quindi un drop aggiunto dopo non viene mai eseguito per quelli. Quella regola d’ordine è l’intera ragione per cui una regola dall’aspetto corretto può non avere alcun effetto.

Inserite la regola prima dell’accept invece di aggiungerla in fondo. Se la catena contiene già un accept generale per l’interfaccia del tunnel, la nuova regola deve precederlo, altrimenti è soltanto decorativa. Controllate l’ordine risultante e non il file che avete modificato, perché un set di regole assemblato da più file può non corrispondere a nessuno di essi. Poi confermate con un pacchetto di prova dal pool.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

Il terzo comando analizza il file senza applicarlo, e intercetta gli errori di sintassi prima che diventino un’interruzione. Applicatelo con un piano di ripristino, perché una regola sbagliata in una catena forward può tagliare il tunnel su cui state lavorando.

I flussi esistenti non si curano della vostra nuova regola

Una voce conntrack creata prima che la regola esistesse continua a corrispondere all’accept precedente. Ecco perché un nuovo drop a volte sembra funzionare per connessioni nuove e non fare nulla per quella che si sta provando.

Leggete la corrispondenza di stato in cima alla catena. Se accetta traffico established e related prima della vostra regola, ogni flusso già in corso continua a fluire finché non si chiude. Di solito è il comportamento che volete per una regola d’emergenza, ed è confondente quando vi aspettate un taglio immediato. Decidete quale effetto volete prima di distribuire. Un test che riutilizza una connessione aperta vi racconterà una storia sbagliata.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

Il primo comando mostra se esiste un flusso, e il secondo se una regola di stato precoce continua ad accettarlo. Entrambi sono in sola lettura e sicuri durante un incidente.

Che cosa non è questa regola

La regola non è una lista nera di domini, una politica IPv6 né una restrizione su un singolo account applicativo.

Ognuna di queste cose richiede il proprio meccanismo. Un blocco di dominio deve risolvere nomi, cosa che un filtro di pacchetti non fa. Il traffico IPv6 ha bisogno della propria corrispondenza, perché un’espressione ip non dice nulla sui pacchetti ip6. Una restrizione a livello applicativo appartiene al servizio o a un proxy autenticato, non a una corrispondenza di prefisso. Tenere separati questi requisiti è ciò che impedisce di chiedere a una regola stretta di svolgere quattro lavori.

Il contratto che questa regola consegna è preciso: il traffico da un pool ammesso verso un prefisso di destinazione viene negato, mentre il traffico non correlato del gateway conserva la sua politica esistente. Scrivete quella frase accanto alla regola, e la prossima persona saprà a cosa serviva.