Pode unha soa interface WAN servir a VPN entre sedes e o acceso remoto?

Unha soa dirección pública pode atender á vez un túnel de sucursal e un pool de usuarios en mobilidade. Pero non pode atender unha soa regra de admisión compartida. O par da sucursal e o usuario en mobilidade difiren en quen din ser, como se comproba esa proba, que direccións reciben e que prefixos poden respondérlleles. Cando tratas a dirección exterior como un detalle de transporte e non como unha identidade, o deseño vólvese moito máis sinxelo.

Unha proba rápida de sensatez: intenta escribir os dous rexistros de admisión antes de tocar o router. Se unha soa condición de coincidencia ten que cubrir ambos, a política xa é ambigua, e o primeiro síntoma parecerá unha avaría de encamiñamento ou de firewall cando en realidade é unha avaría de identidade.

Dous rexistros antes de calquera configuración

O rexistro da sucursal é curto e estable. Enumera a dirección do par ou o nome do certificado, a clave precompartida ou o trustpoint do certificado, as subredes protexidas en ambos os lados, a interface do túnel e a ruta estática que envía o tráfico cara á sucursal dentro dese túnel. Cada campo trata dun par coñecido e dun conxunto fixo de prefixos.

O rexistro de mobilidade é máis amplo e máis persoal. Enumera o protocolo e o porto do cliente, como se autentica un usuario ou un dispositivo, o pool de direccións que se entrega ao conectar, os recursos que ese pool pode alcanzar, os prefixos do túnel dividido, os servidores DNS que se empuxan ao cliente e calquera segundo factor. Cada campo responde a unha pregunta sobre un número descoñecido de usuarios e non sobre unha soa pasarela.

Esa diferenza de granularidade é todo o motivo polo que os dous papeis diverxen. Un perfil de sucursal pode confiar sen risco nunha soa clave porque a clave pertence a un só dispositivo nun só sitio. Un perfil de mobilidade que confía nunha soa clave de grupo para todos afunde a responsabilidade por usuario, algo que adoita descubrirse máis tarde, durante a revisión dun incidente e non durante o despregamento.

Onde diverxen o emparellamento de pares e a autenticación

En IOS XE o perfil IKEv2 leva os parámetros que non se poden negociar e as condicións que se usan para seleccionar o par. Iso significa que o lado da sucursal e o lado de mobilidade necesitan cada un o seu propio perfil, mesmo cando terminan na mesma interface e mesmo cando comparten unha mesma PKI criptográfica. Cisco documenta os papeis do perfil, a autenticación e o emparellamento na súa guía de configuración de IKEv2 para IOS XE 17.

O perfil da sucursal adoita emparellar unha identidade estreita: unha dirección remota, un FQDN ou un suxeito de certificado. Algo como match identity remote address 198.51.100.10 255.255.255.255 fixa un só par, e authentication remote pre-share cunha clave almacenada por sitio abonda. Mantén a coincidencia tan específica como permita o inventario de pares, porque un comodín que se solape máis arriba na orde de selección pode arrastrar o tráfico da sucursal ao perfil equivocado.

O perfil de mobilidade non pode fixar unha dirección, así que empareja un grupo, un key-id ou un campo do certificado, e logo entrega a comprobación real do usuario a AAA ou á política de autorización ligada ao perfil. Esa separación importa: a autenticación do par responde se o cliente pode construír un túnel, e a autorización por usuario responde que pool e que recursos obtén. Usar a clave da sucursal como inicio de sesión universal tira a segunda resposta.

O reenvío e a tradución necesitan a mesma separación

A admisión e o alcance son problemas separados. Un intercambio correcto de IKE e IPsec demostra que as partes coinciden nas claves; non crea unha ruta cara ao pool que recibiu o cliente. Por iso os pools de acceso remoto necesitan un camiño de retorno, xa sexa unha ruta estática que apunte á interface do túnel ou un protocolo de encamiñamento que inxecte o resumo do pool. Os prefixos da sucursal adoitan chegar polo mesmo proceso de encamiñamento que serve o resto do sitio.

A tradución é onde os dous papeis chocan máis a miúdo. O tráfico entre sitios que debe conservar as súas direccións privadas necesita unha exención de NAT limitada a eses dous prefixos, en ambos os sentidos. Os clientes en mobilidade tamén adoitan necesitar a exención para o tráfico que levan polo túnel, pero o seu tráfico cara a internet ou ben evita o túnel co túnel dividido ou ben sae no concentrador despois do NAT. Eximir todo o que chega dun túnel é o erro clásico, porque tamén quita a tradución a tráfico que de verdade a necesita.

Mantén as regras de exención tan estreitas como as regras de admisión. Se un resumo de pool e un prefixo de sucursal se solapan, o camiño de retorno vólvese ambiguo moito antes de que se descarte un só paquete, e o síntoma aparece como un sitio que perde unha subrede de cando en vez e non como un fallo limpo do túnel.

Casos de aceptación que expoñen unha política cruzada

Constrúe catro casos e execútaos por orde. Un equipo da sucursal alcanza un recurso só da sucursal. Un cliente en mobilidade alcanza o mesmo recurso a través da dirección do seu pool. Un cliente en mobilidade intenta un prefixo da sucursal que non debería tocar. Un par da sucursal intenta obter unha dirección do pool de acceso remoto. Os dous últimos son os que atrapan un perfil compartido, porque fallan en silencio na monitorización normal.

Despois confirma o plano de datos e non a configuración. show crypto ikev2 sa e show crypto ipsec sa dinche que perfil e que selectores levaron cada fluxo, mentres que show ip nat translations e os contadores do túnel mostran se o camiño de retorno e a exención coincidiron de verdade. Un tracer ou unha captura de paquetes na interface do túnel pecha o bucle.

Escribe a identidade observada, a dirección do pool e a política seleccionada xunto a cada resultado. A quenda remata cando cada caso corresponde exactamente a un rexistro e ningún caso necesita unha excepción temporal para pasar.