Túneles IPsec con extremos dinámicos

El par remoto (dinámico) inicia las negociaciones con el enrutador local (Juniper Networks). El enrutador local utiliza las directivas 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 compara 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 compara las identidades de proxy de los hosts protegidos y las redes enviadas 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 cualquier identidad de proxy enviada 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 multiservicio. 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 del próximo 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 emparejan después de que falle la coincidencia de reglas para reglas estáticas.

La respuesta a los mensajes de saludo de detección de pares muertos (DPD) se realiza de la misma manera con pares dinámicos que con 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 extremo de túnel remoto. Estos hosts y redes protegidos se conocen como identidades de proxy remoto.

Cada ruta se crea en función de la red proxy remota y la máscara enviada por el par y se inserta en la tabla de rutas correspondiente 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 proxy remota aceptada es la predeterminada (0.0.0.0/0). En este caso, puede ejecutar protocolos de enrutamiento en el túnel IPsec para aprender rutas y agregar rutas estáticas para el tráfico que desea proteger a través de este túnel.

Para los conjuntos de servicios de estilo del 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 insertar estas rutas depende de dónde aparezca 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 IKE se configura en el nivel jerárquico [edit services ipsec-vpn ike] .

El perfil de túnel de IKE especifica toda la información necesaria para completar la negociación de IKE. 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. La siguiente es la configuración en el nivel de [edit access] jerarquía; para obtener más información sobre los perfiles de acceso, consulte la Biblioteca de administración de Junos OS para dispositivos de enrutamiento.

Las siguientes instrucciones conforman el perfil de IKE:

• 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 se autentican varios túneles dinámicos mediante el 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 del IKE de fase 2.

  De forma predeterminada, remote 0.0.0.0/0 local 0.0.0.0/0 se utiliza si no se configuran valores. 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 de seguridad fuera de banda. Puede configurar el valor en hexadecimal formato o ascii-text en formato. 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 para su uso solo en configuraciones de punto de conexión dinámico.

• interface-id—Identificador de interfaz, atributo obligatorio que se utiliza para derivar la información de la 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 directiva IPsec se define en el nivel jerárquico [edit services ipsec-vpn ipsec policy policy-name] . 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 nivel de [edit access] jerarquía. Para ello, incluya la ike-access-profile instrucción en el nivel jerárquico [edit services service-set name ipsec-vpn-options] :

La ike-access-profile instrucción debe hacer referencia al mismo nombre que la profile instrucción configurada para el acceso 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 de 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, que especifica qué interfaces lógicas de servicios adaptables participan en la negociación de IPsec dinámico. Al asignar el mismo identificador de interfaz a varias interfaces lógicas, puede crear un grupo de interfaces para este propósito. 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 se especifica el identificador de interfaz en la dial-options instrucción, esta interfaz lógica forma parte del grupo identificado por la ipsec-interface-id instrucción.

Si configura shared el modo, permite compartir una interfaz lógica a través de 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 valor predeterminado.

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

Posteriormente, puede agregar hardware PIC de servicio al enrutador de la serie MX e incluir el 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 al configurar túneles IPsec de punto de conexión dinámico:

• Configure un conjunto de servicios IPsec del próximo salto para cada interfaz de servicios o interfaz AMS utilizada por el túnel IPsec de punto de conexión dinámico (consulte 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: interfaces multiservicios (ms-) o interfaces AMS (ams-).

  • Tener una interfaz en la outside-service instrucción que esté 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.

  • Tener el mismo ike-access-profile nombre.

• Al configurar el identificador de interfaz (consulte Configuración del identificador de interfaz), se ipsec-interface-id identifier debe configurar:

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

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

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

  • Sólo en interfaces configuradas con service-domain inside.

  • Solo en interfaces que estén en el mismo VRF.