Excepción de UFW para a VPN cando cambia o enderezo do extremo

O cliente tenta reconectarse e nada sae da máquina, aínda que o mesmo perfil funcionaba a semana pasada. O nome do extremo agora resólvese nun enderezo distinto, e a excepción de saída segue nomeando a antiga. Ese único permiso obsoleto abonda para converter un kill switch que funciona nunha caída total, e resulta invisible en todos os indicadores de estado que mostra o escritorio. A reparación é un fluxo de traballo pequeno e non unha edición dunha liña.

O túnel reconéctase e despois non sae nada

Unha regra de saída que nomea un enderezo de destino é unha instantánea, e as respostas DNS non o son. Cando o provedor rota un enderezo, o paquete que o cliente envía cara ao par novo non coincide con nada e a denegación por defecto descártao. O cliente informa entón dun tempo de espera esgotado, que soa a problema do servidor máis que do cortalumes.

Fixar o enderezo que devolve unha consulta pública fai que hoxe funcione e deixa mañá roto. Iso é unha edición puntual, non unha política de mantemento.

Describe a excepción que realmente pretendes

Comeza por anotar os catro valores que necesita a regra: o nome ou conxunto de enderezos do extremo aprobado, o transporte, o porto de destino e a interface pola que sae o paquete. Os catro forman parte do permiso, e calquera deles pode estar mal mentres a regra segue parecendo plausible. Unha regra correcta en tres deles falla exactamente igual que unha regra equivocada nos catro. Anótaos antes de teclear a orde, porque unha regra só vale o que vale a descrición que ten detrás.

A orde seguinte mostra a forma para un extremo IPv4 UDP nunha ligazón por cable. Substitúe ambos os valores polos que verificaches contra o despregamento.

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

Ese permiso non autoriza destinos arbitrarios no mesmo porto, non crea un escoitador e non cobre TCP. A páxina de manual de UFW describe como o enderezo, a interface e o protocolo estreitan unha regra, e ese estreitamento é xustamente o punto.

Refréscao como un só fluxo de traballo

Trata a excepción como un recurso con dono e transición, non como unha orde que alguén lembra executar. Primeiro obtén un candidato do resolver e do inventario de extremos do propio despregamento, e define a propósito como se resolve ese nome antes de que exista o túnel. Despois valida o candidato contra o protocolo, o porto e a familia de enderezos previstos antes de tocar o conxunto de regras.

Instala primeiro o novo permiso estreito e confirma que se cargou, porque pedir ao cliente que use un enderezo que o cortalumes aínda bloquea produce un fallo que parece unha avaría do servidor. Mantén intactas as regras non relacionadas durante o cambio.

Observa a transición do cliente pola súa ruta de reconexión admitida e confirma que enderezo remoto escolleu. Actualizar só o DNS non move un socket existente, e un axuste de persistencia do extremo pode manter o cliente no par antigo moito despois de que o rexistro cambie.

Por último, retira o permiso obsoleto a propósito, deixando a xanela de solapamento aprobada mentres unha sesión antiga segue activa. Eliminar a entrada antiga demasiado pronto produce unha caída breve; deixala para sempre deixa un permiso que ninguén sabe explicar.

Retira o permiso antigo a propósito

A retirada é onde está a maior parte do risco, porque a regra antiga é o único que funciona agora mesmo. Se a instalación do candidato fallou, non continúes nin borres a entrada que aínda leva tráfico. Se a retirada en si falla, rexistra o permiso obsoleto como obsoleto en lugar de declarar a política ao día.

Repite toda a revisión cando a ligazón pase de Ethernet a Wi-Fi, cando cambie o transporte ou cando un servizo rote entre varios enderezos. Suponse que unha regra específica de interface deixa de coincidir tras un cambio de rede, e ese comportamento é correcto aínda que pareza unha regresión.

Demostra o contrato despois con tráfico inofensivo. O extremo aprobado debe ser alcanzable durante a configuración, a aplicación protexida debe funcionar unha vez conectada, e o tráfico directo non relacionado debe seguir bloqueado durante unha caída. Inclúe ambas as familias de enderezos e un intento de actualización fallido a propósito, xa que unha conexión que funciona tras unha soa edición de enderezo fixado non demostra ningún deses casos.