Quando as rotas do túnel dividido se sobrepõem: qual prefixo ganha

Dois perfis de tunelamento dividido, dois prefixos privados e um host que ambos reivindicam. O sintoma raramente é uma falha limpa: um serviço funciona na segunda-feira, expira depois que o segundo cliente se reconecta e volta a funcionar após reiniciar. A ordem em que você conectou os clientes não decide o resultado, nem a ordem das linhas na interface do cliente. Execute estas verificações em ordem e pare na primeira que não se sustentar, porque as seguintes só fazem sentido quando as anteriores são verdadeiras.

1. Anote o destino e a origem

Comece pelo endereço exato para onde vai a requisição que falha, não pelo nome do host e não pelo nome da aplicação. Resolva o nome uma vez, anote cada resposta e escolha a que o fluxo que falha realmente usa. Depois anote o endereço local do mesmo fluxo, porque o endereço de origem pode mudar qual regra de política corresponde e, portanto, qual tabela é consultada.

Uma requisição para um de vários registros A pode falhar enquanto um endereço irmão tem sucesso, o que parece um túnel instável e na verdade são dois caminhos diferentes. Se o destino é um nome com várias respostas, teste cada resposta separadamente antes de mudar qualquer coisa.

2. Pergunte ao núcleo qual rota ele escolheu

Não leia a tabela de rotas e deduza a resposta. Faça a mesma pergunta que a pilha faz, com o mesmo endereço de origem: ip route get 10.20.4.10 from 10.8.0.2 no Linux, ou Find-NetRoute -RemoteIPAddress 10.20.4.10 no PowerShell. A saída nomeia a rota que realmente seria usada, e muitas vezes não é a que você esperava ao ler a tabela.

Entre as rotas que correspondem, normalmente ganha o prefixo mais específico: um /24 vence um /16 para um endereço dentro dos dois. Entre correspondências de mesmo comprimento ganha a métrica mais baixa, e uma rota instalada em um link que está fora é ignorada. Dois túneis que anunciam o mesmo /24 com a mesma métrica são outro caso: o núcleo mantém as duas rotas e escolhe entre elas, então o resultado pode alternar em vez de seguir a ordem em que os clientes se conectaram. É exatamente essa situação que produz o padrão de segunda-feira funciona e terça-feira falha, e reconectar em outra ordem não muda isso.

3. Verifique se uma regra de política redirecionou a consulta

Antes de a tabela de rotas ser consultada, o núcleo percorre suas regras de política. Uma regra pode enviar tráfego de uma origem, usuário ou marca de firewall específicos para uma tabela completamente diferente, então o prefixo vencedor na tabela principal pode nunca ser consultado para esse fluxo. ip rule show as lista em ordem de avaliação, e ip route show table 100 mostra o que a tabela selecionada realmente contém.

Aqui existem duas armadilhas. Uma regra que aponta para uma tabela vazia produz uma consulta que cai para a regra seguinte, então a regra parece não fazer nada. A outra é o próprio número de prioridade: as regras são lidas em ordem crescente, e os valores embutidos são 0 local, 32766 main e 32767 default. Uma regra com número abaixo de 32767 é consultada antes da regra padrão que captura tudo. Uma regra com número acima de 32767 fica atrás dela e só é alcançada quando nenhuma tabela anterior responde, o que uma rota padrão normal em main impede, portanto na prática nunca é alcançada e silenciosamente não faz nada enquanto parece instalada. Se o cliente escreveu uma regra e uma rota, verifique as duas, e verifique-as de novo após uma reconexão, porque um perfil reescrito pode adicionar uma segunda regra com prioridade diferente.

4. Separe um empate de roteamento de um plano de endereços duplicado

Às vezes o prefixo não é o problema de forma alguma. Dois sites que usam ambos 192.168.1.0/24 significam que o mesmo endereço identifica dois hosts diferentes, e nenhuma rota pode distingui-los. Uma rota de host para uma das duas respostas só funciona até o outro site responder pelo mesmo nome, e então a exceção se torna silenciosamente o próprio defeito.

A pista é que o endereço de destino é idêntico nos dois caminhos e só o proprietário pretendido difere. Isso é uma decisão de plano de endereços, não um ajuste de roteamento: renumere um lado, coloque um lado atrás de um gateway que traduz, ou alcance o segundo site através de um proxy que resolve os próprios nomes. Baixar uma rota padrão ou empilhar exceções de host apenas desloca a colisão.

5. Confirme que o resolvedor concorda com a rota

Um nome que se resolve para o endereço privado errado produz todos os sintomas de um conflito de roteamento e nenhuma das suas causas. Compare a resposta que o host recebe com o endereço que o destino realmente usa, e verifique qual resolvedor respondeu. Se o túnel empurra um resolvedor, o cliente deveria instalá-lo para os fluxos que usam o túnel; se não, o host continua perguntando ao resolvedor local, que pode responder a partir de um domínio de busca ou de um registro em cache.

Consulte o resolvedor diretamente e anote o servidor que respondeu. Uma resposta em cache com TTL curto também pode explicar por que a primeira requisição após uma reconexão se comporta de forma diferente da quinta.

6. Reconecte, inspecione o estado aplicado e então teste os dois fluxos

Após uma correção, reconecte e inspecione o que o cliente realmente instalou em vez de confiar no editor de perfis. Leia novamente as regras, as tabelas e a resposta de ip route get resultante. Um segundo cliente pode reinstalar a própria rota ao conectar e recriar o conflito, e é por isso que a verificação de estado deve ocorrer depois que o último cliente se conecta, não antes.

Teste dois fluxos, não um: a requisição que antes falhava e um recurso que deveria usar o outro túnel. Mover todo o tráfego privado para uma única conexão fará o primeiro teste passar enquanto quebra o segundo, e só um teste emparelhado detecta isso. Anote cada exceção que mantiver, com o destino e o motivo, para que a próxima pessoa consiga distinguir uma rota de host deliberada de uma remanescente.