Que VRF chega ao par de VPN e cal transporta o paquete?

Cada túnel dentro dun contexto de encamiñamento de cliente segue tendo que chegar ao seu par remoto, e esa consulta pode ocorrer nunha táboa completamente distinta. Facelo mal produce unha das fallas máis confusas en IPsec con coñecemento de VRF: o túnel levanta, as rutas parecen presentes e o tráfico morre porque unha das dúas consultas usou o contexto equivocado. Execute os catro pasos seguintes en orde e anote os dous destinos por separado.

Dúas consultas, un túnel

O paquete encapsulado exterior diríxese ao enderezo de transporte do par e encamíñase antes de que exista calquera protección. O paquete interior diríxese a un servidor do cliente e encamíñase tras a desencapsulación, dentro do contexto do cliente. Son dous destinos, dúas consultas e a miúdo dúas táboas distintas.

A documentación de Cisco para IPsec con coñecemento de VRF chámaos VRF de porta frontal e VRF interior. A porta frontal transporta o tráfico cifrado e o contexto interior transporta o tráfico protexido. Nada de poñerlle a un túnel o nome dun cliente fai aparecer ningunha das dúas rutas.

Así que enumere catro datos antes de cambiar unha configuración: o enderezo de transporte do par e o contexto que chega a el, despois o prefixo do servidor e o contexto que chega a el. Se non pode completar os catro, está a piques de adiviñar. Adiviñar nesta área é caro, porque unha ruta engadida á táboa equivocada pode facer funcionar un fluxo mentres rompe outro en silencio. Os catro datos tardan dez minutos en recollerse e aforran un día de análise de capturas.

Confirme a consulta de transporte do par

Empece pola porta frontal, porque un túnel que non pode chegar ao seu par nunca deixará pasar un só paquete protexido. En IOS, pida a ruta cara ao par dentro do VRF de transporte en lugar da táboa 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 enderezo do par é alcanzable nese contexto, o segundo enumera os VRF que existen realmente e o terceiro mostra se se formou unha asociación de seguridade. Un enderezo de par que só se resolve na táboa global é o erro clásico da porta frontal, e preséntase como unha negociación IKE que nunca comeza.

Comprobe tamén a asignación de interface. O comportamento documentado esixe que o VRF de porta frontal do túnel e o VRF da interface WAN coincidan; unha discrepancia pode deixar saír un paquete e aínda así impedir que a resposta se procese no contexto correcto.

Confirme a consulta interior do servidor

Coa porta frontal demostrada, cambie ao contexto do cliente e faga a mesma pregunta sobre o prefixo do servidor. Esta consulta decide se un paquete desencapsulado pode reenviarse máis alá.

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

O primeiro comando mostra a ruta interior, e o segundo mostra o estado da sesión xunto cos contextos que a plataforma lle asociou. Se a ruta existe pero o detalle da sesión nomea o contexto interior equivocado, o túnel está a reenviar a unha táboa que non coñece o prefixo do cliente.

Unha ruta na táboa global non é proba para ningunha das dúas consultas. As rutas globais úsanse cando un paquete non está asociado a ningún VRF, e unha interface de túnel asignada a un contexto de cliente cambia esa asociación. Se falta a ruta interior, o paquete desencapsúlase e despois descártase por falta dunha entrada de reenvío, o que parece perda de paquetes e non un erro de encamiñamento.

Coloque o axuste onde o modelo o espera

A mesma documentación distingue modelos de configuración, e un axuste que pertence a un non pertence necesariamente a outro. Nas interfaces de túnel con protección de túnel, o VRF interior defínese na interface de túnel. Nos deseños baseados en crypto map, o VRF interior forma parte da entrada de crypto map. Mover un comando de nome similar entre modelos sen comprobar a súa función é a forma en que un deseño que funciona se volve intermitente.

Encamiñamento e identidade son asuntos separados. A alcanzabilidade nunca substitúe un perfil de par que o dispositivo acepte, e un cambio de nome de VRF non debe alterar as credenciais ofrecidas. Comprobe ambas as cousas tras calquera cambio, porque un túnel que negocia co perfil equivocado aínda pode formar unha asociación e non reenviar nada.

Por último, rexistre os catro datos e os comandos que os demostraron no rexistro de cambios. O seguinte enxeñeiro herdará o túnel e non o razoamento, e unha nota breve que nomee ambos os contextos vale máis que un diagrama que ninguén actualiza.