ufw allow 443 não fez nada por um serviço atrás da VPN

O ping funciona a partir de um cliente VPN, o serviço TCP expira e ufw allow 443/tcp não muda absolutamente nada. Quando a aplicação corre num anfitrião atrás da gateway e não na própria gateway, essa permissão foi escrita para o caminho de tráfego errado. O pacote não é endereçado à firewall e não é entregue a nenhum processo local, pelo que as regras de entrada nunca o veem. A correção é uma regra de rota dirigida ao fluxo reencaminhado, e a prova disso já está no registo.

Decida se o destino é local ou reencaminhado

Leia o pacote como o kernel o vê. O tráfego entregue a um serviço na gateway é entrada local. O tráfego que a gateway encaminha para outro anfitrião é reencaminhado, e o UFW mantém conjuntos de regras separados para os dois caminhos. A distinção é decidida pelo endereço de destino e pela consulta de encaminhamento, não pela interface por onde o pacote chegou.

Uma linha de registo que mostra a mesma interface nos campos IN e OUT pode continuar a descrever um pacote encaminhado, porque um túnel que leva clientes para dentro e para fora de um único dispositivo vê-se exatamente assim. O endereço de destino resolve a questão mais depressa do que os nomes das interfaces. Ver o mesmo nome duas vezes não prova uma entrega local, e inventar uma interface de túnel que a implementação nunca criou também não ajuda.

Leia o bloco antes de acrescentar qualquer regra

Reproduza uma tentativa de ligação autorizada e registe a origem, o destino, o protocolo e a porta de destino tal como a gateway os registou. Compare esses quatro valores com a entrada do registo e com a localização real do serviço. Um ping bem-sucedido anterior prova apenas que a sua própria troca estava permitida, e uma firewall pode tratar um TCP SYN para uma aplicação de forma muito diferente.

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

O primeiro comando devolve o veredicto com os seus campos, e o segundo mostra o que já está carregado e em que ordem. Leia ambos antes de editar seja o que for, porque uma negação anterior acima da sua regra explica o mesmo sintoma sem qualquer regra em falta.

Escreva a regra de rota mais estreita que se ajuste

Neste exemplo, os clientes chegam pela tun0 a partir de 172.20.8.0/24, o serviço escuta em 10.30.0.15 na porta 8443, e a gateway sai por ens5. Esses valores foram escolhidos para não se parecerem nada com um valor predefinido de VPC na nuvem de 10.0.0.0/16 nem com uma rede doméstica de 192.168.0.0/16, e 8443 mantém o exemplo longe do próprio ouvinte 443 da gateway.

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

A execução em seco imprime o conjunto de regras que resultaria, e é a forma mais barata de ver se a sua regra fica antes ou depois de uma negação existente. Confirme os nomes das interfaces e os endereços internos contra a implementação e não contra o exemplo, e lembre-se de que, quando a NAT de destino corre primeiro, o filtro vê o destino traduzido.

Mantenha o caminho de retorno com estado

O UFW acompanha as ligações permitidas, pelo que as respostas a um fluxo reencaminhado permitido são admitidas sem uma regra inversa explícita. Acrescentar uma regra sem restrições na direção oposta para que as coisas funcionem alarga a política muito para além do serviço único e não é necessário para uma troca normal de pedido e resposta. Mantenha o caminho de retorno implícito e o conjunto de regras legível.

Aplique a regra apenas quando a execução em seco corresponder à sua intenção, e depois confirme que a lista ordenada a mostra na posição esperada. Mantenha o ouvinte da VPN e as regras de gestão como assuntos separados, porque alterá-los é uma decisão diferente de admitir uma aplicação. Anote a alteração onde está escrita a topologia, para que o próximo engenheiro não tenha de a redescobrir a partir de uma captura de pacotes.

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

Verifique o que o UFW não pode impor por si

Uma regra correta continua a precisar do reencaminhamento do kernel e de uma rota que chegue ao serviço. Confirme ambos antes de culpar a firewall uma segunda vez.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Depois olhe para fora do anfitrião. Numa instância na nuvem, a política de UFW do convidado não substitui os grupos de segurança, as ACL de sub-rede nem a configuração de reencaminhamento do fornecedor, pelo que um bloqueio local é uma prova sobre uma camada e não a prova de que todas as outras camadas permitam o serviço.

Termine testando uma ligação nova com a firewall ativa, a partir de uma fonte permitida e de outra não relacionada. Desativar o UFW remove o sintoma e destrói a prova no mesmo comando, e é por isso que deve ser a última experiência e não a primeira.