Por que as rutas de igual custo fan difíciles de ver as fallas de VPN
Cando varios túneles comparten un custo, cada fluxo pode tomar un distinto. Un ping correcto non di nada sobre o camiño que usa realmente a súa aplicación.
Un usuario informa de que a aplicación interna funciona desde unha máquina e falla desde outra, e de que o ping que executa desde a pasarela ten éxito en ambos os casos. Con varios túneles de igual custo, iso non é unha contradición. Cada fluxo colócase no seu propio seguinte salto, así que a súa sonda e a sesión do usuario poden simplemente usar camiños distintos. O percorrido seguinte reproduce esa elección antes de cambiar nada.
Un ping, varios camiños posibles
Cando unha ruta ten máis dun seguinte salto co mesmo custo, o encamiñador debe escoller un por paquete. A maioría das implementacións aplican un hash a campos do paquete, normalmente os enderezos de orixe e destino xunto co protocolo e os portos, para que as respostas queden no mesmo camiño. Aplicacións distintas, ou mesmo conexións distintas dunha mesma aplicación, producen hashes distintos.
Por iso un diagnóstico desde a pasarela demostra tan pouco. A sonda da propia pasarela ten os seus enderezos e portos, e por tanto o seu propio hash. Pode caer no túnel san mentres o usuario segue caendo no roto.
Como escolle a plataforma un seguinte salto
Reproduza a elección en lugar de adiviñala. Pregunte ao núcleo que ruta usaría para a mesma orixe e destino que a sesión que falla. Esa consulta inclúe campos que unha consulta simple de destino ignora. Execútea tamén desde un cliente que funciona e compare as dúas respostas:
ip route get 10.20.5.7 from 10.20.0.14As versións máis recentes de iproute2 tamén aceptan o protocolo e o porto de destino, o que importa cando o hash os inclúe. Compare esa saída coa mesma consulta desde un cliente que funciona, e a diferenza é a proba que lle 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 o fluxo que falla, non a táboa de rutas
A táboa de rutas lista ambos os túneles e por definición parece correcta. A pregunta é que fai cada túnel co paquete unha vez elixido. Verifique que ambos levan os mesmos prefixos protexidos, o mesmo permiso de reenvío e un camiño de volta que chega ao mesmo cliente.
Fíxese nos dispositivos con estado polo medio. Se unha petición sae por un túnel e a resposta volve polo outro, unha devasa ou un NAT que nunca viu o fluxo orixinal descartaraa. Os dous túneles reenvían o tráfico correctamente e a conexión segue fallando.
Comprobe tamén a MTU por camiño. Un camiño cunha encapsulación extra reduce o tamaño útil, e unha transferencia que ten éxito por un túnel atasca polo outro exactamente no tamaño onde se rompe o máis pequeno.
Compare un camiño cada vez
Onde o deseño permita mantemento, saque un túnel de servizo e repita a tarefa do usuario. Se a falla desaparece, o problema é do camiño que retirou, e o seguinte paso é comparar a súa configuración coa do veciño en lugar de volver examinar a táboa de encamiñamento.
Compare a aplicación real, non pings repetidos. Anote se a falla segue un seguinte salto concreto, un tamaño de paquete ou unha transición tras reconectar, porque eses tres patróns apuntan a reparacións distintas.
Por último, anote por que os camiños se consideran equivalentes e como debería unha falla sacar un de servizo. O multipath só é seguro cando os camiños son realmente intercambiables, e iso é unha afirmación de deseño que convén comprobar en lugar de supoñer.