Túneles IPsec con puntos de conexión dinámicos

El remoto (par dinámico) inicia las negociaciones con el enrutador local (Juniper Networks). El enrutador local utiliza las políticas IKE e IPsec predeterminadas para hacer coincidir las propuestas enviadas por el par remoto para negociar los valores de asociación de seguridad (SA). Las propuestas implícitas contienen una lista de todas las transformaciones admitidas que el enrutador local espera de todos los pares dinámicos.

Si se usa la autenticación de clave previamente compartida, la clave previamente compartida es global para un conjunto de servicios. Cuando se busca la clave previamente compartida para el par, el enrutador local hace coincidir la dirección de origen del par con cualquier clave previamente compartida configurada explícitamente en ese conjunto de servicios. Si no se encuentra una coincidencia, el enrutador local utiliza la clave global previamente compartida para la autenticación.

La fase 2 de la autenticación hace coincidir las identidades de proxy de los hosts y redes protegidos enviados por el par con una lista de identidades de proxy configuradas. La identidad de proxy aceptada se utiliza para crear las reglas dinámicas para cifrar el tráfico. Puede configurar identidades de proxy incluyendo la allowed-proxy-pair instrucción en el perfil de acceso de IKE. Si no coincide ninguna entrada, se rechaza la negociación.

Si no configura la allowed-proxy-pair instrucción, se aplica el valor ANY(0.0.0.0/0)-ANY predeterminado y el enrutador local acepta las identidades de proxy enviadas por el par. Se aceptan direcciones IPv4 e IPv6, pero debe configurar todas las direcciones IPv6 manualmente.

Una vez que la negociación de fase 2 se completa correctamente, el enrutador crea las reglas dinámicas e inserta la ruta inversa en la tabla de enrutamiento utilizando la identidad de proxy aceptada.

Después de una negociación correcta con el par dinámico, el proceso de administración de claves (kmd) crea una regla dinámica para el proxy de fase 2 aceptado y la aplica en el AS local o en la PIC de multiservicios. Las direcciones de origen y destino se especifican mediante el proxy aceptado. Esta regla se utiliza para cifrar el tráfico dirigido a uno de los hosts finales en la identidad de proxy de fase 2.

La regla dinámica incluye un ipsec-inside-interface valor, que es el nombre de interfaz asignado al túnel dinámico. Los source-address valores y destination-address se aceptan desde el ID de proxy. El match-direction valor es input para conjuntos de servicios de estilo de siguiente salto.

La búsqueda de reglas para túneles estáticos no se ve afectada por la presencia de una regla dinámica; Se realiza en el orden configurado. Cuando se recibe un paquete para un conjunto de servicios, las reglas estáticas siempre coinciden primero.

Las reglas dinámicas se hacen coincidir después de que se haya producido un error en la coincidencia de reglas para las reglas estáticas.

La respuesta a los mensajes de saludo de detección de pares inactivos (DPD) se produce de la misma manera con los pares dinámicos que con los pares estáticos. No se admite el inicio de mensajes de saludo DPD desde pares dinámicos.

Las rutas estáticas se insertan automáticamente en la tabla de rutas para aquellas redes y hosts protegidos por un punto de conexión de túnel remoto. Estos hosts y redes protegidos se conocen como identidades de proxy remotas.

Cada ruta se crea en función de la máscara y la red de proxy remoto enviada por el par y se inserta en la tabla de rutas pertinente después de negociaciones exitosas de fase 1 y fase 2.

La preferencia de ruta para cada ruta inversa estática es 1. Este valor es necesario para evitar conflictos con rutas similares que podría agregar el proceso de protocolo de enrutamiento (rpd).

No se agregan rutas si la dirección de proxy remoto aceptada es la predeterminada (0.0.0.0/0). En este caso, puede ejecutar protocolos de enrutamiento a través del túnel IPsec para aprender rutas y agregar rutas estáticas para el tráfico que desea proteger en este túnel.

Para los conjuntos de servicios de estilo de salto siguiente, las rutas inversas incluyen los saltos siguientes que apuntan a las ubicaciones especificadas por la inside-service-interface instrucción.

La tabla de rutas en la que se insertan estas rutas depende de dónde se muestre la inside-service-interface ubicación. Si estas interfaces están presentes en una instancia de enrutamiento y reenvío VPN (VRF), las rutas se agregan a la tabla VRF correspondiente; de lo contrario, las rutas se agregan a inet.0.

Solo puede configurar un perfil de túnel por conjunto de servicios para todos los pares dinámicos. La clave previamente compartida configurada en el perfil se utiliza para la autenticación IKE de todos los pares dinámicos que terminan en ese conjunto de servicios. Como alternativa, puede incluir la ike-policy instrucción para hacer referencia a una política de IKE que defina con valores de identificación específicos o con un comodín (la any-remote-id opción). La política de ICR se configura en el [edit services ipsec-vpn ike] nivel de jerarquía.

El perfil de túnel de IKE especifica toda la información necesaria para completar la negociación de ICR. Cada protocolo tiene su propia jerarquía de instrucciones dentro de la instrucción client para configurar pares de valores de atributo específicos del protocolo, pero solo se permite una configuración de cliente para cada perfil. A continuación se muestra la configuración en el nivel jerárquico; para obtener más información sobre los [edit access] perfiles de acceso, consulte la biblioteca de administración de Junos OS para dispositivos de enrutamiento.

Las siguientes instrucciones conforman el perfil de ICR:

• allowed-proxy-pair: durante la negociación de IKE de fase 2, el par remoto proporciona su dirección de red (remote) y la dirección de red de su par (local). Dado que varios túneles dinámicos se autentican a través del mismo mecanismo, esta instrucción debe incluir la lista de combinaciones posibles. Si el par dinámico no presenta una combinación válida, se produce un error en la negociación de IKE de fase 2.

  De forma predeterminada, remote 0.0.0.0/0 local 0.0.0.0/0 se utiliza si no se configura ningún valor. En esta configuración se admiten los formatos de dirección IPv4 e IPv6, pero no hay direcciones IPv6 predeterminadas. Debe especificar incluso 0::0/0.

• pre-shared-key: clave utilizada para autenticar el par dinámico durante la negociación de fase 1 de IKE. Esta clave es conocida por ambos extremos a través de un mecanismo seguro fuera de banda. Puede configurar el valor en o ascii-text formathexadecimal. Es un valor obligatorio.

• ike-policy—Política que define los valores de identificación remota correspondientes a los pares dinámicos permitidos; Puede contener un valor any-remote-id comodín solo para usarse en configuraciones de puntos de conexión dinámicos.

• interface-id: identificador de interfaz, atributo obligatorio que se utiliza para derivar la información de interfaz de servicios lógicos para la sesión.

• ipsec-policy: nombre de la política IPsec que define la información de política IPsec para la sesión. La política de IPsec se define en el [edit services ipsec-vpn ipsec policy policy-name] nivel de jerarquía. Si no se establece ninguna política, se acepta cualquier política propuesta por el par dinámico.

Para completar la configuración, debe hacer referencia al perfil de acceso de IKE configurado en el [edit access] nivel de jerarquía. Para ello, incluya la ike-access-profile instrucción en el nivel de [edit services service-set name ipsec-vpn-options] jerarquía:

La ike-access-profile instrucción debe hacer referencia al mismo nombre que la profile instrucción que configuró para el acceso a IKE en el nivel jerárquico [edit access] . Solo puede hacer referencia a un perfil de acceso en cada conjunto de servicios. Este perfil se utiliza para negociar asociaciones de seguridad IKE e IPsec solo con pares dinámicos.

Todas las interfaces a las que hace referencia la inside-service-interface instrucción dentro de un conjunto de servicios deben pertenecer a la misma instancia de VRF.

Puede configurar un identificador de interfaz para un grupo de pares dinámicos, el cual especifica qué interfaces lógicas de servicios adaptables participan en la negociación dinámica de IPsec. Si asigna el mismo identificador de interfaz a varias interfaces lógicas, puede crear un conjunto de interfaces para este fin. Para configurar un identificador de interfaz, incluya la ipsec-interface-id instrucción y la dedicated instrucción or shared en el nivel de [edit interfaces interface-name unit logical-unit-number dial-options] jerarquía:

Si especifica el identificador de interfaz en la instrucción, dial-options esta interfaz lógica forma parte del conjunto identificado por la ipsec-interface-id instrucción.

Si configura shared el modo, permite que una interfaz lógica se comparta en varios túneles. La dedicated instrucción especifica que la interfaz lógica se utiliza en un modo dedicado, lo cual es necesario cuando se configura un túnel de tipo vínculo IPsec. Debe incluir la dedicated instrucción cuando especifique un ipsec-interface-id valor.

El software incluye propuestas IKE e IPsec predeterminadas implícitas para que coincidan con las propuestas enviadas por los pares dinámicos. Los valores se muestran en la Tabla 1; Si se muestra más de un valor, el primer valor es el predeterminado.

A partir de la versión 16.2R1 de Junos OS, puede distribuir túneles IPsec con puntos de conexión dinámicos entre varias MS-MIC o entre varias PIC de servicio de una MS-MPC. La distribución de túneles se configura configurando un conjunto de servicios IPsec de salto siguiente para la interfaz de multiservicios (ms-) de cada PIC de servicio. A partir de Junos OS versión 17.1R1, también puede distribuir túneles IPsec con puntos de conexión dinámicos entre interfaces de multiservicios agregadas (AMS) de MS-MIC o MS-MPC configurando un conjunto de servicios IPsec de salto siguiente para cada interfaz AMS.

Más adelante puede agregar hardware de PIC de servicio al enrutador de la serie MX e incluir la PIC de servicio en la distribución del túnel simplemente agregando otro conjunto de servicios, sin necesidad de cambiar la configuración de los pares IPsec.

Para configurar la distribución de túneles, realice los pasos siguientes cuando configure túneles IPsec de punto de conexión dinámicos:

• Configure un conjunto de servicios IPsec de salto siguiente para cada interfaz de servicios o interfaz AMS utilizada por el túnel IPsec del punto de conexión dinámico (consulte Hacer referencia al perfil de acceso de IKE en un conjunto de servicios). Todos los conjuntos de servicios deben:

  • Utilice el mismo tipo de interfaz de servicios, ya sean interfaces de multiservicios (MS) o AMS (AMS).

  • Tenga una interfaz en la outside-service instrucción que se encuentre en la misma instancia de enrutamiento y reenvío VPN (VRF) que las interfaces de los otros conjuntos de servicios.

  • Tener la misma local-gateway dirección IP.

  • Tienen el mismo ike-access-profile nombre.

• Cuando configure el identificador de interfaz (consulte Configurar el identificador de interfaz), debe ipsec-interface-id identifier configurarse:

  • Solo en interfaces que aparecen en las inside-service-set instrucciones de los conjuntos de servicios.

  • Con dedicated para todas las interfaces o con shared para todas las interfaces.

  • Bajo no más de una unidad compartida de una interfaz.

  • Solo en interfaces configuradas con service-domain inside.

  • Solo en interfaces que se encuentran en el mismo VRF.