¿Puede una sola interfaz WAN servir la VPN entre sedes y el acceso remoto?

Una sola dirección pública puede atender a la vez un túnel de sucursal y un grupo de usuarios en movilidad. Pero no puede atender una sola regla de admisión compartida. El par de la sucursal y el usuario en movilidad difieren en quiénes dicen ser, cómo se comprueba esa prueba, qué direcciones reciben y qué prefijos pueden responderles. Cuando tratas la dirección exterior como un detalle de transporte y no como una identidad, el diseño se vuelve mucho más sencillo.

Una prueba rápida de sensatez: intenta escribir los dos registros de admisión antes de tocar el router. Si una sola condición de coincidencia tiene que cubrir ambos, la política ya es ambigua, y el primer síntoma parecerá una avería de enrutamiento o de cortafuegos cuando en realidad es una avería de identidad.

Dos registros antes de cualquier configuración

El registro de la sucursal es corto y estable. Enumera la dirección del par o el nombre del certificado, la clave precompartida o el trustpoint del certificado, las subredes protegidas en ambos lados, la interfaz del túnel y la ruta estática que envía el tráfico hacia la sucursal dentro de ese túnel. Cada campo trata de un par conocido y de un conjunto fijo de prefijos.

El registro de movilidad es más amplio y más personal. Enumera el protocolo y el puerto del cliente, cómo se autentica un usuario o un dispositivo, el grupo de direcciones que se entrega al conectar, los recursos que ese grupo puede alcanzar, los prefijos del túnel dividido, los servidores DNS que se empujan al cliente y cualquier segundo factor. Cada campo responde a una pregunta sobre un número desconocido de usuarios y no sobre una sola puerta de enlace.

Esa diferencia de granularidad es todo el motivo por el que los dos papeles divergen. Un perfil de sucursal puede confiar sin riesgo en una sola clave porque la clave pertenece a un solo dispositivo en un solo sitio. Un perfil de movilidad que confía en una sola clave de grupo para todos hunde la responsabilidad por usuario, algo que suele descubrirse más tarde, durante la revisión de un incidente y no durante el despliegue.

Dónde divergen el emparejamiento de pares y la autenticación

En IOS XE el perfil IKEv2 lleva los parámetros que no se pueden negociar y las condiciones que se usan para seleccionar el par. Eso significa que el lado de la sucursal y el lado de movilidad necesitan cada uno su propio perfil, incluso cuando terminan en la misma interfaz e incluso cuando comparten una misma PKI criptográfica. Cisco documenta los papeles del perfil, la autenticación y el emparejamiento en su guía de configuración de IKEv2 para IOS XE 17.

El perfil de la sucursal suele emparejar una identidad estrecha: una dirección remota, un FQDN o un sujeto de certificado. Algo como match identity remote address 198.51.100.10 255.255.255.255 fija un solo par, y authentication remote pre-share con una clave almacenada por sitio basta. Mantén la coincidencia tan específica como permita el inventario de pares, porque un comodín que se solape más arriba en el orden de selección puede arrastrar el tráfico de la sucursal al perfil equivocado.

El perfil de movilidad no puede fijar una dirección, así que empareja un grupo, un key-id o un campo del certificado, y luego entrega la comprobación real del usuario a AAA o a la política de autorización ligada al perfil. Esa separación importa: la autenticación del par responde si el cliente puede construir un túnel, y la autorización por usuario responde qué grupo y qué recursos obtiene. Usar la clave de la sucursal como inicio de sesión universal tira la segunda respuesta.

El reenvío y la traducción necesitan la misma separación

La admisión y el alcance son problemas separados. Un intercambio correcto de IKE e IPsec demuestra que las partes coinciden en las claves; no crea una ruta hacia el grupo que recibió el cliente. Por eso los grupos de acceso remoto necesitan un camino de retorno, ya sea una ruta estática que apunte a la interfaz del túnel o un protocolo de enrutamiento que inyecte el resumen del grupo. Los prefijos de la sucursal suelen llegar por el mismo proceso de enrutamiento que sirve al resto del sitio.

La traducción es donde los dos papeles chocan más a menudo. El tráfico entre sitios que debe conservar sus direcciones privadas necesita una exención de NAT limitada a esos dos prefijos, en ambos sentidos. Los clientes en movilidad también suelen necesitar la exención para el tráfico que llevan por el túnel, pero su tráfico hacia internet o bien evita el túnel con el túnel dividido o bien sale en el concentrador después del NAT. Eximir todo lo que llega de un túnel es el error clásico, porque también quita la traducción a tráfico que de verdad la necesita.

Mantén las reglas de exención tan estrechas como las reglas de admisión. Si un resumen de grupo y un prefijo de sucursal se solapan, el camino de retorno se vuelve ambiguo mucho antes de que se descarte un solo paquete, y el síntoma aparece como un sitio que pierde una subred de vez en cuando y no como un fallo limpio del túnel.

Casos de aceptación que exponen una política cruzada

Construye cuatro casos y ejecútalos en orden. Un equipo de la sucursal alcanza un recurso solo de la sucursal. Un cliente en movilidad alcanza el mismo recurso a través de la dirección de su grupo. Un cliente en movilidad intenta un prefijo de la sucursal que no debería tocar. Un par de la sucursal intenta obtener una dirección del grupo de acceso remoto. Los dos últimos son los que atrapan un perfil compartido, porque fallan en silencio en la monitorización normal.

Después confirma el plano de datos y no la configuración. show crypto ikev2 sa y show crypto ipsec sa te dicen qué perfil y qué selectores llevaron cada flujo, mientras que show ip nat translations y los contadores del túnel muestran si el camino de retorno y la exención coincidieron de verdad. Un tracer o una captura de paquetes en la interfaz del túnel cierra el bucle.

Escribe la identidad observada, la dirección del grupo y la política seleccionada junto a cada resultado. La tanda termina cuando cada caso corresponde exactamente a un registro y ningún caso necesita una excepción temporal para pasar.