Qué interfaz recibe los roles NAT de dentro y de fuera en una salida VPN de IOS

Los routers que ofrecen una salida a Internet de túnel completo hacen dos tareas que parecen una. Terminan el túnel y reenvían el paquete de cliente descifrado hacia Internet. Solo la segunda tarea necesita traducción, y la traducción debe coincidir con el flujo interno. Esa distinción decide qué interfaces llevan los roles de NAT y qué rango de direcciones aparece en la regla.

Siga un paquete a través del router

Tome un cliente en 10.90.0.25 que abre un servicio HTTPS público. Si ese destino entra o no en el túnel es una decisión de la política del propio cliente. Una vez entra, el router descifra el paquete y lo entrega a una interfaz virtual, desde donde se enruta hacia el enlace ascendente público.

Esa interfaz virtual es el lado interno de la traducción. El enlace ascendente público es el lado externo. Si los roles se invierten o faltan, el paquete o sale con una fuente privada o se descarta antes de traducirse.

Ajuste la política de traducción al grupo de clientes

La regla de NAT debe nombrar el rango que los clientes reciben realmente, no la LAN de la oficina que casualmente comparte el mismo enlace ascendente. Una regla que cubre solo la subred local deja fuera a los clientes remotos incluso cuando ambos salen por la misma interfaz.

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

Mantenga aparte las excepciones de sitios privados. El tráfico hacia destinos internos debe conservar su origen original, o el destino responderá a una dirección que no puede alcanzar y el tramo de vuelta fallará de un modo que parece un bucle de enrutamiento.

Aplique los roles a las interfaces reales del diseño desplegado. Un fragmento de Virtual-Template copiado de una respuesta antigua de Easy VPN no es una configuración actual completa, y el tipo de túnel empleado determina qué interfaz recibe el paquete descifrado.

Separe el transporte exterior de la traducción interna

Traducir un origen de aplicación descifrado no es la misma operación que empujar IKE o paquetes protegidos a través de un dispositivo NAT más arriba. La primera cambia lo que Internet ve como origen de la petición del cliente; la segunda mantiene vivo un túnel a través de un elemento intermedio.

Confundirlas produce dos fallos clásicos. Un router que traduce su propio transporte de túnel rompe la relación con el par, mientras que un router que nunca traduce el flujo interno reenvía direcciones privadas a Internet. Lea qué flujo está mirando antes de editar una regla, y compruebe si el túnel siguió levantado tras el cambio. Una regla que arregla la navegación pero tumba el túnel ha movido el problema en lugar de resolverlo.

Ninguno de los dos fallos se corrige cambiando el otro. Lea qué flujo está mirando antes de editar una regla.

Verifique en ambas fronteras

Lea el origen de la aplicación en la frontera de Internet, y el destino restaurado en el tramo de vuelta. La primera dice si hubo traducción; la segunda dice si el mapeo inverso volvió al cliente correcto.

Después pruebe un cliente que use una ruta de túnel dividido aprobada. Ese cliente nunca ejerce la traducción de Internet de este router, así que debería comportarse distinto, y la diferencia confirma qué ruta tomó el tráfico.

Si ambos clientes se comportan igual, la política de túnel dividido no hace lo que dice el diseño. Corríjalo antes de añadir más reglas de traducción, porque una regla escrita para una ruta que no se usa esconde el problema real.