Ping no es una prueba: recorra la ruta entre dos sedes

El túnel está activo, las puertas de enlace se responden y los usuarios de una sede siguen sin poder abrir el recurso compartido de la otra. Alguien hace ping desde la puerta de enlace, obtiene respuesta y declara la red sana. Esa respuesta viajó entre dos dispositivos que nunca fueron el problema. Una prueba útil empieza en el host que necesita el servicio, usa el protocolo que usa la aplicación y reproduce la condición en la que falla. Todo lo demás es luz verde para una ruta que nadie recorre.

Empiece en el cliente que necesita el servicio

Anote cuatro cosas antes de probar nada: la dirección del cliente, la dirección de destino, el nombre de host y el puerto de la aplicación. Después confirme que el servicio funciona localmente en su propia sede, desde un host contiguo. Sin esa línea base no puede distinguir un túnel roto de un servicio roto, y la mitad de estos casos son el segundo.

Pruebe el nombre de host documentado y, donde el servicio lo permita, una comprobación de dirección directa del mismo puerto. Una búsqueda de nombre fallida y una dirección resuelta inalcanzable le llevan por caminos distintos. Si sustituye un nombre de host por una IP, no desactive la comprobación de identidad HTTPS para que funcione; un aviso de certificado es información, no un obstáculo.

Recorra la ruta en cada extremo

Lea la ruta que elige el cliente, después la ruta que elige la puerta de enlace para ese destino, después los contadores o una captura acotada en cada extremo. Busca dos hechos: si la petición llegó a la LAN remota y si volvió una respuesta. Los contadores de interfaz incluyen todos los demás flujos, así que correlacione por marca de tiempo exacta y par de direcciones en lugar de por la forma del gráfico. Una captura tomada en el extremo equivocado es peor que ninguna, porque parece una prueba.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

Si la petición aparece en el extremo remoto sin respuesta detrás, el problema está en el otro lado: un cortafuegos, una ruta de retorno ausente o un host que no acepta el origen. Si la petición nunca aparece, la ruta local o los selectores del túnel no la transportaron, y el otro lado todavía no merece la investigación.

Use el protocolo que usa la aplicación

ICMP es una sonda débil. Se puede filtrar, limitar por velocidad o tratar con una política distinta a la del servicio, lo que hace ambiguos tanto su éxito como su fallo. Pruebe el puerto real y, cuando pueda, el apretón de manos real del protocolo.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

Un apretón de manos TCP completado demuestra alcanzabilidad y política para ese puerto. No demuestra que la aplicación funcione: la autenticación, una carga o una llamada API concreta aún pueden fallar. Pruebe la operación que los usuarios realizan de verdad, con un equivalente inofensivo en lugar de enviar repetidamente una transacción real.

Reproduzca la condición que falla

Los fallos que solo aparecen con transferencias grandes son un problema de tamaño, no de conectividad. Envíe un paquete grande con el bit don't-fragment activado y observe dónde se detiene. Si una petición pequeña tiene éxito y una grande se cuelga, la MTU del túnel y el tratamiento de MSS en las puertas de enlace son los siguientes sospechosos.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

Si solo falla una subred, mire los selectores de tráfico, los anuncios de rutas y la puerta de enlace de retorno de esa subred. Si solo falla el nombre de host, siga el DNS, incluido qué resolutor usó el cliente y si la vista remota es visible desde esa sede. Tres fallos distintos, tres soluciones distintas, y la prueba de ping no distingue ninguno.

Después de la corrección, repita la misma prueba

Vuelva a ejecutar el mismo cliente, destino, puerto y carga. Luego reconecte o ejercite la ruta de conmutación por error si el diseño tiene una, porque una corrección que solo funciona mientras la instancia original del túnel está viva no se ha probado. Mantenga la prueba ligada a un origen real, un destino real y una operación real en lugar de a un indicador verde en un panel.

Registre los cuatro valores de base y el resultado. El siguiente informe del mismo síntoma podrá entonces empezar desde pruebas en lugar de desde un ping.