El ping funciona en un solo sentido: por qué Windows descarta el eco del servidor

Tu cliente hace ping al servidor, el servidor no puede hacer ping al cliente, y el túnel transporta paquetes con claridad en ambas afirmaciones. Lo que difiere no es la ruta sino el primer paquete de cada prueba: uno es una respuesta a un flujo que Windows ya sigue, el otro es una petición entrante nueva que ninguna regla ha admitido. Esa diferencia explica la mayoría de los informes de ping unidireccional y apunta directamente a la regla que tienes que escribir. Dos pruebas en sentidos opuestos separan los casos en aproximadamente un minuto.

Dos sentidos, dos decisiones distintas

Cuando el cliente envía la petición de eco, el cortafuegos de Windows ve una conexión saliente que ha decidido permitir. La respuesta vuelve dentro de ese flujo establecido, así que el motor con estado la admite sin consultar ninguna regla entrante para ICMP. Eso es lo que significa el filtrado con estado en la práctica, y la regla que nadie escribió no interviene. Por tanto, el éxito del cliente no dice nada sobre la política entrante.

Cuando el servidor envía la petición primero, ningún estado coincide con ella. Windows trata el paquete como una conexión entrante nueva y pregunta a la política entrante, que por defecto no prevé nada para las peticiones de eco que llegan de fuentes arbitrarias.

Así pues, el éxito del cliente demostró que el ICMP saliente y la ruta de vuelta funcionan. Nunca ejercitó la decisión entrante, y la conclusión natural, que el cortafuegos está bien, es razonable y errónea. Por eso el error se repite en tickets que ya contienen la prueba.

Sigue el paquete hasta que desaparezca

Confirma las direcciones antes de cambiar nada: usa la dirección de túnel que el cliente tiene realmente y comprueba que el servidor enruta hacia ella y no hacia una dirección LAN detrás del cliente. Los dos fallos parecen idénticos desde el símbolo del sistema del servidor, porque ambos acaban en un tiempo de espera agotado. Dónde muere el paquete es el único hecho que decide qué cambiar.

Si la petición llega a la interfaz del túnel y no sale nada, el cortafuegos local es el motivo probable. Si nunca llega a la interfaz, la respuesta está más arriba: una ruta del servidor, una política saliente o la entrega propia entre pares de la VPN.

Captura en la interfaz del túnel del cliente mientras el servidor hace ping. Ver llegar la petición sin una respuesta a su lado es la prueba que justifica escribir una regla de Windows. No ver nada te envía más arriba, y una regla añadida en ese estado solo hace la máquina más permisiva para un paquete que nunca llegó. En cualquier caso, la captura cuesta menos que las conjeturas que sustituye.

Limita una regla en lugar de abrir ICMP

Identifica el adaptador y su categoría actual antes de escribir nada, porque ambos aparecen en el ámbito que estás a punto de fijar. Ese alias es el nombre de la interfaz de Windows, que no es necesariamente el nombre del perfil de VPN que importaste. Los comandos de abajo enumeran lo que existe y luego previsualizan una regla limitada sin aplicarla.

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 es la petición de eco, el único mensaje que el servidor necesita ver respondido. Limítala a la dirección de túnel del servidor y a la interfaz del túnel, y deja el perfil tal como el adaptador es realmente. Renombrar una red para encajar con un ejemplo es un cambio aparte con consecuencias propias.

Lo que la regla no cubre

El eco de IPv6 es otro protocolo con otro tipo de mensaje, así que una regla ICMPv4 no dice nada sobre él, y un túnel que transporta ambas familias necesita su propia regla para la otra. Esta regla tampoco abre nada más: RDP, el uso compartido de archivos y todos los demás servicios siguen dependiendo de su propia política. Ese es todo el sentido de limitar una regla estrecha en lugar de habilitar un permiso amplio de ICMP. El permiso amplio es la solución fácil y la que sobrevive más tiempo, porque nadie se da cuenta después.

En un dispositivo gestionado la regla puede sustituirse en la próxima actualización de política, así que el propietario de la política tiene que hacer el cambio equivalente y no un administrador local. Escribe la intención en el ticket además del comando, porque una actualización borrará el comando y dejará intacto el requisito. No son el mismo artefacto, y solo uno de los dos sobrevive.

Lee el resultado en el sentido correcto

Una vez aplicada la regla, haz ping desde el servidor y confirma que una respuesta llega al cliente, luego haz ping desde una fuente que todavía debe quedar excluida y confirma que no llega. Repite la prueba de accesibilidad en la otra familia de direcciones si el túnel transporta una.

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

Imprimir la regla que entró en vigor es más útil que confiar en el comando que la creó, porque una previsualización y una regla aplicada son estados distintos. Si el filtro de direcciones muestra la fuente que pretendías y la fuente excluida sigue agotando el tiempo de espera, la regla hace exactamente lo que dice su ámbito. Un ping correcto originado en el cliente nunca lo habría demostrado, y por eso el sentido de cada prueba pertenece al registro junto a su resultado. Guarda ambos sentidos en el ticket, o el siguiente lector repetirá la prueba que no puede fallar.