Excepción de UFW para la VPN cuando cambia la dirección del extremo

El cliente intenta reconectarse y nada sale de la máquina, aunque el mismo perfil funcionaba la semana pasada. El nombre del extremo ahora se resuelve en una dirección distinta, y la excepción de salida sigue nombrando la antigua. Ese único permiso obsoleto basta para convertir un kill switch que funciona en una caída total, y resulta invisible en todos los indicadores de estado que muestra el escritorio. La reparación es un flujo de trabajo pequeño y no una edición de una línea.

El túnel se reconecta y después no sale nada

Una regla de salida que nombra una dirección de destino es una instantánea, y las respuestas DNS no lo son. Cuando el proveedor rota una dirección, el paquete que el cliente envía hacia el par nuevo no coincide con nada y la denegación por defecto lo descarta. El cliente informa entonces de un tiempo de espera agotado, que suena a problema del servidor más que del cortafuegos.

Fijar la dirección que devuelve una consulta pública hace que hoy funcione y deja mañana roto. Eso es una edición puntual, no una política de mantenimiento.

Describe la excepción que realmente pretendes

Empieza por anotar los cuatro valores que necesita la regla: el nombre o conjunto de direcciones del extremo aprobado, el transporte, el puerto de destino y la interfaz por la que sale el paquete. Los cuatro forman parte del permiso, y cualquiera de ellos puede estar mal mientras la regla sigue pareciendo plausible. Una regla correcta en tres de ellos falla exactamente igual que una regla equivocada en los cuatro. Anótalos antes de teclear la orden, porque una regla solo vale lo que vale la descripción que tiene detrás.

La orden siguiente muestra la forma para un extremo IPv4 UDP en un enlace por cable. Sustituye ambos valores por los que verificaste contra el despliegue.

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

Ese permiso no autoriza destinos arbitrarios en el mismo puerto, no crea un escucha y no cubre TCP. La página de manual de UFW describe cómo la dirección, la interfaz y el protocolo estrechan una regla, y ese estrechamiento es justamente el punto.

Refréscalo como un solo flujo de trabajo

Trata la excepción como un recurso con dueño y transición, no como una orden que alguien recuerda ejecutar. Primero obtén un candidato del resolución y del inventario de extremos del propio despliegue, y define a propósito cómo se resuelve ese nombre antes de que exista el túnel. Después valida el candidato contra el protocolo, el puerto y la familia de direcciones previstos antes de tocar el conjunto de reglas.

Instala primero el nuevo permiso estrecho y confirma que se cargó, porque pedir al cliente que use una dirección que el cortafuegos todavía bloquea produce un fallo que parece una avería del servidor. Mantén intactas las reglas no relacionadas durante el cambio.

Observa la transición del cliente por su ruta de reconexión admitida y confirma qué dirección remota eligió. Actualizar solo el DNS no mueve un socket existente, y un ajuste de persistencia del extremo puede mantener al cliente en el par antiguo mucho después de que el registro cambie.

Por último, retira el permiso obsoleto a propósito, dejando la ventana de solapamiento aprobada mientras una sesión antigua sigue activa. Eliminar la entrada antigua demasiado pronto produce una caída breve; dejarla para siempre deja un permiso que nadie sabe explicar.

Retira el permiso antiguo a propósito

La retirada es donde está la mayor parte del riesgo, porque la regla antigua es lo único que funciona ahora mismo. Si la instalación del candidato falló, no continúes ni borres la entrada que todavía lleva tráfico. Si la retirada en sí falla, registra el permiso obsoleto como obsoleto en lugar de declarar la política al día.

Repite toda la revisión cuando el enlace pase de Ethernet a Wi-Fi, cuando cambie el transporte o cuando un servicio rote entre varias direcciones. Se supone que una regla específica de interfaz deja de coincidir tras un cambio de red, y ese comportamiento es correcto aunque parezca una regresión.

Demuestra el contrato después con tráfico inofensivo. El extremo aprobado debe ser alcanzable durante la configuración, la aplicación protegida debe funcionar una vez conectada, y el tráfico directo no relacionado debe seguir bloqueado durante una caída. Incluye ambas familias de direcciones y un intento de actualización fallido a propósito, ya que una conexión que funciona tras una sola edición de dirección fijada no demuestra ninguno de esos casos.