Comprensión de túneles IPsec (L2L)

En mi función actual, trabajo con túneles L2L (LAN a LAN) con bastante frecuencia. Son la forma “barata” de conectar dos ubicaciones en comparación con los circuitos de acceso dedicados. El único requisito es tener el hardware correcto y una IP estática “siempre encendida” en cada ubicación. Con frecuencia bromeo con que configurar un túnel L2L en un ASA es fácil y solo toma 20 líneas de configuración en la CLI. Dicho esto como cualquier otra cosa en el mundo de las redes, si no entiendes cómo funciona la tecnología, algún día te vas a quedar atascado. Escribir 20 líneas de configuración en una consola y comprender realmente lo que está sucediendo son dos cosas completamente diferentes. En esta publicación, hablaré sobre los conceptos básicos de IPsec, cómo se forman los túneles y algunos pasos para solucionar problemas que puede tomar cuando tiene problemas.

Terminología
IPsec (Protocolo de seguridad de Internet) – De lo que estamos hablando

IKE (Intercambio de claves de Internet) – Piense en IKE como el conjunto de herramientas necesario para establecer y mantener una conexión segura entre dos terminales. Básicamente, IKE permite que la conexión forme y mantenga SAs (Asociaciones de seguridad) que son la parte clave de un túnel IPsec

ISAKMP (Asociación de Seguridad de Internet y Protocolo de Administración de Claves): ISAKMP es el estándar que define cómo trabajar con SAs. En otras palabras, ISAKMP maneja cómo se crean, mantienen, modifican y derriban SAS. ¿Has notado la superposición? IKE e ISAKMP suenan muy similares, ¿no? Eso es porque lo son. De hecho, Cisco incluso lo anota en su documentación.

” El Protocolo de Administración de Claves y Asociación de Seguridad de Internet, también llamado IKE, es el protocolo de negociación que permite a dos hosts acordar cómo crear una asociación de seguridad IPsec. Cada negociación de ISAKMP se divide en dos secciones llamadas Fase 1 y Fase 2.”

Dirección de pares-Dependiendo del contexto, es la dirección pública en un extremo del túnel o en el otro extremo del túnel.

DH (Diffie-Hellman) – DH permite a dos partes compartir una clave secreta a través de un canal inseguro. DH se utiliza durante la fase 1 de IKE para intercambiar claves y establecer una clave secreta segura.

Conjuntos de directivas ISAKMP: Un conjunto de directivas que especifica el algoritmo de cifrado IKE, el algoritmo de autenticación IKE, el tipo de autenticación IKE, la versión DH y la vida útil del túnel IKE. El conjunto de políticas ISAKMP se utiliza durante las negociaciones de la fase 1 de IKE. Para que esto sea aún más confuso, los conjuntos de directivas ISAKMP también se conocen como conjuntos de transformaciones ISAKMP, conjuntos de transformaciones IKE o simplemente conjuntos de transformaciones antiguos

Conjuntos de transformaciones IPsec: un conjunto de transformaciones consta de configuraciones relevantes para la creación del túnel IPsec. El conjunto de transformaciones real se usa durante la fase 2 de IKE y generalmente solo consiste en el tipo de cifrado y autenticación de IKE. Una vez más, la parte confusa es que a menudo algunas personas simplemente llaman a estos conjuntos de transformación.

SAs (Asociaciones de seguridad) – Básicamente es el conjunto de parámetros IPsec en los que están de acuerdo ambos lados del túnel. Haré una distinción crítica aquí para aquellos de nosotros en Cisco Land. Habrá una ISAKMP SA y una IPsec SA. Hay varios túneles creados mientras se crea el túnel IPsec. Recuerde que la ISAKMP SA se considera el resultado de la fase IKE 1 y la IPsec SA se considera el resultado de la fase IKE 2. Además, una SA es solo una conexión de un solo sentido. Dado que la mayoría del tráfico entre endpoints requiere comunicación bidireccional, cada ASA creará su propia SA para hablar con el otro par.

Nonce-Un número, generalmente utilizado para una clave segura, que solo se usa una vez. Si se usa por segunda vez, generalmente es una señal de un intento de conexión fraudulento.

Resumen terminológico: La terminología de VPN es muy, muy, muy confusa. Solo trata de recordar que ISAKMP e IKE a veces se usan indistintamente. Además, los conjuntos de transformaciones son un término general para un grupo de configuraciones. Intento usar la frase solo cuando me refiero a lo que escribo después de ‘transform-set’ en la CLI que se usa para especificar el tipo de autenticación y cifrado para la Fase 2 de IKE.

El Proceso
Ahora que conocemos algunos de los términos clave, podemos comenzar a hablar sobre cómo se forma el túnel IPsec. En mi opinión, hay 4 fases en la vida de un túnel IPsec. Los presentaré a continuación y luego hablaremos de ellos

Fase 1-El tráfico interesante genera la creación del túnel
Fase 2-IKE Fase 1
Fase 3-IKE Fase 2
Fase 4 – Terminación del túnel

Algunas personas lanzan una fase entre mi fase 3 y 4 y la listan como ‘Túnel IPsec creado’, que en mi punto de vista no es en realidad una fase. Enumerar el producto de las fases 1 a 3 no parece justificar su propia fase en mi mente. En cualquier caso, vamos a entrar en detalles sobre cada uno.

Fase 1 – El tráfico interesante genera la creación del túnel
Lo que mucha gente no sabe sobre IPsec es que es lo que yo llamo un servicio “bajo demanda”. Es decir, una vez que creas un túnel, no está funcionando todo el tiempo. Lo que llamamos “tráfico interesante”, desencadena la creación de un túnel. Crear el túnel no toma mucho tiempo, pero en la mayoría de los casos, se puede notar cuando se usa ping para probar. En la mayoría de los casos, cuando intento hacer ping desde una máquina cliente a través del túnel, la primera solicitud ICMP fallará porque el túnel se está cargando. Los ICMP posteriores se ejecutan correctamente. El tráfico interesante se define en el ASA con un ACL. Luego, la ACL se especifica dentro del mapa criptográfico de túneles con un comando ‘dirección de coincidencia’. Un ejemplo de ACL podría tener este aspecto:

lista de acceso L2LCryptoMap ip de permiso extendido < Subred local>< Máscara local>< Subred de destino><Máscara de destino>

Le indica al ASA que haga coincidir el tráfico procedente de su subred con la subred del otro lado del túnel. Esto plantea la cuestión de las subredes privadas duplicadas. Si su subred en la interfaz interna de ambos ASAs es la misma, tendrá problemas. Piénselo de esta manera, cuando un cliente de un lado intenta ir a un recurso de la otra subred, no va a ir a ninguna parte. De forma predeterminada, el cliente buscará una respuesta ARP porque cree que el cliente remoto al que intenta acceder está en su subred local. Dado que no intenta salir de la subred, el cliente nunca contactará con la puerta de enlace predeterminada (la interfaz interna de ASA) y nunca formará un túnel. Incluso si lo hicieras, el tráfico no fluiría. Hay algunas cosas “difíciles” que podemos hacer para solucionar este problema, pero no entran en el ámbito de esta entrada de blog. La mejor situación es tener redes privadas únicas en cada ubicación.

Fase 2-IKE Fase 1
Una vez que el ASA recibe una solicitud para una subred remota, que coincide con un mapa criptográfico, comienza la fase 1 de IKE. El objetivo de la fase 1 de IKE es configurar la conexión para la fase 2 de IKE. Básicamente, la fase 1 de IKE establece el trabajo de base para que se produzca la conexión real. En realidad, crea su propia SA, que a veces se denomina SA de gestión. Esta SA de gestión es utilizada por IKE fase 2 para crear los túneles de datos reales. Desde un punto de vista técnico, hay tres pasos para la fase 1 de IKE. El primer paso se llama negociación de políticas. La negociación de políticas se reduce a encontrar conjuntos de transformaciones coincidentes en cada extremo. Antes de los formularios SA de ISAKMP, cada extremo debe acordar un conjunto de directivas IKE coincidente. Los siguientes elementos deben coincidir con la política establecida a cada lado del túnel.

– El algoritmo de cifrado IKE
– El algoritmo de autenticación IKE
-La definición de clave IKE
-La Versión Diffie Hellman
– La Vida útil de IKE

Recuerde, Los conjuntos de políticas de IKE están asociados con la finalización de la fase 1 de IKE. Un endpoint puede tener cualquier número de conjuntos de directivas que se evalúan en un orden. Por ejemplo, es posible que haya establecido directivas 10, 20 y 30. Los puntos finales recorrerán los conjuntos de directivas en orden, comenzando por el más bajo primero hasta que encuentren una coincidencia. Por lo tanto, tiene sentido definir primero conjuntos de políticas más sólidos. Si se definen después de conjuntos de políticas más débiles, es posible que encuentre primero una coincidencia más débil.

Ahora, antes de adentrarnos demasiado en la fase 1 de IKE, es pertinente explicar que hay dos tipos diferentes de fase 1 de IKE. El que se usa más a menudo se llama ‘modo principal’ y consiste en 6 mensajes que se intercambian entre pares. El otro tipo se llama modo agresivo y condensa los mensajes enviados entre pares en 3 mensajes. El modo principal es más lento en la configuración, pero más seguro. El modo agresivo es más rápido en la configuración, pero menos seguro. No me cite en esto, pero creo que el modo principal se usa de forma predeterminada. No voy a entrar en detalles aquí, ambos logran lo mismo y los detalles que enumeré anteriormente deberían indicarte las grandes diferencias.

Nuestro primer paso para la fase 1 de IKE fue la negociación de políticas: los pares deben acordar un conjunto de políticas coincidentes. Para ello, se envían conjuntos de directivas entre sí para que se comparen y encuentren el conjunto de directivas coincidentes más bajo. Una vez que se haya completado, podemos pasar al siguiente paso, que es el intercambio de claves DH. Durante este proceso, los pares intercambian claves públicas que se utilizan para establecer el secreto compartido. Después de este proceso, se forma la Fase 1 SA (ISAKMP SA) y pasamos al último paso, que es la autenticación de pares.

Durante la autenticación por pares, el método de autenticación definido se utiliza para garantizar que los dispositivos no autorizados no formen conexiones seguras en la red. La mayoría de las veces, esto se hace con claves pre-compartidas. Este paso es bastante simple, los pares comprueban para asegurarse de que las teclas coincidan. Si no lo hacen, la autenticación falla. Si coinciden, pasamos a la fase 2 de IKE.

Fase 3-Fase 2 de IKE
Me gusta pensar en la fase 2 de IKE como la construcción real del túnel de datos. El trabajo hasta este momento ha consistido principalmente en garantizar que tengamos un canal de comunicaciones seguro en su lugar para que podamos construir el SAS IPsec real. En comparación con la fase 1 de IKE, la fase 2 de IKE solo tiene un tipo de modo que se llama “modo rápido”. El modo rápido utiliza la SA ISAKMP existente creada en la fase 1 de IKE y crea la SAS IPsec y gestiona los intercambios de claves. El primer paso del modo rápido es negociar los conjuntos de transformaciones IPsec (¡no es lo mismo que los conjuntos de políticas ISAKMP!!). Los siguientes elementos deben coincidir en ambos extremos para que se forme el SAS de IPsec.

– El Protocolo IPsec
– El tipo de cifrado IPsec
– El tipo de autenticación IPsec
– El modo IPsec
– La vida útil IPsec SA

Ahora tomemos un breve momento para comparar los conjuntos de transformaciones de IKE fase 1 y fase 2. La siguiente es una configuración típica de un ASA.

Conjunto de políticas ISAKMP
política isakmp de cifrado 10
autenticación pre-compartida
cifrado 3des
hash sha
grupo 2
curso de la vida 86400

Transformación IPsec
conjunto de transformaciones ipsec de cifrado ESP-3DES-SHA esp-3des esp-sha-hmac

¿Ves algo extraño? En el conjunto de políticas de ISAKMP puede ver claramente las 5 piezas necesarias del conjunto de transformaciones que deben acordarse. En la transformación IPsec no está tan claro. Esto se debe a que la transformación realmente solo define 3 de las 5 piezas requeridas. El ejemplo anterior define el protocolo IPsec (ESP), el tipo de autenticación IPsec (SHA) y el tipo de cifrado IPsec (3DES). No es necesario definir el modo IPsec y la vida útil de IPsec SA. Cuando no lo son, el ASA simplemente asume los siguientes valores de 28,800 para la vida útil de SA y el modo de túnel para todos los conjuntos de transformaciones. Normalmente no cambio estos valores a menos que el otro lado los cambie.

Así que una vez que los conjuntos de transformación se hayan negociado y emparejado, podemos crear el SAS IPsec. Como se indicó anteriormente, una SA es una conexión unidireccional. Por lo tanto, para que el tráfico fluya en cada sentido, deben formarse dos SAS IPsec. La ASA hace este trabajo por ti, por supuesto, por lo que no hay mucho detalle para compartir aquí. El modo rápido utiliza nonces para generar nuevo material clave que evita ataques de repetición. El tercer paso es el proceso de renegociar periódicamente la conexión. El SAS debe regenerarse antes de que expire la vida útil del túnel. El modo rápido monitoriza esto y genera nuevos SAS antes de que los antiguos expiren.

Fase 4-Terminación del túnel
¡En este punto tenemos un túnel VPN completamente funcional! El tráfico debe estar pasando en ambas direcciones. Lo único que queda por hacer es derribar el túnel si no hay tráfico interesante. Las SAS solo se regeneran si el tráfico interesante continúa fluyendo. Si el tráfico interesante se detiene en el SA, se permite que expire después de que se haya alcanzado su vida útil. Si se permite que la SA caduque, TODOS los datos relacionados con la SAS se eliminan de la SA. La próxima vez que se genere tráfico interesante, todo el proceso comenzará desde cero.

Solución de problemas
El problema más común en la conectividad IPsec es no encontrar coincidencias de conjuntos de transformación para las fases 1 y 2 de IKE. Si tiene problemas, lo primero que debe hacer siempre es verificar dos veces la configuración en ambos lados para asegurarse de que coincidan al 100%. Lo siguiente que puede hacer es echar un vistazo a las SAS en el ASA y determinar si se crearon y si lo son, qué estado tienen.

Para ver la Fase IKE SA 1, emita este comando
ASA # show crypto isakmp sa

Para ver la fase IKE SA 2, emita este comando
ASA # show crypto ipsec sa

Si no tiene una fase 1 SA, no llegará muy lejos. El estado de la SA te dice un par de cosas. Le indica si la SA se creó o no con el modo principal o agresivo, de qué lado subió el túnel y también le indica el estado de las negociaciones. A continuación se muestra un vistazo a una SA típica de fase 1.

ASA # show crypto isakmp sa
Active SA: 1
Rekey SA: 0 (Un túnel reportará 1 SA activa y 1 Rekey durante la Rekey)
Total IKE SA: 1

1 Par IKE: < Dirección IP del par>
Tipo: L2L Rol: respondedor
Rekey: no Estado: MM_ACTIVE

Como puede ver en la salida anterior, tenemos una SA de fase 1 de IKE. El tipo es ‘L2L’ (lo que indica que es un túnel IPsec de sitio a sitio), el rol es ‘respondedor’ (lo que significa que el par trajo el túnel), y el estado es MM_Active (lo que significa que está usando el modo principal (MM) y la fase 1 de IKE está funcionando (ACTIVA)). MM_ACTIVE es lo que queremos ver en una IKE SA de fase 1. Eso significa que todo está listo para que ocurra la fase 2 de IKE. Entonces, ¿qué debes hacer si no tienes el estado ACTIVO? ¿O nada de SA?

Hay varios otros estados que pueden indicarle qué está pasando con ISAKMP SA.

Nota: Estos códigos de estado son solo para la versión ASA más reciente, el código IPsec anterior usaba mensajes de estado diferentes.
Las dos primeras letras le indican si la conexión se realizó con el modo principal (MM) o el modo agresivo (AM). Dado que puede ser el modo principal o agresivo, la lista es simplemente ‘XX’ a continuación. Por supuesto, solo verás algunos de ellos con el modo principal o agresivo. Las definiciones que enumero para cada estado son las que he encontrado que son el problema en la mayoría de los casos.

XX_Active – Connected
XX_KEY_EXCH – Error de autenticación, compruebe su método de autenticación
XX_INIT_EXCH – Error de autenticación, compruebe su método de autenticación
XX_NO_STATE – No es posible que coincida con las políticas de Fase 1 de IKE, verifique en cada lado
XX_WAIT_MSG2 – Esperando la respuesta del par

Además, si no tiene una SA en absoluto, comience por verificar lo obvio. Comience en la capa 1 y trabaje para asegurarse de que ambas unidades tengan conectividad y que las direcciones de pares sean correctas.

el 99% de las veces, un problema es con la SA de fase 1 de IKE. Si está recibiendo un estado de ACTIVIDAD en la fase 1, probablemente esté en buena forma. Si todavía tiene problemas, eche un vistazo a su IKE fase 2 SA. No voy a mostrar un ejemplo de uno, ya que en su mayoría son solo estadísticas. Sin embargo, se aplica el mismo concepto, si no tiene una SA IPsec, no tiene un túnel VPN.

Depuración
Si todavía tiene problemas, como cualquier otra cosa en el ASA, intente depurar. Los dos comandos que está buscando serían

ASA # debug crypto isakmp
ASA # debug crypto ipsec
ASA # terminal monitor

Asegúrese de habilitar terminal monitor si no está en el puerto de la consola

La gran solución
No puedo decirle cuántas veces he pasado horas tratando de cargar un túnel sin ningún éxito. Al final, dos comandos siempre arreglaron mis problemas. Cuando todo lo demás falle, borre todas sus SAS ISAKMP e IPSEC. Esto, por supuesto, eliminará cualquier conexión IPsec a la caja. Algo sobre volar todas las otras conexiones y empezar de cero parece arreglarlo. Para hacer esto.

ASA # clear crypto ipsec sa
ASA # clear crypto isakmp sa

Conclusión
Espero que hayas visto, a través de este artículo, que tener una comprensión básica de cómo funciona IPsec hace un mundo de diferencia. Saber dónde buscar errores y cómo interpretarlos es clave para solucionar problemas de túneles IPsec L2L.