VPN conectada mas a firewall ainda bloqueia: como saber qual

O cliente diz conectado, o recurso continua a recusar, e o próximo passo habitual é desligar algo. Os dois controles dessa frase fazem trabalhos diferentes: a VPN constrói um caminho para o tráfego coberto, e uma firewall decide por ligação se o tráfego pode passar. Um túnel a funcionar com uma política que recusa parece exatamente um túnel avariado da cadeira do utilizador, por isso a tarefa é descobrir qual camada responde. Esta é a ordem que sigo, com a leitura que lhe diz para parar.

Separe o caminho da política

Comece pela forma da falha, porque é informação gratuita. Uma queda de pacote produz um tempo limite: o cliente tenta de novo, nada volta e o comando fica pendurado até desistir. Uma recusa produz uma negação ou um reinício: algo respondeu e disse não. Um serviço que não escuta recusa no próprio anfitrião, sem qualquer firewall.

Esses três resultados apontam para camadas diferentes. O tempo limite significa que alguma política em algum lugar descarta em silêncio, ou que o caminho nunca sai da máquina. Recusado significa que chegou ao anfitrião e a sua pilha ou a firewall local recusou. Silêncio total, com a interface do túnel ativa e sem rota para o destino, significa que o caminho está errado e nenhuma regra de firewall o corrige.

Leia o caminho numa passagem

Confirme que o túnel cobre o destino antes de olhar para uma única regra. Um túnel dividido que só leva a sub-rede do escritório não encaminha um pedido para outro intervalo, e então a falha parece um bloqueio da firewall que não é:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

A saída da rota nomeia a interface por onde o pacote vai sair e o endereço de origem que vai levar. Se essa interface for a sua placa de rede física e não o túnel, o problema está no encaminhamento ou nos intervalos permitidos do túnel, e pertence à configuração da VPN e não à firewall.

Uma armadilha específica da VPN merece a sua própria verificação. No WireGuard, AllowedIPs de um par é ao mesmo tempo uma rota e um filtro criptográfico: um pacote cujo endereço de origem não pertence ao conjunto permitido do par é descartado antes de qualquer regra de firewall ser consultada. Assim, uma firewall local perfeitamente correta pode estar atrás de um descarte silencioso que parece uma política, e a correção é uma linha de configuração da chave e não uma regra.

Leia a política na camada que responde

Quando o caminho está correto, percorra a política do anfitrião para fora e observe a única camada cujos contadores se movem:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

O socket à escuta responde a uma pergunta diferente da das regras. Se nada escuta na porta, o núcleo recusa a ligação e nenhuma regra de entrada é relevante. Se o socket existe e a ligação de um cliente remoto expira, está a ocorrer um descarte em algum ponto do caminho, e os contadores das regras dizem-lhe se é aqui.

Ative o registo para o perfil ou a cadeia que suspeita em vez de adivinhar de fora. Um único descarte registado que nomeia origem, destino e porta identifica a camada e a regra, e também prova que o pacote chegou, o que nenhum teste do lado do cliente consegue estabelecer.

Leia a decisão da passagem quando o túnel termina ali

Numa passagem site-to-site ou de acesso remoto, a VPN autentica um utilizador e a política autoriza um recurso, e essas são concessões separadas. Um utilizador admitido no túnel não é admitido automaticamente em cada anfitrião interno, e a recusa vem muitas vezes de uma regra de encaminhamento enquanto o próprio túnel está saudável. A mesma separação aparece no IPsec, onde a política de segurança que seleciona o tráfego é distinta do filtro que o admite, e por isso os dois são documentados como mecanismos diferentes em RFC 4301.

Verifique o caminho de regresso com o mesmo cuidado que o de ida. A filtragem com estado precisa de ver a resposta, por isso o encaminhamento assimétrico pelo túnel numa direção e à volta dele na outra produz descartes que parecem aleatórios e só se reproduzem a partir de alguns clientes. Se o tráfego chega à passagem e para, leia a regra de encaminhamento e a rota de regresso em conjunto antes de alargar seja o que for.

A passagem é também onde uma regra de NAT ou de mascaramento pode esconder a origem real. Se os anfitriões internos virem o endereço da passagem em vez do cliente, as suas regras de firewall local que devem corresponder ao conjunto de clientes nunca corresponderão, e a correção pertence à passagem e não a cada servidor.

Altere a camada mais estreita e depois verifique

Resista à reparação ampla. Desativar a firewall local, acrescentar uma regra que permita tudo ou forçar cada interface a um perfil de confiança retira sempre o controlo que fazia o seu trabalho, e a alteração sobrevive ao incidente. Uma regra limitada ao intervalo de origem e à porta em questão é mais fácil de rever, mais fácil de remover, e deixa o resto da política da máquina intacto.

Verifique com o mesmo teste que falhou, a partir do mesmo cliente, e depois mais uma vez após reconectar, porque uma regra que corresponde antes de o túnel renegociar pode deixar de corresponder depois:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Antes de fechar:

• A rota para o destino sai pela interface do túnel, e o endereço de origem corresponde ao que a política espera.
• Algo escuta na porta, e a recusa ou o tempo limite é atribuído a uma regra nomeada em vez de presumido.
• A passagem encaminha nos dois sentidos, e o destino vê a origem para a qual as suas regras foram escritas.
• Nenhum controlo foi desativado para o teste passar, e a alteração que fez nomeia um único intervalo de origem e uma única porta.