Por qué las rutas de igual coste hacen difíciles de ver las fallas de VPN
Cuando varios túneles comparten un coste, cada flujo puede tomar uno distinto. Un ping correcto no dice nada sobre el camino que usa realmente su aplicación.
Un usuario informa de que la aplicación interna funciona desde una máquina y falla desde otra, y de que el ping que ejecuta desde la puerta de enlace tiene éxito en ambos casos. Con varios túneles de igual coste, eso no es una contradicción. Cada flujo se coloca en su propio siguiente salto, así que su sonda y la sesión del usuario pueden simplemente usar caminos distintos. El recorrido siguiente reproduce esa elección antes de cambiar nada.
Un ping, varios caminos posibles
Cuando una ruta tiene más de un siguiente salto al mismo coste, el enrutador debe elegir uno por paquete. La mayoría de las implementaciones aplican un hash a campos del paquete, normalmente las direcciones de origen y destino junto con el protocolo y los puertos, para que las respuestas se queden en el mismo camino. Aplicaciones distintas, o incluso conexiones distintas de una misma aplicación, producen hashes distintos.
Por eso un diagnóstico desde la puerta de enlace demuestra tan poco. La sonda de la propia puerta de enlace tiene sus direcciones y puertos, y por tanto su propio hash. Puede caer en el túnel sano mientras el usuario sigue cayendo en el roto.
Cómo elige la plataforma un siguiente salto
Reproduzca la elección en lugar de adivinarla. Pregunte al núcleo qué ruta usaría para el mismo origen y destino que la sesión que falla. Esa consulta incluye campos que una consulta simple de destino ignora. Ejecútela también desde un cliente que funciona y compare las dos respuestas:
ip route get 10.20.5.7 from 10.20.0.14Las versiones más recientes de iproute2 también aceptan el protocolo y el puerto de destino, lo que importa cuando el hash los incluye. Compare esa salida con la misma consulta desde un cliente que funciona, y la diferencia es la prueba que le faltaba.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Siga el flujo que falla, no la tabla de rutas
La tabla de rutas lista ambos túneles y por definición parece correcta. La pregunta es qué hace cada túnel con el paquete una vez elegido. Verifique que ambos llevan los mismos prefijos protegidos, el mismo permiso de reenvío y un camino de vuelta que llega al mismo cliente.
Fíjese en los dispositivos con estado por el medio. Si una petición sale por un túnel y la respuesta vuelve por el otro, un cortafuegos o un NAT que nunca vio el flujo original la descartará. Los dos túneles reenvían el tráfico correctamente y la conexión sigue fallando.
Compruebe también la MTU por camino. Un camino con una encapsulación extra reduce el tamaño útil, y una transferencia que tiene éxito por un túnel se atasca por el otro exactamente en el tamaño donde se rompe el más pequeño.
Compare un camino cada vez
Donde el diseño permita mantenimiento, saque un túnel de servicio y repita la tarea del usuario. Si la falla desaparece, el problema es del camino que retiró, y el siguiente paso es comparar su configuración con la del vecino en lugar de volver a examinar la tabla de enrutamiento.
Compare la aplicación real, no pings repetidos. Anote si la falla sigue un siguiente salto concreto, un tamaño de paquete o una transición tras reconectar, porque esos tres patrones apuntan a reparaciones distintas.
Por último, anote por qué los caminos se consideran equivalentes y cómo debería una falla sacar uno de servicio. El multipath solo es seguro cuando los caminos son realmente intercambiables, y eso es una afirmación de diseño que conviene comprobar en lugar de suponer.