Uma rota padrão de VPN na tabela 200 esconde sua rota LAN

Quatro verificações separam uma falha da tabela de políticas de uma falha de roteamento: qual regra correspondeu, qual tabela essa regra nomeou, o que essa tabela contém e qual rota dentro dela venceu. A tabela principal não é mais consultada assim que uma tabela anterior produz uma rota, então uma entrada LAN visível ali pode ser irrelevante para o pacote que você testa. Faça as verificações em ordem, e a rota ausente aparece no terceiro passo, não no quarto.

A correspondência do prefixo mais longo acontece dentro de uma única tabela; ela não compara as rotas de todas as tabelas como uma lista única.

A consulta termina na primeira tabela que responde

Pegue uma política em que o tráfego de uma sub-rede consulta primeiro a tabela 200, a tabela 200 contém uma rota padrão pelo túnel e a tabela principal contém o prefixo LAN. Um pacote para um endereço LAN pode corresponder a essa rota padrão na tabela 200 e parar ali. Como a consulta produziu uma rota, a regra posterior da tabela principal nunca tem a chance de oferecer sua entrada mais específica. O resultado é um pacote que entra no túnel enquanto uma rota LAN perfeitamente boa fica sem uso.

As regras anteriores e a própria consulta de endereços locais da máquina continuam valendo, então o teste deve usar a origem, a marca e a interface que o fluxo real carrega. Consulte com qualquer outra coisa e a LAN pode ser selecionada corretamente, o que esconde justamente a falha que você procura.

Coloque a exceção LAN onde ela pertence

A tabela escolhida pode carregar as rotas LAN, conectadas e de endpoint de que precisa, o que mantém a política autossuficiente. Outro desenho usa uma regra anterior explícita para o prefixo LAN, ou uma rota de descarte deliberada que entrega um prefixo a uma consulta posterior. Cada um é um padrão legítimo com um dono diferente. Escolha pela política pretendida e por quem mantém as rotas, não por qual é mais curta de digitar.

Seja qual for o padrão, a exceção deve ser visível onde a política é definida. Uma rota adicionada à mão e não registrada desaparecerá no próximo reinício e levará o diagnóstico junto.

Não copie a tabela principal inteira

Copiar cada rota da principal para a tabela de políticas parece uma correção e cria um instantâneo. Um administrador pode adicionar ou remover endereços e interfaces dinamicamente, e a cópia fica obsoleta sem que ninguém perceba. Mantenha o ciclo de vida das rotas com seu dono de configuração e regenere a tabela a partir da configuração, não de um momento no tempo.

Uma tabela copiada também frustra o propósito, porque reproduz o comportamento de reserva que a política deveria restringir.

Verifique as respostas separadamente das rotas

Depois que a consulta seleciona o caminho desejado, as respostas ainda podem falhar por motivos que nada têm a ver com a tabela. A tradução pode ser aplicada na interface errada, a validação de caminho reverso pode rejeitar um pacote que chegou por um caminho inesperado, ou o endpoint pode simplesmente não responder. São falhas distintas com evidências distintas, e nenhuma delas é corrigida editando entradas de rota.

Guarde a consulta para esse fluxo exato nos dois lados da mudança, para que a correção permaneça visível. Desativar as verificações de caminho reverso globalmente ou limpar regras não fornece nenhuma rota ausente e enfraquece controles não relacionados.

Anote a regra, a tabela, a rota vencedora e o caminho da resposta. Esse registro separa um erro de política de um serviço quebrado.