¿Falta el perfil de aplicación de UFW? Describe puertos, no servicios

UFW dice que no encuentra un perfil que coincida con OpenSSH, y la búsqueda de la causa va directa al servidor SSH. Es la dirección equivocada: el mensaje trata de una definición de cortafuegos con nombre y no dice nada sobre si sshd está instalado, en marcha o escuchando. Un perfil de aplicación de UFW es una lista de puertos y protocolos con una etiqueta. Leer la definición cuesta un comando y normalmente termina la investigación.

Paso 1: enumera los nombres que UFW conoce de verdad

Pregunta al cortafuegos qué nombres tiene antes de pedirle que permita uno. La lista proviene de los perfiles instalados en esta máquina, así que un nombre ausente es un hecho sobre este sistema y no sobre el software que intentabas proteger. Si el nombre está, el error vino de una errata o de un alias antiguo del historial de tu shell.

ufw app list
ufw app info OpenSSH

La lista es corta en una instalación por defecto, y los nombres no son nombres de paquetes. Un perfil llamado OpenSSH puede faltar mientras el paquete openssh-server está instalado, y lo contrario también es posible. Usa el nombre exacto que imprime la lista; un nombre de perfil VPN o un lanzador de escritorio con una grafía parecida no es un perfil de aplicación de UFW. Si falta el nombre que quieres, ese es el hallazgo, y el paso siguiente es mirar qué debería proporcionarlo.

Paso 2: lee la definición, no la etiqueta

Un perfil es un archivo de estilo INI en /etc/ufw/applications.d, con un nombre, un título, una descripción y un campo de puertos. El campo de puertos puede listar varios puertos y transportes, así que la etiqueta dice menos que la definición. El manual de UFW documenta estos campos y la operación de actualización de aplicaciones. Lee el archivo en lugar de suponer que el nombre significa un puerto conocido.

cat /etc/ufw/applications.d/openssh-server
ufw app info OpenSSH

Una definición que contiene 22/tcp describe el puerto TCP 22 y nada más. No demuestra que el demonio de esta máquina escuche ahí, y no cubre un segundo puerto que añadieras después. Si el demonio corre en otro lugar, el perfil es el permiso equivocado aunque su nombre coincida con el producto. Compara el receptor con la definición antes de permitir cualquiera de los dos.

ss -ltnp 'sport = :22'

Detente si la definición y el receptor no coinciden. Permitir un perfil que nombra un puerto donde nadie escucha crea una regla que parece un avance y no protege nada.

Paso 3: separa el perfil del servicio en marcha

Permitir un perfil con nombre no instala, inicia ni configura el servicio, y un servicio en marcha no necesita un perfil empaquetado para ser accesible. Son decisiones separadas que pertenecen a herramientas distintas: el gestor de paquetes, el gestor de servicios y el cortafuegos. Tratarlas como una sola es como la gente instala un servidor no deseado para que aparezca un nombre simbólico.

Para un servidor VPN la separación continúa después de permitir el receptor exterior. El permiso para el puerto del transporte cifrado no habilita el reenvío del núcleo, no añade una regla NAT y no da a los usuarios del túnel acceso a una LAN. Cada uno de esos es una política separada con su propia revisión. Un perfil con el nombre del producto VPN solo describe los puertos que lista, y el resto de la configuración del servidor sigue siendo tuya de escribir.

Si falta el perfil y necesitas uno, una regla de puerto explícita revisada o un perfil local en applications.d son ambos legítimos. Instalar un paquete que no querías no lo es.

Paso 4: guarda una vía de vuelta antes de recargar el cortafuegos

Antes de cualquier cambio de regla, confirma que tienes una segunda vía hacia la máquina: una consola, una dirección fuera de banda o un retorno programado. Después lee el conjunto de reglas y la política por defecto, porque una denegación por defecto sin regla SSH es la forma clásica de quedarte fuera mientras pruebas. Cambia una regla cada vez y lee la confirmación que imprime UFW. Una regla guardada, una regla activa y un servicio accesible son tres observaciones distintas.

ufw status verbose
ufw allow 22/tcp
ufw app update OpenSSH

Después del cambio, prueba la conexión permitida y una vía que aún debería denegarse. La prueba de denegación importa tanto como la de permiso, porque una regla más amplia de lo previsto pasa la primera prueba y falla la segunda. Anota el nombre del perfil, los puertos que contenía y el receptor contra el que verificaste.

La lista de comprobación termina cuando el nombre existe o se ha sustituido a propósito, la definición coincide con el receptor real, el servicio se gestiona por separado, y has probado tanto una vía permitida como una denegada con una ruta de recuperación a mano. Un nombre en la lista no es nada de eso.