Uma firewall da distribuição Linux pode bloquear o tráfego VPN

O túnel sobe, o registo diz ligado, e uma aplicação continua a não alcançar nada. Num cliente Linux isso costuma significar que a firewall da distribuição filtra um caminho que o cliente VPN nunca geriu. Dois gestores podem estar ativos ao mesmo tempo, cada um com as suas ideias sobre a interface, a zona e a direção do tráfego. Identificar o proprietário antes de alterar seja o que for é mais rápido do que tentar regras até algo funcionar.

Encontre o gestor e o backend

Comece pelo que está realmente carregado, não pelo que está instalado. Uma distribuição pode trazer firewalld, ufw e um serviço nftables simples, e só um deles possui o conjunto de regras em execução. Os pacotes coexistem pacificamente, e uma regra introduzida pelo frontend errado nunca chega ao núcleo. Leia o serviço ativo e depois leia o conjunto de regras que ele produziu.

O backend importa tanto quanto o frontend. Uma instalação de firewalld pode conduzir nftables ou o backend iptables antigo conforme a versão e a configuração, e ambos produzem uma saída de inspeção diferente. Escreva a distribuição, a versão e o backend no ticket antes de comparar o seu sistema com qualquer guia.

Faça coincidir a direção e a interface

Um pedido de saída do cliente, um ouvinte de entrada e um pacote reencaminhado atravessam ganchos diferentes, e uma regra para um não cobre os outros. Uma zona que permite a LAN local muitas vezes não inclui a interface do túnel nem o conjunto de endereços da VPN. A interface do túnel costuma aterrar na zona predefinida, que é frequentemente mais restrita do que a zona do adaptador físico. Essa discrepância explica porque é que a navegação funciona na LAN e para no momento em que o túnel sobe.

Pergunte qual direção falhou antes de escolher uma regra. Uma aplicação que não consegue ligar-se para fora precisa do caminho de saída, enquanto um serviço de entrada precisa do caminho de entrada na interface do túnel. Acrescentar uma regra à cadeia errada produz uma alteração que parece aplicada e não faz absolutamente nada.

Mantenha os proprietários das regras de acordo

O gancho de um cliente VPN, um ambiente de execução de contentores e o serviço da distribuição podem todos modificar a rede, e não se coordenam entre si. As regras introduzidas à mão desaparecem no recarregamento seguinte, e as regras inseridas na cadeia de um gestor podem ser avaliadas numa ordem que não pretendia. Use a configuração persistente do gestor e inspecione o conjunto de regras resultante em vez do ficheiro que escreveu. Desativar a firewall inteira porque um serviço está inacessível troca um problema pequeno por um grande.

Os contadores estreitos são a forma barata de encontrar o fluxo rejeitado. Uma regra de registo limitada a um destino e uma porta mostra se o descarte acontece localmente sem capturar o tráfego de mais ninguém. Remova a regra de registo quando a investigação terminar, porque é um diagnóstico e não uma política, e a documentação de zonas da firewalld explica como as interfaces e os serviços se combinam.

Verifique a correção sem perder o bloqueio

Inspecione o estado aplicado com o gestor que o possui, usando comandos que correspondam ao backend que registou. A lista seguinte assume que a firewalld está no comando; substitua pelo equivalente para nftables ou ufw em vez de executar todas. Misturar ferramentas numa única sessão é como uma máquina acaba com dois conjuntos de regras em conflito.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

O primeiro comando nomeia as zonas e as interfaces que lhes estão atribuídas, o que mostra onde o túnel aterrou realmente. O segundo imprime as regras e serviços de uma zona, para que possa ver se a interface VPN está coberta. A lista do nftables é a verdade fundamental do backend em uso, e uma regra que só existe num ficheiro de configuração não aparece ali. Compare as três saídas com a regra que acrescentou, e a discrepância costuma nomear-se sozinha.

Depois repita o pedido original e o comportamento de falha que exige. Um site que passou a funcionar não basta se a mesma alteração removeu o bloqueio do cliente, por isso teste também um caminho sem proteção. Registe o gestor, o backend, a interface e o objetivo da regra, porque uma atualização de pacote que reavive um segundo gestor reconstruirá de outra forma toda a confusão.