A firewall está a bloquear a VPN? Uma verificação passo a passo

Um único tempo limite da VPN prova que não chegou qualquer resposta utilizável, e não prova nada sobre a causa. O perfil pode indicar a porta errada, o servidor pode estar em baixo, ou o pedido pode chegar sem um caminho de retorno funcional. Cada um destes casos deixa um rasto diferente, e é o rasto que lhe diz que regra tocar. Percorra as quatro etapas abaixo por ordem. Pare assim que uma delas explicar o sintoma.

Etapa 1: confirmar o servidor e o transporte

Leia o nome do servidor, o transporte e a porta do perfil atual do operador e não de uma alteração local. Uma porta alterada no seu portátil não pode criar um ouvinte num servidor público, e essa discrepância produz um tempo limite idêntico a um bloqueio. Se o perfil oferece um transporte alternativo suportado, registe-o como alternativa e não como correção. Resolva o nome e compare a resposta com o endereço que o operador publicou.

Um registo DNS obsoleto envia o cliente para um anfitrião que nunca respondeu. É outra falha que imita um filtro, e descartá-la custa uma única consulta.

Escreva os dois valores no ticket. Todas as comparações posteriores os usam, e um ticket sem eles reinicia a investigação.

Etapa 2: provar o caminho com uma única comparação controlada

Mantenha o dispositivo e o perfil sem alterações e experimente outra rede de acesso de confiança. Se o túnel subir aí, a diferença é o caminho original ou a sua política. Se um segundo dispositivo aprovado funcionar na rede original, a diferença é o primeiro dispositivo. Uma destas duas comparações é quase sempre decisiva.

Conclua primeiro qualquer início de sessão de rede legítimo, porque um portal cativo parece um bloqueio até estar concluído.

Teste a porta que realmente usa, e trate um resultado TCP como informação apenas sobre TCP.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Um handshake TCP bem-sucedido na porta 443 diz que aí respondeu um ouvinte. Não diz nada sobre um ouvinte UDP na 51820, nem sobre se a negociação foi concluída.

Etapa 3: ler os eventos de segurança do momento da falha

Os eventos da firewall são a prova mais forte disponível, e trazem uma ressalva que vale a pena dizer primeiro. O registo está desativado em muitos perfis predefinidos, por isso verifique se o perfil em causa registra descartes antes de ler um registo vazio como prova de inocência. Quando o registo está ativo, o evento indica a regra, a direção e os endereços, que é exatamente o que uma alteração de regra precisa. As regras de aplicação e as regras de porta são objetos separados, e a política gerida pode sobrepor-se a uma definição local. Confirme que cliente e que serviço uma regra cobre realmente.

Recolha o estado do perfil e os eventos recentes da máquina que falhou, não de um anfitrião vizinho.

Leia a hora do evento em relação à hora da sua tentativa de teste, porque um nome de regra coincidente com um carimbo temporal diferente é uma coincidência.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

Num servidor que administra, pergunte se o pedido chegou sequer ao ouvinte. Um pacote que chega sem resposta é um problema de encaminhamento ou de rota de retorno. Um pedido que nunca aparece é um problema de filtragem ou de endereçamento.

Etapa 4: testar o encaminhamento depois de o túnel estar de pé

Uma firewall pode permitir a sessão e ainda assim negar tudo o que a sessão quer alcançar. Os sysctl de encaminhamento, as regras NAT e as rotas de retorno ficam todos depois da autenticação, e uma isenção ampla para a porta da VPN não repara nenhuma delas. Teste um destino interno e um destino de internet em separado, porque costumam falhar por motivos diferentes. Se os nomes internos falharem mas os endereços funcionarem, olhe para o DNS empurrado antes de qualquer regra.

Execute as três verificações abaixo no servidor enquanto um cliente está ligado e tenta o pedido que falha.

Os contadores da interface do túnel são o ponto, porque mostram se os pacotes entraram e se algo saiu.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Quando chegam pacotes ao túnel e nada sai em direção ao destino, o suspeito é o encaminhamento ou o NAT. Quando não chega nada, a sessão está de pé mas o cliente não envia, e o lugar a olhar é a tabela de rotas do cliente.

Verificar a correção e remover o que não ajudou

Depois de uma correção aprovada, repita exatamente o teste que falhou e registe o resultado com o mesmo perfil e dispositivo. Depois remova qualquer exceção temporária que não tenha mudado o resultado, porque as exceções não utilizadas acumulam-se e cada uma é uma decisão que ninguém se lembra de ter tomado. Mantenha o que resta estreito: um destino, uma porta, uma direção, um responsável.

Volte a executar os mesmos três comandos e compare-os com as saídas que guardou antes da alteração.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Quando a rede de comparação funciona, a rede original continua a falhar e os eventos permanecem vazios, o suspeito restante é o caminho e não o anfitrião. Entregue isso ao responsável da rede como uma afirmação concreta, com os dois resultados de comparação anexados. É um melhor ponto para parar do que um perfil de firewall desativado.