Un firewall della distribuzione Linux può bloccare il traffico VPN

Il tunnel sale, il registro dice connesso, e un’applicazione continua a non raggiungere nulla. Su un client Linux questo di solito significa che il firewall della distribuzione filtra un percorso che il client VPN non ha mai gestito. Due gestori possono essere attivi contemporaneamente, ciascuno con le proprie idee sull’interfaccia, la zona e la direzione del traffico. Identificare il proprietario prima di modificare qualcosa è più veloce che provare regole finché qualcosa funziona.

Trova il gestore e il backend

Parti da ciò che è realmente caricato, non da ciò che è installato. Una distribuzione può fornire firewalld, ufw e un semplice servizio nftables, e solo uno di essi possiede il set di regole in esecuzione. I pacchetti convivono pacificamente, e una regola inserita dal frontend sbagliato non raggiunge mai il kernel. Leggi il servizio attivo, poi leggi il set di regole che ha prodotto.

Il backend conta quanto il frontend. Un’installazione di firewalld può pilotare nftables o il vecchio backend iptables a seconda della versione e della configurazione, e i due producono un output di ispezione diverso. Scrivi la distribuzione, la versione e il backend nel ticket prima di confrontare il tuo sistema con qualsiasi guida.

Allinea la direzione e l’interfaccia

Una richiesta in uscita del client, un listener in entrata e un pacchetto inoltrato attraversano hook diversi, e una regola per uno non copre gli altri. Una zona che consente la LAN locale spesso non include l’interfaccia del tunnel né il pool di indirizzi VPN. Un’interfaccia di tunnel di solito finisce nella zona predefinita, che è spesso più severa della zona in cui si trova l’adattatore fisico. Questa discrepanza spiega perché la navigazione funziona sulla LAN e si ferma nel momento in cui il tunnel sale.

Chiedi quale direzione ha fallito prima di scegliere una regola. Un’applicazione che non riesce a connettersi verso l’esterno ha bisogno del percorso di uscita, mentre un servizio in entrata ha bisogno del percorso di ingresso sull’interfaccia del tunnel. Aggiungere una regola alla catena sbagliata produce un cambiamento che sembra applicato e non fa assolutamente nulla.

Mantieni d’accordo i proprietari delle regole

L’hook di un client VPN, un runtime per container e il servizio della distribuzione possono tutti modificare la rete, e non si coordinano tra loro. Le regole inserite a mano scompaiono al successivo ricaricamento, e le regole inserite nella catena di un gestore possono essere valutate in un ordine che non avevi previsto. Usa la configurazione persistente del gestore e ispeziona il set di regole risultante invece del file che hai scritto. Disattivare l’intero firewall perché un servizio è irraggiungibile scambia un problema piccolo con uno grande.

I contatori stretti sono il modo economico per trovare il flusso rifiutato. Una regola di registrazione limitata a una destinazione e una porta mostra se lo scarto avviene localmente senza catturare il traffico altrui. Rimuovi la regola di registrazione al termine dell’indagine, perché è una diagnostica e non una politica, e la documentazione delle zone di firewalld spiega come si combinano interfacce e servizi.

Verifica la correzione senza perdere il blocco

Ispeziona lo stato applicato con il gestore che lo possiede, usando comandi che corrispondono al backend che hai annotato. L’elenco seguente presuppone che firewalld sia al comando; sostituiscilo con l’equivalente per nftables o ufw invece di eseguirli tutti. Mescolare strumenti in un’unica sessione è il modo in cui una macchina finisce con due set di regole in conflitto.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

Il primo comando nomina le zone e le interfacce assegnate, il che mostra dove è atterrato davvero il tunnel. Il secondo stampa le regole e i servizi di una zona, così puoi vedere se l’interfaccia VPN è coperta. L’elenco nftables è la verità di base per il backend in uso, e una regola che esiste solo in un file di configurazione non compare lì. Confronta i tre output con la regola aggiunta, e la discrepanza di solito si nomina da sola.

Poi ripeti la richiesta originale e il comportamento di errore che richiedi. Un sito che funziona di nuovo non basta se la stessa modifica ha rimosso il blocco del client, quindi prova anche un percorso non protetto. Annota il gestore, il backend, l’interfaccia e lo scopo della regola, perché un aggiornamento di pacchetto che rianima un secondo gestore ricostruirà altrimenti tutto il disordine.