Il kill switch di UFW blocca la tua VPN? Consenti il peer

Hai seguito la checklist: nega l'uscita, consenti il tunnel, abilita ufw. Poi il client attende all'handshake e non si connette mai, oppure si connette e nessuna pagina si carica. Entrambi i fallimenti nascono dalla stessa lacuna. Manca la regola che permette al tunnel di esistere, perché il tunnel non è un'interfaccia da cui escono i tuoi pacchetti.

Perché un permesso su tun0 all'inizio non corrisponde a nulla

tun0 viene creato dal client dopo che esiste una sessione. I datagrammi che costruiscono quella sessione sono normali pacchetti UDP indirizzati al provider sulla porta 1194, ed escono da wlan0 o eth0 con l'indirizzo sorgente fisico. allow out on tun0 corrisponde solo al traffico la cui interfaccia di uscita è tun0, quindi durante l'handshake non corrisponde a nulla.

Metti default deny outgoing sopra e i pacchetti esterni vengono scartati prima che l'interfaccia compaia. Il client riprova, va in timeout e segnala un errore TLS o di handshake, il che manda la gente a frugare tra certificati e MTU mentre il firewall si mangia la connessione in silenzio. La regola che doveva contenere il tuo traffico impedisce che quel traffico venga contenuto.

La correzione riflessa rende permanente la fuga. sudo ufw allow out on wlan0, o riportare il default su consentire, alza il tunnel e lascia la macchina senza kill switch: la prossima volta che il tunnel cade, tutto riprende dall'adattatore fisico. Ho perso un pomeriggio esattamente su quella coppia di modifiche prima di capire quale pacchetto stessi filtrando davvero.

Di cosa hanno bisogno i due insiemi di pacchetti

Il tuo traffico attraversa il firewall due volte, in due forme. Il pacchetto interno va dall'indirizzo del tunnel verso l'esterno attraverso tun0. Il pacchetto esterno va dall'indirizzo fisico al peer, ed è l'unica cosa visibile sul filo. Una regola per forma:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Sostituisci indirizzo e porta con quelli del tuo profilo. I peer WireGuard di solito rispondono su 51820/udp; i profili OpenVPN che passano su TCP 443 hanno bisogno di quella porta invece. I dettagli cambiano, la forma no: entrambe le regole sono strette e insieme definiscono le uniche destinazioni che la macchina può raggiungere mentre il tunnel è giù.

L'ordine è il secondo mito. Con iptables grezzo leggi la catena dall'alto in basso e ragioni su quale regola vince. ufw non è un sottile involucro attorno alla lista che hai digitato; compila le tue regole nelle proprie catene e sceglie i punti di inserimento. ufw status le stampa nell'ordine di ufw, non nel tuo. Quando una regola sembra ignorata, confronta ufw show added con l'insieme compilato da iptables -S | grep ufw prima di riscrivere qualcosa.

L'eccezione deve restare larga un solo indirizzo

Una regola peer è corretta solo finché nomina l'indirizzo che il client compone. I provider ruotano gli endpoint, e un profilo che risolve un nome host seguirà un cambio DNS verso un nuovo indirizzo mentre la regola continua a puntare al vecchio. Quando un tunnel che funzionava da mesi smette di alzarsi, confronta l'indirizzo nella regola con quello che il client sta cercando prima di allargare qualcosa.

Allargare a un'intera sottorete, o a ogni destinazione sulla porta 1194, riporta la politica a un firewall con un buco. L'eccezione è il kill switch; una volta che è ampia, non resta più niente da spegnere. Tienila su un solo indirizzo e lascia un commento che nomini il profilo e il provider a cui appartiene, perché tra sei mesi l'indirizzo sembrerà arbitrario.

La risoluzione dei nomi merita una riga sua. La ricerca avviene prima che il tunnel esista, sull'interfaccia fisica, quindi una politica severa di rifiuto dell'uscita può lasciare il client incapace di trovare il proprio server. Consenti la porta 53 verso l'indirizzo del tuo resolver, oppure risolvi una volta e fissa l'indirizzo nel profilo. Consentire DNS su ogni interfaccia è una decisione, non un default.

Costruisci la politica prima che il tunnel serva

ufw enable applica l'intera politica in una volta e ricarica le sue catene, e cambiare una politica predefinita su un firewall in esecuzione le ricarica anch'esso. Il manuale di ufw avverte che questo può far cadere connessioni esistenti come SSH. Perciò i comandi vanno in quest'ordine, con la regola SSH prima dell'attivazione e una sessione console aperta:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset è lasciato fuori da quel blocco di proposito. Cancella ogni regola e disattiva il firewall, e su un host remoto l'attivazione successiva è ciò che fa cadere la tua sessione. Se fai comunque il reset, aggiungi la regola SSH e conferma una seconda via di ritorno tramite console prima di andare avanti.

La sequenza non è cosmetica. Le regole aggiunte mentre ufw è in esecuzione non svuotano nulla, ma nel momento in cui giri una politica predefinita le catene si ricaricano, e una sessione che la vecchia politica permetteva se ne va con loro. Fai i default, i permessi e l'attivazione in un solo passaggio, finché hai ancora una via d'ingresso che non dipende dalla macchina.

Prova lo stato bloccato e conserva l'annullamento

Un kill switch non testato è una supposizione. Disconnetti il client di proposito e prova a caricare una pagina: deve fallire. Riconnetti e deve riprendersi senza toccare una regola. sudo ufw status verbose conferma i default e lo stato di registrazione, e ufw status numbered mostra quale regola di test cancellare quando sopravvive al suo scopo.

Tieni lo script inverso accanto a quello diretto. Una macchina con rifiuto dell'uscita e un tunnel morto non può scaricare la propria riparazione, quindi l'annullamento deve stare sul disco ed essere leggibile da una console:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Eseguilo quando il tunnel è già giù e le regole vanno tolte, non come passo di routine. Prima di chiudere il terminale, quattro cose devono valere: la regola peer nomina esattamente un indirizzo, il DNS ha un'eccezione nominata, l'attivazione è arrivata dopo i permessi, e tirare il tunnel uccide il traffico ordinario senza uccidere il client per sempre.