Qual VRF alcança o par de VPN e qual transporta o pacote?

Cada túnel dentro de um contexto de roteamento de cliente ainda precisa alcançar seu par remoto, e essa consulta pode ocorrer em uma tabela completamente diferente. Errar aqui produz uma das falhas mais confusas em IPsec ciente de VRF: o túnel sobe, as rotas parecem presentes e o tráfego morre porque uma das duas consultas usou o contexto errado. Execute os quatro passos abaixo em ordem e anote os dois destinos separadamente.

Duas consultas, um túnel

O pacote encapsulado externo é endereçado ao endereço de transporte do par e é roteado antes que exista qualquer proteção. O pacote interno é endereçado a um servidor do cliente e é roteado após a desencapsulação, dentro do contexto do cliente. São dois destinos, duas consultas e frequentemente duas tabelas diferentes.

A documentação da Cisco para IPsec ciente de VRF os chama de VRF da porta da frente e VRF interno. A porta da frente transporta o tráfego cifrado, e o contexto interno transporta o tráfego protegido. Nada em dar a um túnel o nome de um cliente faz qualquer das duas rotas aparecer.

Portanto, liste quatro fatos antes de alterar uma configuração: o endereço de transporte do par e o contexto que chega até ele, depois o prefixo do servidor e o contexto que chega até ele. Se não conseguir preencher os quatro, você está prestes a adivinhar. Adivinhar nessa área é caro, porque uma rota adicionada à tabela errada pode fazer um fluxo funcionar enquanto quebra outro silenciosamente. Os quatro fatos levam dez minutos para serem coletados e economizam um dia de análise de capturas.

Confirme a consulta de transporte do par

Comece pela porta da frente, porque um túnel que não alcança seu par nunca deixará passar um único pacote protegido. No IOS, peça a rota até o par dentro do VRF de transporte em vez da tabela global.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

O primeiro comando responde se o endereço do par é alcançável naquele contexto, o segundo lista os VRF que realmente existem e o terceiro mostra se uma associação de segurança foi formada. Um endereço de par que só se resolve na tabela global é o erro clássico da porta da frente, e se apresenta como uma negociação IKE que nunca começa.

Verifique também a atribuição de interface. O comportamento documentado exige que o VRF da porta da frente do túnel e o VRF da interface WAN concordem; uma divergência pode deixar um pacote sair e ainda assim impedir que a resposta seja processada no contexto correto.

Confirme a consulta interna do servidor

Com a porta da frente comprovada, mude para o contexto do cliente e faça a mesma pergunta sobre o prefixo do servidor. Essa consulta decide se um pacote desencapsulado pode ser encaminhado adiante.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

O primeiro comando mostra a rota interna, e o segundo mostra o estado da sessão junto com os contextos que a plataforma associou a ela. Se a rota existe mas o detalhe da sessão nomeia o contexto interno errado, o túnel está encaminhando para uma tabela que não conhece o prefixo do cliente.

Uma rota na tabela global não é prova para nenhuma das duas consultas. Rotas globais são usadas quando um pacote não está associado a um VRF, e uma interface de túnel atribuída a um contexto de cliente muda essa associação. Se falta a rota interna, o pacote é desencapsulado e depois descartado por falta de entrada de encaminhamento, o que parece perda de pacotes e não um erro de roteamento.

Coloque a configuração onde o modelo a espera

A mesma documentação distingue modelos de configuração, e uma configuração que pertence a um não pertence necessariamente ao outro. Em interfaces de túnel com proteção de túnel, o VRF interno é definido na interface de túnel. Em projetos baseados em crypto map, o VRF interno faz parte da entrada de crypto map. Mover um comando de nome semelhante entre modelos sem verificar sua função é a forma como um projeto que funciona se torna intermitente.

Roteamento e identidade são questões separadas. A alcançabilidade nunca substitui um perfil de par que o dispositivo aceitará, e uma renomeação de VRF não deve alterar as credenciais oferecidas. Verifique ambos após qualquer alteração, porque um túnel que negocia com o perfil errado ainda pode formar uma associação e não encaminhar nada.

Por fim, registre os quatro fatos e os comandos que os comprovaram no registro de mudanças. O próximo engenheiro herdará o túnel e não o raciocínio, e uma nota curta que nomeie os dois contextos vale mais do que um diagrama que ninguém atualiza.