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

O teu cliente fai ping ao servidor, o servidor non pode facer ping ao cliente, e o túnel transporta paquetes con claridade en ambas as afirmacións. O que difire non é a ruta senón o primeiro paquete de cada proba: un é unha resposta a un fluxo que Windows xa segue, o outro é unha petición entrante nova que ningunha regra admitiu. Esa diferenza explica a maioría dos informes de ping unidireccional e apunta directamente á regra que tes que escribir. Dúas probas en sentidos opostos separan os casos en aproximadamente un minuto.

Dous sentidos, dúas decisións distintas

Cando o cliente envía a petición de eco, a devasa de Windows ve unha conexión saínte que decidiu permitir. A resposta volve dentro dese fluxo establecido, así que o motor con estado admítea sen consultar ningunha regra entrante para ICMP. Iso é o que significa o filtrado con estado na práctica, e a regra que ninguén escribiu non intervén. Por tanto, o éxito do cliente non di nada sobre a política entrante.

Cando o servidor envía a petición primeiro, ningún estado coincide con ela. Windows trata o paquete como unha conexión entrante nova e pregunta á política entrante, que por defecto non prevé nada para as peticións de eco procedentes de fontes arbitrarias.

Así pois, o éxito do cliente demostrou que o ICMP saínte e a ruta de volta funcionan. Nunca exerceu a decisión entrante, e a conclusión natural, que a devasa está ben, é razoable e errónea. Por iso o erro se repite en tíckets que xa conteñen a proba.

Segue o paquete ata que desapareza

Confirma os enderezos antes de cambiar nada: usa o enderezo de túnel que o cliente ten realmente e comproba que o servidor encamiña cara a el e non cara a un enderezo LAN detrás do cliente. Os dous fallos parecen idénticos desde o símbolo do sistema do servidor, porque ambos acaban nun tempo de espera esgotado. Onde morre o paquete é o único feito que decide que cambiar.

Se a petición chega á interface do túnel e non sae nada, a devasa local é o motivo probable. Se nunca chega á interface, a resposta está máis arriba: unha ruta do servidor, unha política saínte ou a entrega propia entre pares da VPN.

Captura na interface do túnel do cliente mentres o servidor fai ping. Ver chegar a petición sen unha resposta ao lado é a proba que xustifica escribir unha regra de Windows. Non ver nada envíate máis arriba, e unha regra engadida nese estado só fai a máquina máis permisiva para un paquete que nunca chegou. En calquera caso, a captura custa menos que as conxecturas que substitúe.

Limita unha regra en lugar de abrir ICMP

Identifica o adaptador e a súa categoría actual antes de escribir nada, porque ambos aparecen no ámbito que estás a piques de fixar. Ese alias é o nome da interface de Windows, que non é necesariamente o nome do perfil de VPN que importaches. Os comandos de abaixo enumeran o que existe e despois previsualizan unha regra limitada sen aplicala.

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

ICMPv4 tipo 8 é a petición de eco, a única mensaxe que o servidor precisa ver respondida. Limítaa ao enderezo de túnel do servidor e á interface do túnel, e deixa o perfil tal como o adaptador é realmente. Renomear unha rede para encaixar nun exemplo é un cambio aparte con consecuencias propias.

O que a regra non cobre

O eco de IPv6 é outro protocolo con outro tipo de mensaxe, así que unha regra ICMPv4 non di nada sobre el, e un túnel que transporta ambas as familias necesita a súa propia regra para a outra. Esta regra tampouco abre nada máis: RDP, a compartición de ficheiros e todos os demais servizos seguen dependendo da súa propia política. Ese é todo o sentido de limitar unha regra estreita en lugar de habilitar un permiso amplo de ICMP. O permiso amplo é a solución fácil e a que sobrevive máis tempo, porque ninguén se decata despois.

Nun dispositivo xestionado a regra pode substituírse na próxima actualización de política, así que o propietario da política ten que facer o cambio equivalente e non un administrador local. Escribe a intención no tícket ademais do comando, porque unha actualización borrará o comando e deixará o requisito intacto. Non son o mesmo artefacto, e só un dos dous sobrevive.

Le o resultado no sentido correcto

Unha vez aplicada a regra, fai ping desde o servidor e confirma que unha resposta chega ao cliente, despois fai ping desde unha fonte que aínda debe quedar excluída e confirma que non chega. Repite a proba de accesibilidade na outra familia de enderezos se o túnel transporta unha.

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

Imprimir a regra que entrou en vigor é máis útil que confiar no comando que a creou, porque unha previsualización e unha regra aplicada son estados distintos. Se o filtro de enderezos mostra a fonte que pretendías e a fonte excluída segue esgotando o tempo de espera, a regra fai exactamente o que di o seu ámbito. Un ping correcto orixinado no cliente nunca o tería demostrado, e por iso o sentido de cada proba pertence ao rexistro xunto ao seu resultado. Garda ambos os sentidos no tícket, ou o seguinte lector repetirá a proba que non pode fallar.