Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Introducción a IPsec VPN

Una VPN es una red privada que utiliza una red pública para conectar dos o más sitios remotos. En lugar de utilizar conexiones dedicadas entre redes, las VPN utilizan conexiones virtuales enrutadas (de túnel) a través de redes públicas. IPsec VPN es un protocolo que consta de un conjunto de estándares que se utiliza para establecer una conexión VPN.

Introducción a IPsec VPN

Una VPN proporciona un medio por el que los equipos remotos se comunican de forma segura a través de una WAN pública, como Internet.

Una conexión VPN puede vincular dos LAN (VPN de sitio a sitio) o un usuario de acceso telefónico remoto y una LAN. El tráfico que fluye entre estos dos puntos pasa a través de recursos compartidos tales como enrutadores, conmutadores y otros equipos de red que forman la WAN pública. Para proteger la comunicación VPN mientras se pasa a través de la WAN, los dos participantes crean un túnel de seguridad IP (IPsec).

El término túnel no denota modo de túnel (consulte Procesamiento de paquetes en modo de túnel). En su lugar, hace referencia a la conexión IPsec.

IPsec es un conjunto de protocolos relacionados para proteger las comunicaciones de forma criptográfica en la capa de paquetes IP. IPsec también proporciona métodos para la negociación manual y automática de asociaciones de seguridad (SAs) y la distribución de claves, todos los atributos para los que se recopilan en un dominio de interpretación (DOI). El DOI de IPsec es un documento que contiene definiciones para todos los parámetros de seguridad necesarios para la negociación correcta de un túnel VPN: básicamente, todos los atributos necesarios para sa y ICR negociación. Consulte RFC 2407 y RFC 2408 para obtener más información.

Este tema incluye las siguientes secciones:

Asociaciones de seguridad

Una asociación de seguridad (SA) es un acuerdo unidireccional entre los participantes de la VPN en relación con los métodos y parámetros que se utilizan para proteger un canal de comunicación. La comunicación bidireccional completa requiere al menos dos SA, uno para cada dirección. A través de la SA, un túnel IPsec puede proporcionar las siguientes funciones de seguridad:

  • Privacidad (mediante cifrado)

  • Integridad del contenido (mediante autenticación de datos)

  • Autenticación de remitente y, si utiliza certificados, no repudiación (mediante autenticación de origen de datos)

Las funciones de seguridad que emplee dependerán de sus necesidades. Si sólo necesita autenticar el origen del paquete IP y la integridad del contenido, puede autenticar el paquete sin aplicar ningún cifrado. Por otro lado, si solo le preocupa conservar la privacidad, puede cifrar el paquete sin aplicar ningún mecanismo de autenticación. Opcionalmente, puede cifrar y autenticar el paquete. La mayoría de los diseñadores de seguridad de red deciden cifrar, autenticar y reproducir la protección de su tráfico VPN.

Un túnel IPsec se compone de un par de SA unidireccionales (una SA para cada dirección del túnel) que especifican el índice de parámetros de seguridad (SPI), la dirección IP de destino y el protocolo de seguridad (encabezado de autenticación [AH] o la carga de seguridad de encapsulación [ESP] empleados. Un SA agrupa los siguientes componentes para proteger las comunicaciones:

Para el tráfico entrante, Junos OS busca la SA mediante el siguiente triple:

  • Dirección IP de destino.

  • Protocolo de seguridad, AH o ESP. (Consulte Protocolos de seguridad IPsec.)

  • Valor del índice de parámetros de seguridad (SPI).

Para el tráfico de VPN saliente, la Directiva invoca la SA asociada con el túnel VPN.

Administración de claves IPsec

La distribución y administración de claves son críticas para el uso correcto de VPN. Junos OS admite la tecnología IPsec para crear túneles VPN con tres tipos de mecanismos de creación de claves:

  • Tecla manual

  • AutoKey ICR con una clave previamente compartida o un certificado

Puede elegir su mecanismo de creación de claves (también llamado método de autenticación) durante la configuración de la propuesta de fase 1 y fase 2. Consulte Negociación de túnel IPsecla.

Este tema incluye las siguientes secciones:

Tecla manual

Con las claves manuales, los administradores de ambos extremos de un túnel configuran todos los parámetros de seguridad. Se trata de una técnica viable para redes pequeñas y estáticas en las que la distribución, el mantenimiento y el seguimiento de claves no son difíciles. Sin embargo, la distribución segura de configuraciones clave manuales en grandes distancias plantea problemas de seguridad. Aparte de pasar las teclas frontales, no puede estar completamente seguro de que las claves no se han visto comprometidas durante la transmisión. Además, siempre que desee cambiar la clave, se le plantearán los mismos problemas de seguridad que cuando lo distribuyó inicialmente.

AutoKey ICR

Cuando necesite crear y administrar varios túneles, necesitará un método que no requiera que configure cada elemento manualmente. IPsec admite la generación y negociación automatizadas de claves y asociaciones de seguridad mediante el protocolo Intercambio de claves por red (ICR). Junos OS se refiere a esta negociación automatizada de túnel como AutoKey ICR y admite AutoKey ICR con claves previamente compartidas y AutoKey ICR con certificados.

  • Clave automática ICR con claves previamente compartidas: mediante el uso de ICR de clave automática con claves previamente compartidas para autenticar ICR los participantes en una sesión de ICR, cada lado debe configurar e intercambiar de antemano la clave previamente compartida. En este sentido, el problema de la distribución segura de claves es el mismo que con las claves manuales. Sin embargo, una vez distribuido, una Autokey, a diferencia de la clave manual, puede cambiar automáticamente sus claves a intervalos predeterminados mediante el protocolo ICR. Las claves que cambian frecuentemente mejoran en gran medida la seguridad y, de esta manera, lo reducen considerablemente las responsabilidades de la administración de claves. Sin embargo, el cambio de claves aumenta la sobrecarga del tráfico; por lo tanto, cambiar las claves con demasiada frecuencia puede reducir la eficacia de transmisión de datos.

    Una clave previamente compartida es una clave para el cifrado y el descifrado, que ambos participantes deben tener antes de iniciar la comunicación.

  • Clave automática ICR con certificados: cuando se utilizan certificados para autenticar a los participantes durante una negociación de ICR de clave automática, cada lado genera un par de claves pública y privada y adquiere un certificado. Siempre que la autoridad de certificación emisora (AC) sea de confianza para ambos lados, los participantes pueden recuperar la clave pública del par y comprobar la firma del par. No es necesario hacer un seguimiento de las claves y SAs; ICR lo hace automáticamente.

Intercambio Diffie-Hellman

Un intercambio Diffie-Hellman (DH) permite que los participantes generen un valor secreto compartido. La fortaleza de la técnica es que permite a los participantes crear el valor secreto a través de un medio no seguro sin pasar el valor secreto a través del cable. El tamaño del módulo principal usado en el cálculo de cada grupo difiere como se muestra en la siguiente tabla. Las operaciones de intercambio Diffie Hellman (DH) se pueden realizar en software o hardware. Cuando estas operaciones de intercambio se realizan en hardware, utilizamos la criptografía de tecnología QuickAssist (QAT). A continuación, se enumeran diferentes grupos Diffie Hellman (DH) y se especifica si la operación realizada para ese grupo se encuentra en Tabla 1 el hardware o en el software.

Tabla 1: Los grupos Diffie Hellman (DH) y sus operaciones de intercambio llevaron a cabo

Grupo Diffie-Hellman (DH)

Tamaño del módulo principal

Operación de intercambio realizada en

Grupo DH 1

768-bit

Ferretería

Grupo DH 2

102-bit

Ferretería

Grupo DH 5

1536-bit

Ferretería

Grupo DH 14

2048-bit

Ferretería

Grupo DH 15

3072-bit

Software

Grupo DH 16

4096-bit

Software

Grupo DH 19

Curva elíptica de 256 bits

Software

Grupo DH 20

Curva elíptica de 384 bits

Software

Grupo DH 21

Curva elíptica de 521 bits

Software

Grupo DH 24

Subgrupo de orden principal de 2048 bits

Software

A partir de Junos OS versión 19.1R1, los dispositivos serie SRX son compatibles con los grupos DH 15, 16 y 21.

No recomendamos el uso de los grupos DH 1, 2 y 5.

Dado que el módulo para cada grupo DH tiene un tamaño diferente, los participantes deben aceptar que se utilice el mismo grupo.

Protocolos de seguridad IPsec

IPsec utiliza dos protocolos para proteger las comunicaciones en la capa IP:

  • Encabezado de autenticación (AH): un protocolo de seguridad para autenticar el origen de un paquete IP y comprobar la integridad de su contenido

  • Carga de seguridad de encapsulación (ESP): un protocolo de seguridad para cifrar todo el paquete IP (y autenticar su contenido)

Puede elegir sus protocolos de seguridad (también denominados algoritmos de autenticación y cifrado)durante la configuración de la propuesta de fase 2. Consulte Negociación de túnel IPsecla.

Para cada túnel VPN, se instalan sesiones de túnel AH y ESP en unidades de procesamiento de servicios (SPUs) y en el plano de control. Las sesiones de túnel se actualizan con el protocolo negociado después de completarse la negociación. Para SRX5400, SRX5600 y SRX5800, las sesiones de túnel del delimitador SPUs se actualizan con el protocolo negociado, mientras que los SPUs que no son de delimitadores conservan las sesiones ESP y AH del túnel. Las sesiones de túnel ESP y AH se muestran en los resultados show security flow session de show security flow cp-session los comandos del modo de operación y.

Este tema incluye las siguientes secciones:

Protocolo AH

El protocolo AH (encabezado de autenticación) proporciona un medio para comprobar la autenticidad e integridad del contenido y el origen de un paquete. Puede autenticar el paquete mediante la suma de comprobación calculada a través de un código de autenticación de mensajes hash (HMAC) mediante una clave secreta y funciones hash MD5 o SHA.

  • Síntesis del mensaje 5 (MD5): un algoritmo que produce un hash de 128 bits (también llamado síntesis de mensajes o firma digital) a partir de un mensaje de longitud arbitraria y una clave de 16 bytes. Se utiliza el hash resultante, como una huella dactilar de la entrada, para comprobar el contenido y la autenticidad e integridad del origen.

  • Algoritmo de hash seguro (SHA): un algoritmo que genera un hash de 160 bits a partir de un mensaje de longitud arbitraria y una clave de 20 bytes. Generalmente se considera más seguro que con MD5 debido a los hash de mayor tamaño que produce. Dado que el procesamiento computacional se realiza en los ASIC, el costo de rendimiento es insignificante.

Para obtener más información acerca de los algoritmos hash MD5, consulte RFC 1321 y RFC 2403. Para obtener más información acerca de los algoritmos de hash SHA, consulte RFC 2404. Para obtener más información acerca de HMAC, consulte RFC 2104.

Protocolo ESP

El protocolo carga de seguridad encapsuladora (ESP) proporciona un medio para garantizar la privacidad (cifrado) y la autenticación de origen e integridad del contenido (autenticación). ESP en modo de túnel encapsula todo el paquete IP (encabezado y carga) y, a continuación, anexa un nuevo encabezado IP al paquete que está ahora cifrado. Este nuevo encabezado de IP contiene la dirección de destino necesaria para enrutar los datos protegidos a través de la red. (Consulte procesamiento de paquetes en modo de túnel.)

Con ESP, puede cifrar y autenticar, únicamente cifrar o autenticar. Para el cifrado, puede elegir uno de los siguientes algoritmos de cifrado:

  • Estándar de cifrado de datos (DES): un algoritmo de bloque criptográfico con una clave de 56 bits.

  • Triple DES (3DES): una versión más potente de DES en la que se aplica el algoritmo DES original en tres rondas mediante una clave de 168 bits. DES proporciona ahorros significativos de rendimiento, pero se considera inaceptable para varias transferencias de material clasificadas o sensibles.

  • Estándar de cifrado avanzado (AES): un estándar de cifrado que ofrece una mayor interoperabilidad con otros dispositivos. Junos OS admite AES con claves de 128 bits, 192 bits y 256 bits.

Para la autenticación, puede utilizar algoritmos MD5 o SHA.

Aunque es posible seleccionar NULL para el cifrado, se ha demostrado que IPsec puede ser vulnerable a ataques en tales circunstancias. Por lo tanto, sugerimos que elija un algoritmo de cifrado para obtener la máxima seguridad.

Negociación de túnel IPsec

Para establecer un AutoKey ICR túnel IPsec, son necesarias dos fases de negociación:

  • En la fase 1, los participantes establecen un canal seguro en el que negociar las asociaciones de seguridad IPSec (SA).

  • En la fase 2, los participantes negocian las SA de IPSec para cifrar y autenticar los siguientes intercambios de datos de usuario.

Para un túnel IPsec de clave manual, dado que todos los parámetros de SA se han definido anteriormente, no es necesario negociar qué SA se deben usar. Básicamente, el túnel ya se ha establecido. Cuando el tráfico coincide con una directiva que utiliza ese túnel de clave manual o cuando una ruta implica el túnel, el dispositivo de Juniper Networks simplemente cifra y autentica los datos, según su determinación, y los reenvía a la puerta de enlace de destino.

La dirección de puerta de enlace de ICR remoto puede estar en cualquier instancia de enrutamiento virtual (VR). El VR se determina durante ICR negociación de fase 1 y fase 2. No es necesario configurar VR en las propuestas de ICR. Si la interfaz de puerta de enlace de ICR se mueve de un VR a otro, las negociaciones ICR existentes de las fases 1 y 2 de la puerta de enlace de ICR se borrarán, y se llevarán a cabo nuevas negociaciones de fase 1 y fase 2.

  • En los dispositivos serie SRX, cuando se habilita VPN, se admite la superposición de direcciones IP entre enrutadores virtuales con las siguientes limitaciones:

    • Una dirección de interfaz externa ICR no puede superponerse con ningún otro enrutador virtual.

    • Una dirección interna o de interfaz de confianza puede superponerse a través de enrutadores virtuales.

    • Una dirección de interfaz st0 no puede superponerse en una VPN basada en ruta en túnel de punto a multipunto, como NHTB.

    • Una dirección de interfaz st0 puede superponerse en una VPN basada en rutas en el túnel punto a punto.

  • Las combinaciones de direcciones IP locales y direcciones IP de puerta de enlace remota de los túneles VPN de IPsec configurados en VRs tienen que ser únicas.

  • Cuando la interfaz de bucle invertido se utiliza como interfaz externa de ICR puerta de enlace, la interfaz física de la negociación de ICR debe encontrarse en el mismo VR.

Topologías VPN de IPsec en dispositivos serie SRX

A continuación, se muestran algunas de las topologías VPN de IPsec compatibles con Junos sistema operativo:

  • VPN de sitio a sitio: conecta dos sitios en una organización juntos y permite comunicaciones seguras entre los sitios.

  • VPN hub-and-spoke: conecta las sucursales a la oficina corporativa en una red empresarial. También puede utilizar esta topología para conectar los radios de forma conjunta mediante el envío de tráfico a través del concentrador.

  • VPN de acceso remoto: permite que los usuarios que trabajan en casa o que viajan se conecten a la oficina corporativa y sus recursos. A veces, esta topología se conoce como un túnel de extremo a sitio.

Comparación de VPN basadas en la Directiva y las basadas en la ruta

Es importante comprender las diferencias existentes entre las VPN basadas en la Directiva y las rutas, y la razón por la que una puede ser preferible a la otra.

Tabla 2enumera las diferencias existentes entre las VPN basadas en rutas y las VPN basadas en directivas.

Tabla 2: Diferencias entre VPN basadas en rutas y VPN basadas en políticas

VPN basadas en la ruta

VPN basadas en políticas

Con las VPN basadas en la ruta, una directiva no hace referencia específicamente a un túnel VPN.

Con túneles VPN basados en políticas, un túnel se trata como un objeto que, junto con el origen, destino, aplicación y acción, constituye una directiva de túnel que permite el tráfico VPN.

La Directiva hace referencia a una dirección de destino.

En una configuración VPN basada en directivas, una directiva de túnel hace referencia específicamente a un túnel VPN por nombre.

El número de túneles de VPN basados en rutas que crea está limitado por el número de entradas de ruta o el número de interfaces st0 compatibles con el dispositivo, el número menor.

El número de túneles VPN basados en la Directiva que puede crear está limitado por el número de directivas que admite el dispositivo.

La configuración del túnel VPN basado en la ruta es una buena elección cuando se desea conservar los recursos de túnel mientras se establecen restricciones granulares en el tráfico VPN.

Con una VPN basada en directivas, aunque puede crear numerosas directivas de túnel que hagan referencia al mismo túnel de VPN, cada par de directivas de túnel crea una asociación de seguridad IPsec (SA) individual con el interlocutor remoto. Cada SA cuenta como un túnel VPN individual.

Con un enfoque de VPN basado en la ruta, el Reglamento de tráfico no se asocia con los medios de su entrega. Puede configurar docenas de directivas para regular el tráfico que fluye a través de un túnel único de VPN entre dos sitios y que sólo hay una asociación de IPsec en el trabajo. Además, una configuración VPN basada en rutas le permite crear políticas que hacen referencia a un destino alcanzado a través de un túnel VPN en el que la acción es deny (denegar).

En una configuración VPN basada en políticas, la acción debe ser permitir y debe incluir un túnel.

Las VPN basadas en la ruta admiten el intercambio de información de enrutamiento dinámico a través de túneles VPN. Puede habilitar una instancia de un protocolo de enrutamiento dinámico, como OSPF, en una interfaz st0 que esté enlazada a un túnel VPN.

El intercambio de información de enrutamiento dinámico no se admite en las VPN basadas en políticas.

Las configuraciones basadas en la ruta se utilizan para topologías de concentrador y periferia.

Las VPN basadas en políticas no se pueden utilizar para topologías de concentrador y periferia.

Con las VPN basadas en la ruta, una directiva no hace referencia específicamente a un túnel VPN.

Cuando un túnel no conecta redes de gran tamaño que ejecutan protocolos de enrutamiento dinámico y no necesita conservar túneles ni definir varias políticas para filtrar el tráfico a través del túnel, la mejor opción es un túnel basado en la Directiva.

Las VPN basadas en la ruta no son compatibles con las configuraciones VPN de acceso remoto (acceso telefónico).

Los túneles VPN basados en políticas son necesarios para las configuraciones VPN de acceso remoto (dial-up).

Es posible que las redes VPN basadas en la ruta no funcionen correctamente con otros proveedores.

Es posible que se necesiten VPN basadas en políticas si el tercero requiere una SAs independiente para cada subred remota.

Cuando el dispositivo de seguridad realiza una búsqueda de ruta para encontrar la interfaz a través de la cual debe enviar tráfico para llegar a una dirección, encuentra una ruta a travésst0de una interfaz de túnel seguro (), que está enlazada a un túnel VPN específico.

Con un túnel de VPN basado en rutas, puede considerar un túnel como un medio para entregar el tráfico, y puede considerar la Directiva como un método para permitir o denegar la entrega de ese tráfico.

Con un túnel VPN basado en directivas, puede considerar un túnel como un elemento en la construcción de una política.

Las VPN basadas en la ruta TDR son compatibles con las interfaces st0.

Las VPN basadas en políticas no se pueden utilizar si se requiere TDR para el tráfico de túnel.

El ID de proxy se admite para VPN basadas en rutas y basadas en directivas. Los túneles basados en ruta también ofrecen el uso de varios selectores de tráfico también conocidos como ID de multi proxy. Un selector de tráfico es un acuerdo entre los pares de ICR para permitir tráfico a través de un túnel, si el tráfico coincide con un par especificado de prefijo de dirección IP local y remota, rango de puerto de origen, intervalo de puerto de destino y protocolo. Un selector de tráfico se define dentro de una VPN basada en ruta específica, lo que puede dar como resultado varias SA de IPsec de fase 2. Solo se permite el tráfico que se ajusta a un selector de tráfico a través de una SA. Normalmente, el selector de tráfico es necesario cuando los dispositivos de puerta de enlace remota son dispositivos no Juniper Networks.

Las VPN basadas en políticas solo se admiten en dispositivos SRX5400, SRX5600 y SRX5800. La compatibilidad de la plataforma depende de la versión Junos OS de la instalación.

Comparación de VPN basadas en políticas y VPN basadas en la ruta

Tabla 3resume las diferencias entre las VPN basadas en Directiva y las VPN basadas en la ruta.

Tabla 3: Comparación entre VPN basadas en políticas y VPN basadas en la ruta

VPN basadas en políticas

VPN basadas en la ruta

En las VPN basadas en políticas, un túnel se trata como un objeto que, junto con el origen, el destino, la aplicación y la acción, constituye una directiva de túnel que permite el tráfico VPN.

En las VPN basadas en la ruta, una directiva no hace referencia específicamente a un túnel VPN.

Una directiva de túnel hace referencia específicamente a un túnel VPN por nombre.

Una ruta determina qué tráfico se envía a través del túnel basándose en una dirección IP de destino.

El número de túneles VPN basados en políticas está limitado por el número de túneles admitidos por el dispositivo.

El número de túneles VPN basados en rutas que crea está limitado por el número de interfaces st0 (para VPN de punto a punto) o el número de túneles admitidos por el dispositivo, el que sea menor.

Con una VPN basada en directivas, aunque puede crear numerosas directivas de túnel que hagan referencia al mismo túnel de VPN, cada par de directivas de túnel creará una asociación de IPsec individual con el interlocutor remoto. Cada SA cuenta como un túnel VPN individual.

Dado que la ruta, no la Directiva, determina qué tráfico pasa por el túnel, es posible que se admitan varias directivas con una sola SA o VPN.

En una VPN basada en políticas, la acción debe ser permitir y debe incluir un túnel.

En una red privada virtual (VPN) basada en rutas, la regulación del tráfico no se asocia con los medios de su entrega.

El intercambio de información de enrutamiento dinámico no se admite en las VPN basadas en políticas.

Las VPN basadas en la ruta admiten el intercambio de información de enrutamiento dinámico a través de túneles VPN. Puede habilitar una instancia de un protocolo de enrutamiento dinámico, como OSPF, en una interfaz st0 que esté enlazada a un túnel VPN.

Si necesita más granularidad de la que puede proporcionar una ruta para especificar el tráfico que se envía a un túnel, la mejor opción es usar una VPN basada en Directiva con políticas de seguridad.

Las redes VPN basadas en la ruta utilizan rutas para especificar el tráfico que se envía a un túnel; una directiva no hace referencia específicamente a un túnel VPN.

Con un túnel VPN basado en directivas, puede considerar un túnel como un elemento en la construcción de una política.

Cuando el dispositivo de seguridad realiza una búsqueda de ruta para encontrar la interfaz a través de la cual debe enviar tráfico para llegar a una dirección, encuentra una ruta a través de una interfaz de túnel seguro (st0).

Con un túnel de VPN basado en rutas, puede considerar un túnel como un medio para entregar el tráfico, y puede considerar la Directiva como un método para permitir o denegar la entrega de ese tráfico.

Descripción del procesamiento de paquetes de ICR y IPsec

Un túnel VPN de IPsec se compone de la configuración de túneles y la seguridad aplicada. Durante la instalación de túneles, los interlocutores establecen asociaciones de seguridad (SA), que definen los parámetros para proteger el tráfico entre ellos. (Consulte Introducción a IPSec VPN.) Después de establecer el túnel, IPsec protege el tráfico que se envía entre los dos extremos del túnel mediante la aplicación de los parámetros de seguridad definidos por la SA durante la instalación del túnel. Dentro de la implementación Junos OS, IPsec se aplica en modo de túnel, que admite los protocolos carga de seguridad de encapsulación (ESP) y encabezado de autenticación (AH).

Este tema incluye las siguientes secciones:

Procesamiento de paquetes en modo de túnel

IPsec funciona en uno de dos modos: transporte o túnel. Cuando ambos extremos del túnel son hosts, puede utilizar cualquiera de los modos. Cuando al menos uno de los puntos de conexión de un túnel es una puerta de enlace de seguridad, como una Junos OS enrutador o firewall, debe utilizar el modo de túnel. Los dispositivos Juniper Networks funcionan siempre en modo de túnel para túneles IPsec.

En el modo de túnel, todo el paquete IP original (carga y encabezado) se encapsula dentro de otra carga IP y se le anexa un nuevo encabezado, como se muestra Figura 1 en. El paquete original completo puede cifrarse, autenticarse o ambas cosas. Con el protocolo AH (Authentication header), también se autentican los encabezados AH y los nuevos. Con el protocolo carga de seguridad de encapsulación (ESP), también se puede autenticar el encabezado ESP.

Figura 1: Modo de túnelModo de túnel

En una VPN de sitio a sitio, las direcciones de origen y destino utilizadas en el nuevo encabezado son las direcciones IP de la interfaz de salida. Consulte Figura 2la.

Figura 2: VPN de sitio a sitio en modo de túnelVPN de sitio a sitio en modo de túnel

En una VPN de acceso telefónico, no hay puerta de enlace de túnel en el cliente de acceso telefónico a redes VPN extremo del túnel; el túnel se extiende directamente al propio cliente (consulte Figura 3). En este caso, en los paquetes enviados desde el cliente de acceso telefónico a redes, tanto el encabezado nuevo como el original encapsulado tienen la misma dirección IP: la de la computadora del cliente.

Algunos clientes VPN, como el cliente VPN dinámico y NetScreen-Remote, utilizan una dirección IP interna virtual (también llamada "dirección adhesiva"). NetScreen-Remote le permite definir la dirección IP virtual. El cliente VPN dinámico utiliza la dirección IP virtual asignada durante el intercambio de configuración XAuth. En estos casos, la dirección IP interna virtual es la dirección IP de origen en el encabezado del paquete original del tráfico que se origina en el cliente, y la dirección IP que el ISP asigna dinámicamente es la dirección IP de origen del encabezado exterior.

Figura 3: VPN de acceso telefónico en modo de túnelVPN de acceso telefónico en modo de túnel

Distribución de sesiones de ICR e IPsec en SPUs

En los dispositivos SRX5400, SRX5600 y SRX5800, ICR proporciona administración de túnel para IPsec y autentica a las entidades finales. ICR realiza un intercambio de claves Diffie-Hellman (DH) para generar un túnel IPsec entre los dispositivos de red. Los túneles IPsec generados por ICR se utilizan para cifrar, descifrar y autenticar el tráfico de usuario entre los dispositivos de red en la capa IP.

La VPN se crea mediante la distribución de la ICR y de la carga de trabajo de IPsec entre las distintas unidades de procesamiento de servicios (SPUs) de la plataforma. En el caso de los túneles de localización a localización, la SPU de carga mínima se elige como la SPU de delimitación. Si varios SPUs tienen la misma carga mínima, cualquiera de ellos puede elegirse como un anclaje de la SPU. En este caso, la carga corresponde al número de puertas de enlace de sitio a sitio o de túneles VPN manuales anclados en una SPU. En el caso de túneles dinámicos, los túneles dinámicos recién establecidos emplean un algoritmo de operación por rondas para seleccionar la SPU.

En IPsec, la carga de trabajo se distribuye con el mismo algoritmo que distribuye el ICR. La SA de Phase 2 para un par de puntos de terminación de túnel de VPN determinado es propiedad exclusiva de una SPU concreta, y todos los paquetes IPsec que pertenecen a esta SA de fase 2 se reenvían a la SPU de delimitación de esa SA para el procesamiento de IPsec.

Varias sesiones IPsec (SA de fase 2) pueden funcionar a través de una o más sesiones ICR. La SPU que se selecciona para delimitar la sesión IPsec se basa en la SPU que delimita la sesión de ICR subyacente. Por lo tanto, todas las sesiones IPsec que se ejecutan en una sola puerta de enlace de ICR son prestadas por el mismo SPU, y no tienen un equilibrio de carga en varios SPUs.

Tabla 4 muestra un ejemplo de un dispositivo de línea SRX5000 con tres Spus que ejecutan siete túneles IPSEC a través de tres puertas de enlace ICR.

Tabla 4: Distribución de sesiones de ICR e IPsec en SPUs

SPU

Puerta de enlace ICR

Túnel IPsec

SPU0

IKE-1

IPsec-1

IPsec-2

IPsec-3

SPU1

IKE-2

IPsec-4

IPsec-5

IPsec-6

SPU2

IKE-3

IPsec-7

Las tres SPUs tienen una carga igual de una puerta de enlace ICR cada uno. Si se crea una nueva puerta de enlace de ICR, puede seleccionar SPU0, SPU1 o SPU2 para delimitar la puerta de enlace de ICR y sus sesiones IPsec.

La configuración y el desactivamiento de túneles IPsec no afectan a la sesión de ICR subyacente ni a los túneles IPsec existentes.

Utilice el siguiente show comando para ver el recuento de túneles actual por la SPU: show security ike tunnel-map.

Utilice la summary opción del comando para ver los puntos de anclaje de cada puerta de enlace: show security ike tunnel-map summary.

Compatibilidad de VPN para insertar tarjetas de procesamiento de servicios

Los dispositivos SRX5400, SRX5600 y SRX5800 tienen una arquitectura de procesador distribuido basada en chasis. La potencia de procesamiento de flujo se comparte y se basa en el número de tarjetas de procesamiento de servicios (SPCs). Puede escalar la potencia de procesamiento del dispositivo instalando nuevas SPCs.

En un clúster de SRX5400, SRX5600 o SRX5800 chasis, puede insertar nuevos SPCs en los dispositivos sin afectar ni interrumpir el tráfico en los ICR existentes o túneles VPN de IPsec. Cuando se inserta un nuevo SPC en cada chasis del cluster, los túneles existentes no se ven afectados y el tráfico sigue fluyendo sin interrupciones.

A partir de Junos OS versión 19.4 R1, en todos los dispositivos de la serie SRX5000 clúster de chasis, puede insertar una nueva tarjeta SRX5K-SPC3 (SPC3) o SRX5K-SPC-4-15-320 (SPC2) en un chasis existente que contenga una tarjeta SPC3. Sólo puede insertar las tarjetas en un área superior a la de la tarjeta de SPC3 existente en el chasis. Debe reiniciar el nodo después de la inserción de SPC3 para activar la tarjeta. Una vez completado el reinicio del nodo, se distribuyen los túneles IPsec a las tarjetas.

Sin embargo, los túneles existentes no pueden usar la potencia de procesamiento de las unidades de procesamiento del servicio (SPUs) en el nuevo SPCs. Una nueva SPU puede delimitar los túneles dinámicos y de sitio a sitio recién establecidos. Sin embargo, no se garantiza que los túneles recién configurados se delimiten en una nueva SPU.

Los túneles de sitio a sitio se delimitan en diferentes SPUs según un algoritmo de equilibrio de carga. El algoritmo de equilibrio de carga depende de los subprocesos de flujo de número que utiliza la SPU. Los túneles que pertenecen a las mismas direcciones IP de puerta de enlace local y remota se fijan en la misma SPU con diferentes subprocesos de flujo RT utilizados por la SPU. La SPU con la carga más pequeña se elige como la SPU de delimitación. Cada SPU mantiene una cantidad de subprocesos de flujo RT que se alojan en esa particular SPU. El número de roscas de caudal RT alojados en cada la SPU varía según el tipo de SPU.

Factor de carga de túnel = número de túneles fijados en la SPU/cantidad total de subprocesos de flujo RT utilizados por la SPU.

Los túneles dinámicos se delimitan en diferentes SPUs basándose en un algoritmo de operación por turnos. No se garantiza que los túneles dinámicos recién configurados se delimiten en el nuevo SPC.

A partir de Junos OS versión 18.2 R2 y 18.4 R1, sólo se admitirán todas las funciones existentes de IPsec VPN que actualmente se admiten en SRX5K-SPC3 (SPC3) en dispositivos SRX5400, SRX5600 y SRX5800 cuando SRX5K-SPC-4-15-320 (SPC2) y tarjetas SPC3 estén instaladas y funcionan en el dispositivo en modo de clúster de chasis o en modo independiente.

Cuando se instalan las tarjetas SPC2 y SPC3, puede comprobar la asignación de túnel en diferentes SPUs mediante show security ipsec tunnel-distribution el comando.

Use el comando show security ike tunnel-map para ver la asignación de túnel en diferentes Spus de sesión con solo spc2 tarjeta insertada. El comando show security ike tunnel-map no es válido en un entorno en el que las tarjetas spc2 y SPC3 están instaladas.

Insertando la tarjeta SPC3: Directrices y limitaciones:

  • En un clúster de chasis, si uno de los nodos tiene una tarjeta SPC3 y el otro nodo tiene 2 tarjetas SPC3, no se admite la conmutación por error al nodo que tiene 1 tarjeta SPC3.

  • Debe insertar el SPC3 o el SPC2 en un chasis existente en una ranura más alta que en la actual SPC3 presente en una ranura inferior.

  • Para que SPC3 ISHU funcione, debe insertar la nueva tarjeta de SPC3 en el número de la ranura superior.

  • En SRX5800 clúster de chasis, no debe insertar la tarjeta de SPC3 en la ranura más alta (Nº de ranura 11) debido al límite de alimentación y distribución de calor.

  • No se admite la eliminación de SPC3 Hot.

Habilitando conjunto de características de IPsec VPN en la tarjeta de procesamiento de servicios SRX5K SPC3

La línea de dispositivos SRX5000 con tarjeta SRX5K-SPC3 requiere el paquete para instalar y habilitar cualquiera de las características de junos-ike VPN IPsec. De forma predeterminada, el paquete se instala en las versiones junos-ike de Junos OS 20.1R2, 20.2R2, 20.3R2, 20.4R1 y posteriores para la línea de dispositivos SRX5000 con RE3. Como resultado, el proceso se ejecuta en el motor de enrutamiento de forma predeterminada en lugar de un demonio de administración de claves ikedikemd IPsec (kmd).

Si desea usar el proceso KMD para habilitar la función VPN IPsec en lugar de la configuración predeterminada ICR, ejecute request system software delete junos-ike el comando.

Para comprobar el paquete junos-ike instalado, utilice el siguiente comando:

Compatibilidad de características VPN IPsec en la línea de dispositivos SRX5000 con SRX5K-SPC3 y vSRX instancias con un paquete nuevo

En este tema, se proporciona un resumen de las características y configuraciones de VPN IPsec que no son compatibles con la línea de dispositivos SRX5000 con SPC3 y en vSRX instancia.

La característica VPN IPsec es compatible con dos procesos y en ikedikemd SRX5K-SPC3 y vSRX instancia. Una sola instancia iked de y se ejecutará en el motor de enrutamiento a la ikemd vez.

De forma predeterminada, el paquete se instala en las versiones Junos-ike de Junos OS 20.1R2, 20.2R2, 20.3R2, 20.4R1 y posteriores para la línea de dispositivos SRX5000 con RE3, y tanto el proceso como el se ejecuta en el motor de ikedikemd enrutamiento.

Para reiniciar ikemd el proceso en el motor de rutina, utilice el restart ike-config-management comando.

Para reiniciar iked el proceso en motor de enrutamiento use el restart ike-key-management comando.

Si desea usar el proceso KMD para habilitar la función VPN IPsec en lugar de la configuración predeterminada ICR, ejecute request system software delete junos-ike el comando.

No se admiten características VPN IPsec

Para determinar si una característica es compatible con una plataforma específica o Junos OS versión, consulte el Explorador de características.

Tabla 5: Compatibilidad de características VPN IPsec en dispositivos serie SRX y vSRX activas

Características

Compatibilidad con la línea de dispositivos SRX 5000 con SRX5K-SPC3 y vSRX instancia

VPN de detección automática (ADVPN).

No

Modo punto a multipunto de multidifusión de protocolo AutoVPN independiente (PIM).

No

AutoVPN RIP compatible con el tráfico de unidifusión.

No

La detección de reenvío bidireccional (BFD) sobre OSPFv3 rutas en st0 interfaz.

No se admite en vSRX

Configurar la clase de reenvío en VPN de IPsec.

No

Modo de configuración (Draft-Dukes-con-MODE-cfg-03).

No

Detección de pares inactivos (DPD) y failover de puerta de enlace DPD.

La conmutación por error de puerta de enlace DPD no se admite en vSRX.

Modos de transporte AH.

No

VPN de grupo.

No

Temporizadores inactivos para ICR.

No

Temporizadores inactivos para IPsec SA.

No

Respuesta SPI no válida.

No

Duración de ICR SA, en kilobytes.

No

Sistema lógico.

No

VPN manual.

No

Tráfico de multidifusión.

No

Neighbor Discovery Protocol (NDP) a través de st0 interfaces.

No

Configuración del tamaño del paquete para la comprobación de la ruta de acceso de IPsec.

No

Reordenación de paquetes para fragmentos IPv6 a través del túnel.

No

Interfaces de túnel punto a multipunto.

No

VPN basada en directivas de IPsec.

No

Acceso remoto.

No

RIP a través de IPsec.

No

Admitir identificadores de ICR de grupo para la configuración de VPN dinámica.

Compatible con SRX

TOS/DSCP respetar IPsec (exterior/interior).

Compatible con SRX

Enrutamiento estático y dinámico de unidifusión (RIP, OSPF, BGP).

Compatible con SRX

Supervisión de VPN.

No

XAuth

No

Descripción de VPN de concentrador y periferia

Si crea dos túneles VPN que terminan en un dispositivo, puede configurar un par de rutas para que el dispositivo dirija el tráfico que sale de un túnel al otro túnel. También debe crear una directiva para permitir que el tráfico pase de un túnel al otro. Dicha disposición se conoce como VPN radial. (Consulte Figura 4.)

También puede configurar varias VPN y enrutar el tráfico entre dos túneles cualesquiera.

Los dispositivos serie SRX solo admiten la característica radial basada en rutas.

Figura 4: Varios túneles en una configuración VPN de concentrador y periferiaVarios túneles en una configuración VPN de concentrador y periferia
Tabla de historial de versiones
Liberación
Descripción
20.1R2
De forma predeterminada, el paquete se instala en las versiones junos-ike de Junos OS 20.1R2, 20.2R2, 20.3R2, 20.4R1 y posteriores para la línea de dispositivos SRX5000 con RE3. Como resultado, el proceso se ejecuta en el motor de enrutamiento de forma predeterminada en lugar de un demonio de administración de claves ikedikemd IPsec (kmd).
19.1R1
A partir de Junos OS versión 19.1R1, los dispositivos serie SRX son compatibles con los grupos DH 15, 16 y 21.