Por qué traceroute muere en una sola dirección a través de un túnel VPN

La salida de traceroute que se completa en una dirección e imprime filas de asteriscos en la otra parece un reenvío asimétrico, y normalmente no lo es. Cada salto mostrado necesita que la sonda llegue, que un router decida responder y que la respuesta vuelva y se empareje con la sonda. Rompa cualquiera de esos eslabones y la fila se convierte en un asterisco mientras el túnel sigue transportando datos.

El rastro es evidencia sobre el diagnóstico antes que evidencia sobre el transporte. La pregunta que vale la pena hacerse es cuál de los tres eslabones falló, y la respuesta viene de los paquetes, no de la forma de la salida.

Un asterisco es una respuesta que falta, no un salto que falta

Traceroute avanza hacia fuera enviando sondas cuyo TTL expira un router más allá en cada ronda. Un router que descarta una sonda expirada debería devolver un mensaje ICMP Time Exceeded que se nombre a sí mismo, y la herramienta imprime ese nombre. Lo que la herramienta espera en realidad es que ese mensaje llegue dentro de un tiempo de espera. Si el router responde desde otra dirección de origen, limita la frecuencia con que genera errores o descarta la sonda sin decir nada, la ronda no produce nada imprimible.

Ninguno de esos resultados dice que la ruta de ida esté rota. Un asterisco es un informe sobre correo sin respuesta, no sobre un camino vacío.

El método de la sonda decide con qué filtro se encuentra

El método predeterminado en Linux suele ser un puerto de destino UDP con un número alto, tracert de Windows envía ecos ICMP, y a Linux se le puede indicar que use ICMP o TCP en su lugar. Cada uno parece un tipo distinto de tráfico para un cortafuegos con estado o un grupo de seguridad de la nube. Comparar un rastro UDP de un lado con un rastro ICMP del otro compara dos experimentos distintos. Fije el método, la familia de direcciones, la dirección de origen y el tiempo de espera antes de llamar diferencia a los resultados.

Para una comparación justa, ejecute el rastro desde los equipos que realmente transportan el tráfico y no desde una puerta de enlace que reenvía en su nombre. Un rastro generado por el router usa su propia dirección de origen y su política de salida, que pueden ser más estrictas que cualquier cosa que vea un cliente. Anote la invocación exacta para que la siguiente persona pueda repetirla.

El valor del tiempo de espera es la otra mitad del experimento, y es fácil dejarlo fuera de las notas. Una espera de dos segundos en un camino congestionado informa de asteriscos donde una espera de cinco segundos informa de saltos. Mantenga el valor idéntico entre ejecuciones para que la comparación siga siendo sobre la red.

La ruta de vuelta es una ruta propia

Un error ICMP es un paquete ordinario con su propio origen y destino, y necesita una ruta de vuelta hacia el rastreador. Si la política del túnel lleva los prefijos de la LAN pero no la dirección del router que generó el error, el mensaje sale por un camino que no puede alcanzarle. El filtrado de respuestas puede descartarlo incluso cuando la ruta existe, porque el paquete llega desde una dirección inesperada en una interfaz inesperada. Eso es un desajuste en el plano de diagnóstico y no un fallo de la aplicación.

Ampliar cada selector hasta que el rastro se complete hace la imagen más bonita y la política peor. Repare la dirección de diagnóstico concreta, o acepte el asterisco y pruebe la aplicación de otra manera.

Confirme el túnel con una petición real

Un handshake TCP en el puerto propio del servicio ejercita el reenvío, el enrutamiento de vuelta y el filtrado en la dirección que importa. Los comandos siguientes se ejecutan en ambos extremos y comparan qué puede abrir cada lado. Sustituya el puerto del servicio y el nombre de la interfaz del túnel por los de su propia configuración.

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

Lea primero las dos ejecuciones de traceroute: si la ejecución ICMP muestra saltos y la TCP no, la diferencia es de método, no de camino. Luego tome el resultado de curl como la respuesta a nivel de aplicación, porque un intercambio completado con un código de estado razonable significa que las rutas de ida y de vuelta funcionan para tráfico real. El listado de sockets muestra si la conexión está establecida, algo que ningún rastro puede decirle.

Un túnel que transporta una sesión interactiva en ambas direcciones mientras un traceroute imprime asteriscos está sano y es simplemente poco fotogénico. Guarde la salida de los comandos de cada lado como registro y trate los saltos que faltan como una pregunta abierta sobre el diagnóstico y no como un veredicto sobre la VPN.