Eccezione UFW per il VPN quando cambia l’indirizzo dell’endpoint

Il client tenta di riconnettersi e nulla esce dalla macchina, anche se lo stesso profilo funzionava la settimana scorsa. Il nome host dell’endpoint ora si risolve in un indirizzo diverso, e l’eccezione in uscita nomina ancora quello vecchio. Quella singola autorizzazione scaduta basta a trasformare un kill switch funzionante in un’interruzione totale, ed è invisibile in ogni indicatore di stato che il desktop mostra. La riparazione è un piccolo flusso di lavoro, non una modifica di una riga.

Il tunnel si riconnette, poi più nulla esce

Una regola in uscita che nomina un indirizzo di destinazione è un’istantanea, e le risposte DNS non lo sono. Quando il provider ruota un indirizzo, il pacchetto che il client invia verso il nuovo peer non corrisponde a nulla e viene scartato dal rifiuto predefinito. Il client segnala quindi un timeout, che suona come un problema del server più che del firewall.

Fissare l’indirizzo che restituisce una ricerca pubblica fa funzionare oggi e lascia rotto domani. È una modifica una tantum, non una politica di manutenzione.

Descrivi l’eccezione che intendi davvero

Inizia scrivendo i quattro valori che la regola richiede: il nome o l’insieme di indirizzi dell’endpoint approvato, il trasporto, la porta di destinazione e l’interfaccia da cui esce il pacchetto. Tutti e quattro fanno parte dell’autorizzazione, e ognuno può essere sbagliato mentre la regola sembra ancora plausibile. Una regola corretta su tre di essi fallisce esattamente come una regola sbagliata su tutti e quattro. Scrivili prima di digitare il comando, perché una regola vale solo quanto la descrizione che la sostiene.

Il comando qui sotto mostra la forma per un endpoint IPv4 UDP su un collegamento via cavo. Sostituisci entrambi i valori con quelli che hai verificato rispetto al deployment.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

Quell’autorizzazione non consente destinazioni arbitrarie sulla stessa porta, non crea un listener e non copre TCP. La pagina di manuale di UFW descrive come indirizzo, interfaccia e protocollo restringono una regola, e quel restringimento è tutto il punto.

Aggiornala come un unico flusso di lavoro

Tratta l’eccezione come una risorsa con un proprietario e una transizione, non come un comando che qualcuno si ricorda di eseguire. Ottieni prima un candidato dal resolver e dall’inventario degli endpoint del deployment stesso, e definisci deliberatamente come quel nome si risolve prima che il tunnel esista. Poi valida il candidato contro il protocollo, la porta e la famiglia di indirizzi previsti prima di toccare l’insieme di regole.

Installa prima la nuova autorizzazione ristretta e conferma che sia stata caricata, perché chiedere al client di usare un indirizzo che il firewall blocca ancora produce un errore che sembra un guasto del server. Lascia intatte le regole non correlate durante il cambio.

Osserva la transizione del client lungo il suo percorso di riconnessione supportato e conferma quale indirizzo remoto ha scelto. Aggiornare solo il DNS non sposta un socket esistente, e un’impostazione di persistenza dell’endpoint può trattenere il client sul peer vecchio molto dopo che il record è cambiato.

Infine ritira l’autorizzazione obsoleta di proposito, consentendo la finestra di sovrapposizione approvata finché una vecchia sessione è ancora attiva. Rimuovere la vecchia voce troppo presto produce una breve interruzione; lasciarla per sempre lascia un’autorizzazione che nessuno sa spiegare.

Ritira la vecchia autorizzazione di proposito

La rimozione è dove sta la maggior parte del rischio, perché la vecchia regola è l’unica cosa che funziona in questo momento. Se l’installazione del candidato è fallita, non proseguire e non cancellare la voce che porta ancora traffico. Se la rimozione stessa fallisce, registra l’autorizzazione scaduta come scaduta invece di dichiarare la politica aggiornata.

Ripeti l’intera revisione quando il collegamento passa da Ethernet a Wi-Fi, quando cambia il trasporto o quando un servizio ruota su più indirizzi. Una regola specifica di un’interfaccia dovrebbe smettere di corrispondere dopo un cambio di rete, e quel comportamento è corretto anche se sembra una regressione.

Dimostra poi il contratto con traffico innocuo. L’endpoint approvato deve essere raggiungibile durante la configurazione, l’applicazione protetta deve funzionare una volta connessa, e il traffico diretto non correlato deve restare bloccato durante un’interruzione. Includi entrambe le famiglie di indirizzi e un tentativo di aggiornamento fallito di proposito, perché una connessione che riesce dopo una sola modifica di indirizzo fissato non dimostra nessuno di questi casi.