O ping só funciona num sentido: por que o Windows descarta o eco do servidor

O seu cliente faz ping ao servidor, o servidor não consegue fazer ping ao cliente, e o túnel transporta claramente pacotes em ambas as afirmações. O que difere não é o caminho, mas o primeiro pacote de cada teste: um é uma resposta a um fluxo que o Windows já segue, o outro é um pedido novo de entrada que nenhuma regra admitiu. Essa diferença explica a maioria dos relatos de ping unidirecional e aponta diretamente para a regra que tem de escrever. Dois testes em sentidos opostos separam os casos em cerca de um minuto.

Dois sentidos, duas decisões diferentes

Quando o cliente envia o pedido de eco, a firewall do Windows vê uma ligação de saída que decidiu permitir. A resposta regressa dentro desse fluxo estabelecido, pelo que o motor com estado a admite sem consultar qualquer regra de entrada para ICMP. É isto que a filtragem com estado significa na prática, e a regra que ninguém escreveu não está envolvida. O sucesso do cliente não diz, portanto, nada sobre a política de entrada.

Quando o servidor envia o pedido primeiro, nenhum estado lhe corresponde. O Windows trata o pacote como uma nova ligação de entrada e interroga a política de entrada, que por omissão nada prevê para pedidos de eco vindos de fontes arbitrárias.

O sucesso do cliente provou então que o ICMP de saída e o caminho de regresso funcionam. Nunca exercitou a decisão de entrada, e a conclusão natural, de que a firewall está bem, é razoável e errada. É por isso que o erro se repete em tickets que já contêm a prova.

Siga o pacote até desaparecer

Confirme os endereços antes de mudar o que quer que seja: utilize o endereço de túnel que o cliente tem realmente e verifique que o servidor encaminha para ele e não para um endereço LAN atrás do cliente. As duas falhas parecem idênticas a partir da linha de comandos do servidor, porque ambas terminam em tempo esgotado. Onde o pacote morre é o único facto que decide o que alterar.

Se o pedido chega à interface do túnel e nada sai, a firewall local é a razão provável. Se nunca chega à interface, a resposta está mais acima: uma rota no servidor, uma política de saída ou a entrega própria da VPN entre pares.

Capture na interface do túnel do cliente enquanto o servidor faz ping. Ver o pedido chegar sem uma resposta ao lado é a prova que justifica escrever uma regra do Windows. Não ver nada remete-o para cima, e uma regra acrescentada nesse estado só torna a máquina mais permissiva para um pacote que nunca chegou. Em qualquer dos casos, a captura custa menos do que as suposições que substitui.

Limite uma regra em vez de abrir o ICMP

Identifique o adaptador e a sua categoria atual antes de escrever seja o que for, pois ambos aparecem no âmbito que vai definir. Esse alias é o nome da interface do Windows, que não é necessariamente o nome do perfil de VPN que importou. Os comandos abaixo listam o que existe e depois pré-visualizam uma regra limitada sem a aplicar.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

O ICMPv4 tipo 8 é o pedido de eco, a única mensagem a que o servidor precisa de ver resposta. Limite-o ao endereço de túnel do servidor e à interface do túnel, e deixe o perfil tal como o adaptador é realmente. Renomear uma rede para encaixar num exemplo é uma alteração separada com consequências próprias.

O que a regra não cobre

O eco IPv6 é outro protocolo com outro tipo de mensagem, pelo que uma regra ICMPv4 nada diz sobre ele, e um túnel que transporta ambas as famílias precisa da sua própria regra para a outra. Esta regra também não abre mais nada: o RDP, a partilha de ficheiros e todos os outros serviços continuam dependentes da sua própria política. É todo o sentido de limitar uma regra estreita em vez de ativar uma permissão ICMP ampla. A permissão ampla é a correção fácil e a que sobrevive mais tempo, porque ninguém a nota depois.

Num dispositivo gerido a regra pode ser substituída na próxima atualização de política, pelo que o proprietário da política tem de fazer a alteração equivalente e não um administrador local. Escreva a intenção no ticket além do comando, porque uma atualização apagará o comando e deixará o requisito intacto. Os dois não são o mesmo artefacto, e só um deles sobrevive.

Leia o resultado no sentido correto

Depois de a regra vigorar, faça ping a partir do servidor e confirme que uma resposta chega ao cliente, depois faça ping a partir de uma fonte que ainda deve ficar excluída e confirme que não chega. Repita o teste de alcançabilidade na outra família de endereços se o túnel transportar uma.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

Imprimir a regra que entrou em vigor é mais útil do que confiar no comando que a criou, porque uma pré-visualização e uma regra aplicada são estados diferentes. Se o filtro de endereços mostrar a fonte pretendida e a fonte excluída continuar a esgotar o tempo, a regra faz exatamente o que o seu âmbito diz. Um ping bem-sucedido originado no cliente nunca o teria demonstrado, e é por isso que o sentido de cada teste pertence ao registo ao lado do resultado. Guarde ambos os sentidos no ticket, ou o próximo leitor repetirá o teste que não pode falhar.