Por que as rotas de custo igual tornam as falhas de VPN difíceis de ver
Quando vários túneis partilham o mesmo custo, cada fluxo pode escolher um diferente. Um ping bem-sucedido não diz nada sobre o caminho que a sua aplicação realmente usa.
Um utilizador relata que a aplicação interna funciona a partir de uma máquina e falha a partir de outra, enquanto o ping que executa a partir da gateway é bem-sucedido em ambos os casos. Com vários túneis de custo igual, isso não é uma contradição. Cada fluxo é colocado no seu próprio próximo salto, pelo que a sua sonda e a sessão do utilizador podem simplesmente usar caminhos diferentes. A análise abaixo reproduz essa escolha antes de alterar o que quer que seja.
Um ping, vários caminhos possíveis
Quando uma rota tem mais do que um próximo salto com o mesmo custo, o router tem de escolher um por pacote. A maioria das implementações faz um hash de campos do pacote, normalmente os endereços de origem e de destino juntamente com o protocolo e as portas, para que as respostas fiquem no mesmo caminho. Aplicações diferentes, ou mesmo ligações diferentes de uma mesma aplicação, produzem hashes diferentes.
É por isso que um diagnóstico a partir da gateway prova tão pouco. A sonda da própria gateway tem os seus próprios endereços e portas e, portanto, o seu próprio hash. Pode cair no túnel saudável enquanto o utilizador continua a cair no avariado.
Como a plataforma escolhe um próximo salto
Reproduza a escolha em vez de a adivinhar. Pergunte ao núcleo que rota usaria para a mesma origem e destino que a sessão que falha. Essa consulta inclui campos que uma simples consulta de destino ignora. Execute-a também a partir de um cliente que funciona e compare as duas respostas:
ip route get 10.20.5.7 from 10.20.0.14As versões mais recentes do iproute2 também aceitam o protocolo e a porta de destino, o que importa quando o hash os inclui. Compare essa saída com a mesma consulta a partir de um cliente que funciona, e a diferença é a prova que lhe faltava.
| 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 falha, não a tabela de rotas
A tabela de rotas lista ambos os túneis e à partida parece correcta. A questão é o que cada túnel faz com o pacote depois de escolhido. Verifique que ambos transportam os mesmos prefixos protegidos, a mesma permissão de encaminhamento e um caminho de retorno que chega ao mesmo cliente.
Preste atenção aos dispositivos com estado no meio. Se um pedido sai por um túnel e a resposta regressa pelo outro, uma firewall ou um NAT que nunca viu o fluxo original irá descartá-la. Os dois túneis encaminham o tráfego correctamente, e a ligação falha mesmo assim.
Verifique também a MTU por caminho. Um caminho com uma encapsulação extra reduz o tamanho utilizável, e uma transferência que tem êxito num túnel encrava no outro exactamente no tamanho em que o mais pequeno quebra.
Compare um caminho de cada vez
Onde o desenho permitir manutenção, retire um túnel de serviço e repita a tarefa do utilizador. Se a falha desaparecer, o problema pertence ao caminho que retirou, e o passo seguinte é comparar a sua configuração com a do vizinho em vez de reexaminar a tabela de encaminhamento.
Compare a aplicação real, não pings repetidos. Registe se a falha segue um próximo salto concreto, um tamanho de pacote ou uma transição após reconexão, porque esses três padrões apontam para reparações diferentes.
Por fim, registe por que razão os caminhos são considerados equivalentes e como uma falha deve retirar um deles de serviço. O multipath só é seguro quando os caminhos são realmente permutáveis, e isso é uma afirmação de desenho que vale a pena verificar em vez de assumir.