Perfil de aplicativo do UFW ausente? Ele descreve portas, não serviços

O UFW diz que não encontra um perfil correspondente ao OpenSSH, e a busca pela causa vai direto ao servidor SSH. É a direção errada: a mensagem trata de uma definição de firewall nomeada e não diz nada sobre o sshd estar instalado, em execução ou escutando. Um perfil de aplicativo do UFW é uma lista de portas e protocolos com um rótulo. Ler a definição custa um comando e normalmente encerra a investigação.

Passo 1: liste os nomes que o UFW realmente conhece

Pergunte ao firewall quais nomes ele tem antes de pedir para permitir um. A lista vem dos perfis instalados nesta máquina, então um nome ausente é um fato sobre este sistema, não sobre o software que você tentava proteger. Se o nome existe, o erro veio de um erro de digitação ou de um alias antigo no histórico do seu shell.

ufw app list
ufw app info OpenSSH

A lista é curta numa instalação padrão, e os nomes não são nomes de pacotes. Um perfil chamado OpenSSH pode faltar enquanto o pacote openssh-server está instalado, e o contrário também é possível. Use o nome exato que a lista imprime; um nome de perfil VPN ou um lançador de desktop com grafia parecida não é um perfil de aplicativo do UFW. Se o nome que você quer falta, esse é o achado, e o próximo passo é ver o que deveria fornecê-lo.

Passo 2: leia a definição, não o rótulo

Um perfil é um arquivo no estilo INI em /etc/ufw/applications.d, com nome, título, descrição e um campo de portas. O campo de portas pode listar várias portas e transportes, então o rótulo diz menos que a definição. O manual do UFW documenta esses campos e a operação de atualização de aplicativos. Leia o arquivo em vez de supor que o nome significa uma porta conhecida.

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

Uma definição que contém 22/tcp descreve a porta TCP 22 e nada mais. Ela não prova que o daemon desta máquina escuta ali, e não cobre uma segunda porta adicionada depois. Se o daemon roda em outro lugar, o perfil é a permissão errada mesmo que o nome combine com o produto. Compare o ouvinte com a definição antes de permitir qualquer um dos dois.

ss -ltnp 'sport = :22'

Pare se a definição e o ouvinte não concordam. Permitir um perfil que nomeia uma porta onde ninguém escuta cria uma regra que parece progresso e não protege nada.

Passo 3: separe o perfil do serviço em execução

Permitir um perfil nomeado não instala, inicia nem configura o serviço, e um serviço em execução não precisa de um perfil empacotado para ser alcançável. São decisões separadas de ferramentas diferentes: o gerenciador de pacotes, o gerenciador de serviços e o firewall. Tratá-las como uma só é como as pessoas instalam um servidor indesejado para que um nome simbólico apareça.

Para um servidor VPN a separação continua depois que o ouvinte externo é permitido. A permissão para a porta do transporte criptografado não ativa o encaminhamento no kernel, não adiciona uma regra NAT e não dá aos usuários do túnel acesso a uma LAN. Cada um desses é uma política separada com sua própria revisão. Um perfil com o nome do produto VPN descreve apenas as portas que lista, e o resto da configuração do servidor ainda é sua para escrever.

Se o perfil falta e você precisa de um, uma regra de porta explícita revisada ou um perfil local em applications.d são ambos legítimos. Instalar um pacote que você não queria não é.

Passo 4: guarde um caminho de volta antes de recarregar o firewall

Antes de qualquer mudança de regra, confirme que você tem uma segunda via para a máquina: um console, um endereço fora de banda ou um retorno programado. Depois leia o conjunto de regras e a política padrão, porque uma negação padrão sem regra SSH é a forma clássica de se trancar para fora durante os testes. Mude uma regra por vez e leia a confirmação que o UFW imprime. Uma regra salva, uma regra ativa e um serviço alcançável são três observações diferentes.

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

Depois da mudança, teste a conexão permitida e um caminho que ainda deveria ser negado. O teste de negação importa tanto quanto o de permissão, porque uma regra mais ampla que o previsto passa no primeiro teste e falha no segundo. Anote o nome do perfil, as portas que ele continha e o ouvinte contra o qual você verificou.

A lista de verificação termina quando o nome existe ou foi substituído de propósito, a definição corresponde ao ouvinte real, o serviço é gerenciado separadamente, e você testou tanto um caminho permitido quanto um negado com uma rota de recuperação à mão. Um nome na lista não é nada disso.