ufw allow 443 no hizo nada por un servicio detrás de la VPN

El ping funciona desde un cliente VPN, el servicio TCP expira y ufw allow 443/tcp no cambia absolutamente nada. Cuando la aplicación se ejecuta en un host detrás de la puerta de enlace y no en la puerta de enlace misma, ese permiso se escribió para una ruta de tráfico equivocada. El paquete no está dirigido al cortafuegos y no se entrega a ningún proceso local, así que las reglas de entrada nunca lo ven. La reparación es una regla de ruta dirigida al flujo reenviado, y la prueba de ello ya está en el registro.

Decide si el destino es local o reenviado

Lee el paquete tal como lo ve el núcleo. El tráfico entregado a un servicio en la puerta de enlace es entrada local. El tráfico que la puerta de enlace encamina hacia otro host es reenviado, y UFW mantiene conjuntos de reglas separados para las dos rutas. La distinción la deciden la dirección de destino y la consulta de enrutamiento, no la interfaz por la que llegó el paquete.

Una línea de registro que muestra la misma interfaz en los campos IN y OUT puede seguir describiendo un paquete enrutado, porque un túnel que lleva clientes dentro y fuera de un solo dispositivo se ve exactamente así. La dirección de destino resuelve la pregunta más rápido que los nombres de las interfaces. Ver el mismo nombre dos veces no demuestra una entrega local, e inventar una interfaz de túnel que el despliegue nunca creó tampoco ayuda.

Lee el bloque antes de añadir cualquier regla

Reproduce un intento de conexión autorizado y captura su origen, destino, protocolo y puerto de destino tal como los registró la puerta de enlace. Compara esos cuatro valores con la entrada del registro y con la ubicación real del servicio. Un ping correcto anterior solo demuestra que su propio intercambio estaba permitido, y un cortafuegos puede tratar un TCP SYN hacia una aplicación de forma muy distinta.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

El primer comando devuelve el veredicto junto con sus campos, y el segundo muestra qué está ya cargado y en qué orden. Lee ambos antes de editar nada, porque una denegación anterior por encima de tu regla explica el mismo síntoma sin que falte ninguna regla.

Escribe la regla de ruta más estrecha que encaje

En este ejemplo, los clientes llegan por tun0 desde 172.20.8.0/24, el servicio escucha en 10.30.0.15 en el puerto 8443, y la puerta de enlace sale por ens5. Esos valores se eligieron para no parecerse en nada a un valor predeterminado de VPC en la nube de 10.0.0.0/16 ni a una red doméstica de 192.168.0.0/16, y 8443 mantiene el ejemplo lejos del propio escucha 443 de la puerta de enlace.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

La ejecución en seco imprime el conjunto de reglas que resultaría, que es la forma más barata de ver si tu regla queda antes o después de una denegación existente. Confirma los nombres de interfaz y las direcciones internas contra el despliegue y no contra el ejemplo, y recuerda que cuando la NAT de destino se ejecuta primero, el filtro ve el destino traducido.

Mantén la ruta de retorno con estado

UFW rastrea las conexiones permitidas, así que las respuestas a un flujo reenviado permitido se admiten sin una regla inversa explícita. Añadir una regla sin restricciones en la dirección opuesta para que las cosas funcionen amplía la política mucho más allá del único servicio y no es necesario para un intercambio normal de petición y respuesta. Mantén la ruta de retorno implícita y el conjunto de reglas legible.

Aplica la regla solo cuando la ejecución en seco coincida con tu intención, y luego confirma que la lista ordenada la muestra en la posición esperada. Conserva el escucha de la VPN y las reglas de gestión como asuntos separados, ya que cambiarlos es una decisión distinta de admitir una aplicación. Anota el cambio donde está escrita la topología, para que el siguiente ingeniero no tenga que redescubrirlo a partir de una captura de paquetes.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Comprueba qué no puede aplicar UFW por ti

Una regla correcta sigue necesitando el reenvío del núcleo y una ruta que llegue al servicio. Confirma ambas cosas antes de culpar al cortafuegos por segunda vez.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Después mira fuera del host. En una instancia en la nube, la política de UFW del invitado no sustituye a los grupos de seguridad, las ACL de subred ni la configuración de reenvío del proveedor, así que un bloqueo local es una prueba sobre una capa y no la prueba de que todas las demás capas permitan el servicio.

Termina probando una conexión nueva con el cortafuegos activo, desde una fuente permitida y desde otra no relacionada. Desactivar UFW elimina el síntoma y destruye la prueba en el mismo comando, por eso debería ser el último experimento y no el primero.