Excepció d’UFW per a la VPN quan canvia l’adreça de l’extrem

El client intenta tornar-se a connectar i no surt res de la màquina, tot i que el mateix perfil funcionava la setmana passada. El nom de l’extrem es resol ara en una adreça diferent, i l’excepció de sortida encara anomena la vella. Aquest únic permís obsolet n’hi ha prou per convertir un kill switch que funciona en una caiguda total, i és invisible en tots els indicadors d’estat que mostra l’escriptori. La reparació és un petit flux de treball i no una edició d’una línia.

El túnel es reconnecta, i llavors no en surt res

Una regla de sortida que anomena una adreça de destinació és una instantània, i les respostes DNS no ho són. Quan el proveïdor rota una adreça, el paquet que el client envia cap al parell nou no coincideix amb res i la denegació per defecte el descarta. Llavors el client informa d’un temps d’espera esgotat, que sona com un problema del servidor i no pas del tallafoc.

Fixar l’adreça que retorna una consulta pública fa que avui funcioni i que demà quedi trencat. Això és una edició puntual, no una política de manteniment.

Descriu l’excepció que realment vols

Comença per escriure els quatre valors que necessita la regla: el nom o conjunt d’adreces de l’extrem aprovat, el transport, el port de destinació i la interfície per la qual surt el paquet. Tots quatre formen part del permís, i qualsevol d’ells pot ser incorrecte mentre la regla encara sembla plausible. Una regla que és correcta en tres d’ells falla exactament igual que una regla que és incorrecta en tots quatre. Escriu-los abans d’escriure l’ordre, perquè una regla només val tant com la descripció que hi ha al darrere.

L’ordre següent mostra la forma per a un extrem IPv4 UDP en un enllaç per cable. Substitueix tots dos valors pels que has verificat contra el desplegament.

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

Aquest permís no autoritza destinacions arbitràries al mateix port, no crea cap oient i no cobreix TCP. La pàgina de manual d’UFW descriu com l’adreça, la interfície i el protocol estrenyen una regla, i aquest estrenyiment és precisament el punt.

Refresca-ho com un sol flux de treball

Tracta l’excepció com un recurs amb un propietari i una transició, no com una ordre que algú recorda executar. Primer obtén un candidat del resolutor i de l’inventari d’extrems del propi desplegament, i defineix deliberadament com es resol aquest nom abans que existeixi el túnel. Després valida el candidat contra el protocol, el port i la família d’adreces previstos abans de tocar el conjunt de regles.

Instal·la primer el nou permís estret i confirma que s’ha carregat, perquè demanar al client que faci servir una adreça que el tallafoc encara bloqueja produeix un error que sembla una fallada del servidor. Mantén intactes les regles no relacionades durant el canvi.

Observa la transició del client pel seu camí de reconnexió suportat i confirma quina adreça remota ha triat. Actualitzar només el DNS no mou un sòcol existent, i un paràmetre de persistència de l’extrem pot mantenir el client al parell vell molt després que el registre hagi canviat.

Finalment, retira el permís obsolet a propòsit, permetent la finestra de superposició aprovada mentre una sessió vella encara és activa. Eliminar l’entrada vella massa aviat produeix una breu caiguda; deixar-la per sempre deixa un permís que ningú no pot explicar.

Retira el permís vell a propòsit

L’eliminació és on hi ha la major part del risc, perquè la regla vella és l’única cosa que funciona ara mateix. Si la instal·lació del candidat ha fallat, no continuïs ni esborris l’entrada que encara porta trànsit. Si la mateixa eliminació falla, registra el permís obsolet com a obsolet en lloc de declarar la política actual.

Repeteix tota la revisió quan l’enllaç passi d’Ethernet a Wi-Fi, quan canviï el transport o quan un servei roti per diverses adreces. Una regla específica d’una interfície ha de deixar de coincidir després d’un canvi de xarxa, i aquest comportament és correcte encara que sembli una regressió.

Demostra el contracte després amb trànsit inofensiu. L’extrem aprovat ha de ser abastable durant la configuració, l’aplicació protegida ha de funcionar un cop connectada, i el trànsit directe no relacionat ha de romandre bloquejat durant una caiguda. Inclou les dues famílies d’adreces i un intent d’actualització fallit a propòsit, ja que una connexió que s’aconsegueix després d’una sola edició d’adreça fixada no demostra cap d’aquests casos.