Configuración de Túneles GRE sobre IPsec: Una Guía Exhaustiva para la Conectividad Segura

La interconexión de redes remotas a través de Internet presenta un desafío fundamental para los profesionales de redes: cómo garantizar tanto la conectividad como la seguridad del tráfico. El túnel GRE sobre IPsec emerge como una solución robusta y versátil, combinando la capacidad de encapsulación de GRE con la fortaleza criptográfica de IPsec. Esta guía profundiza en los parámetros esenciales y los pasos de configuración para establecer túneles GRE sobre IPsec, abordando escenarios comunes y proporcionando una comprensión detallada de su funcionamiento.

Comprendiendo la Fusión: GRE vs. IPsec

Antes de adentrarnos en la configuración, es crucial dilucidar las diferencias intrínsecas entre GRE (Generic Routing Encapsulation) y IPsec (Internet Protocol Security), y por qué su combinación es tan poderosa.

CaracterísticaTúnel GRE (Generic Routing Encapsulation)Túnel IPsec (VPN)
Propósito PrincipalEncapsular tráfico de múltiples protocolos (incluido multicast y broadcast) dentro de paquetes IP. No ofrece seguridad.Crear un canal de comunicación seguro y cifrado entre dos puntos.
SeguridadNula. El tráfico viaja en texto plano.Alta. Proporciona confidencialidad (cifrado), integridad y autenticación.
Protocolos SoportadosCasi cualquier protocolo de red, incluyendo protocolos de enrutamiento dinámico como OSPF o EIGRP.Principalmente tráfico Unicast (IP). Soporte limitado o nulo para Multicast.
EstándarDefinido en el RFC 2784 de la IETF.Un framework de múltiples protocolos (ESP, AH, IKE).

En esencia, GRE se utiliza para transportar tipos de tráfico que IPsec por sí solo podría tener dificultades para manejar, como el tráfico multicast o los protocolos de enrutamiento dinámico. Al encapsular este tráfico GRE dentro de un túnel IPsec, se le aplica una capa de seguridad esencial, protegiendo la información sensible durante su tránsito por redes no confiables.

Diagrama comparativo de GRE y IPsec

Escenario de Red y Topología Base

Para ilustrar la configuración, consideremos un escenario común: conectar dos redes remotas de forma segura a través de Internet. Imaginemos que Host1, ubicado en la red 192.168.1.0/24, necesita comunicarse de manera segura con Host2, en la red 192.168.2.0/24. Esta comunicación se establecerá a través de un túnel VPN configurado entre los routers R1 y R3.

Topología de red para VPN GRE sobre IPsec

Este escenario es representativo de la interconexión de sucursales con una sede central, donde la seguridad y la capacidad de enrutamiento dinámico son primordiales.

Fase 1: Configuración del Túnel GRE Básico

El primer paso es establecer un túnel GRE sin cifrado. Este enfoque permite verificar la conectividad básica y aislar posibles problemas antes de introducir la complejidad de IPsec.

Paso 1: Configurar la Interfaz del Túnel en R1

En R1, se crea una interfaz virtual de túnel, denominada Tunnel0. A esta interfaz se le asigna una dirección IP y se definen las direcciones IP de origen y destino del túnel físico (las interfaces públicas de R1 y R3). Es vital ajustar el MTU (Maximum Transmission Unit) y el MSS (Maximum Segment Size) para tener en cuenta la sobrecarga adicional que introducen los encabezados GRE e IPsec, previniendo así la fragmentación de paquetes.

R1(config)# interface Tunnel0R1(config-if)# ip address 10.0.0.1 255.255.255.252R1(config-if)# tunnel source GigabitEthernet0/0 // O la interfaz de salida a InternetR1(config-if)# tunnel destination 192.168.0.2 // IP pública de R3R1(config-if)# ip mtu 1400R1(config-if)# ip tcp adjust-mss 1360R1(config-if)# no shutdownR1(config-if)# exit

Paso 2: Añadir una Ruta Estática en R1

Para que R1 sepa cómo dirigir el tráfico destinado a la red remota (192.168.2.0/24) a través del túnel, se configura una ruta estática. Esta ruta instruye al router a enviar dicho tráfico por la interfaz Tunnel0.

R1(config)# ip route 192.168.2.0 255.255.255.0 Tunnel0

Paso 3: Configurar la Interfaz del Túnel en R3

Se replica el proceso en R3, creando la interfaz Tunnel0 con una dirección IP diferente dentro del mismo rango de túnel y definiendo las direcciones de origen y destino del túnel físico (las interfaces públicas de R3 y R1, respectivamente).

R3(config)# interface Tunnel0R3(config-if)# ip address 10.0.0.2 255.255.255.252R3(config-if)# tunnel source GigabitEthernet0/0 // O la interfaz de salida a InternetR3(config-if)# tunnel destination 192.168.0.1 // IP pública de R1R3(config-if)# ip mtu 1400R3(config-if)# ip tcp adjust-mss 1360R3(config-if)# no shutdownR3(config-if)# exit

Paso 4: Añadir una Ruta Estática en R3

De manera similar a R1, se añade una ruta estática en R3 para dirigir el tráfico hacia la red local de R1 (192.168.1.0/24) a través de la interfaz Tunnel0.

R3(config)# ip route 192.168.1.0 255.255.255.0 Tunnel0

Paso 5: Verificación del Túnel GRE

Con la configuración GRE completada, se puede verificar la conectividad básica. Un ping entre las interfaces de túnel (por ejemplo, desde R1 a R3 en 10.0.0.2) o entre los hosts remotos debería ser exitoso, demostrando que el túnel GRE está operativo.

R1# ping 10.0.0.2Type escape sequence to abort.Sending 5, 100-byte ICMP Echoes to 10.0.0.2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 24/64/88 ms

En este punto, tenemos una conexión funcional, pero el tráfico aún viaja sin protección.

Fase 2: Asegurando el Túnel con IPsec

La siguiente fase consiste en aplicar IPsec para cifrar el tráfico que atraviesa el túnel GRE. Este proceso se divide en dos fases principales de negociación: ISAKMP (Fase 1) y IPsec (Fase 2).

Paso 6: Configurar la Política ISAKMP (Fase 1) en R1

La Fase 1 establece un canal seguro y autenticado para la negociación de los parámetros de la Fase 2. Se definen algoritmos de cifrado, autenticación, grupos Diffie-Hellman (DH) y un tiempo de vida para la Security Association (SA).

R1(config)# crypto isakmp policy 10R1(config-policy)# authentication pre-shareR1(config-policy)# encryption aes 256R1(config-policy)# hash sha256R1(config-policy)# group 14R1(config-policy)# lifetime 86400R1(config-policy)# exit

Paso 7: Configurar la Clave Precompartida (PSK) en R1

Se establece una clave precompartida (PSK) que debe ser idéntica en ambos extremos para la autenticación mutua.

R1(config)# crypto isakmp key cisco123 address 192.168.0.2 // IP pública de R3

Paso 8: Configurar la Política IPsec (Fase 2) en R1

La Fase 2 define cómo se cifrarán y autenticarán los datos una vez que la Fase 1 se haya completado exitosamente. Se especifican los protocolos de encapsulación (ESP), los algoritmos de cifrado y autenticación, y el tiempo de vida de la SA de IPsec.

R1(config)# crypto ipsec transform-set MY_TRANSFORM_SET esp-aes 256 esp-sha256R1(config)# mode tunnelR1(config)# exit

Paso 9: Crear un Perfil de Túnel IPsec en R1

Se crea un perfil de túnel que enlaza la política de ISAKMP con la política de IPsec y define el tráfico que será protegido. En este caso, se define una "crypto map" que especifica el tráfico entre las redes locales y remotas como "interesante".

R1(config)# crypto map MY_CRYPTO_MAP 10 ipsec-isakmpR1(config-map)# set peer 192.168.0.2 // IP pública de R3R1(config-map)# set transform-set MY_TRANSFORM_SETR1(config-map)# match address 101 // ACL que define el tráfico interesanteR1(config-map)# exitR1(config)# ip access-list extended 101R1(config-acl)# permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255R1(config-acl)# exit

Paso 10: Aplicar la Crypto Map a la Interfaz Física en R1

La configuración de IPsec se aplica a la interfaz física de salida a Internet en R1.

R1(config)# interface GigabitEthernet0/0 // O la interfaz de salida a InternetR1(config-if)# crypto map MY_CRYPTO_MAPR1(config-if)# exit

Pasos 11-14: Configuración en R3

Se repiten los pasos 6 a 10 en R3, asegurándose de que las direcciones IP de los peers y las claves precompartidas coincidan, y que las políticas de ISAKMP y IPsec sean compatibles. La ACL en R3 deberá permitir el tráfico desde la red remota hacia la red local.

// En R3:R3(config)# crypto isakmp policy 10R3(config-policy)# authentication pre-shareR3(config-policy)# encryption aes 256R3(config-policy)# hash sha256R3(config-policy)# group 14R3(config-policy)# lifetime 86400R3(config-policy)# exitR3(config)# crypto isakmp key cisco123 address 192.168.0.1 // IP pública de R1R3(config)# crypto ipsec transform-set MY_TRANSFORM_SET esp-aes 256 esp-sha256R3(config)# mode tunnelR3(config)# exitR3(config)# crypto map MY_CRYPTO_MAP 10 ipsec-isakmpR3(config-map)# set peer 192.168.0.1 // IP pública de R1R3(config-map)# set transform-set MY_TRANSFORM_SETR3(config-map)# match address 101 // ACL que define el tráfico interesanteR3(config-map)# exitR3(config)# ip access-list extended 101R3(config-acl)# permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255R3(config-acl)# exitR3(config)# interface GigabitEthernet0/0 // O la interfaz de salida a InternetR3(config-if)# crypto map MY_CRYPTO_MAPR3(config-if)# exit

Fase 3: Verificación Final del Túnel GRE sobre IPsec

Para que el túnel cifrado se levante, es necesario generar "tráfico interesante". Un simple ping desde Host1 a Host2 activará la negociación de IPsec.

Verificando la Fase 1 (ISAKMP SA)

Se utiliza el comando show crypto isakmp sa para confirmar que la Fase 1 se ha establecido correctamente. El estado "QM_IDLE" (o similar) indica que la Fase 1 está activa y esperando el tráfico de la Fase 2.

R1# show crypto isakmp sa0 10.0.0.2 192.168.0.2 <-- Dynamic Dynamic QM_IDLE

Verificando la Fase 2 (IPsec SA)

El comando show crypto ipsec sa muestra el estado de las Security Associations de IPsec. La presencia de contadores pkts encrypt y pkts decrypt mayores que cero es la prueba definitiva de que el túnel GRE está siendo cifrado por IPsec.

R1# show crypto ipsec sainterface: Tunnel0 <--output omitted for brevity--> local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0) path mtu 1400 current_keys: soft: encr 3DES, hash esp, compression off hard: encr 3DES, hash esp, compression off pkts active 1234, <-- Indicates encrypted packets pkts encrypt 1234, <-- Indicates encrypted packets pkts decrypt 1234, <-- Indicates decrypted packets

¡Cree una interfaz de túnel protegida IPsec de Cisco!

Consideraciones Adicionales y Escenarios Complejos

Túneles GRE sobre IPsec con NAT

Cuando uno de los extremos de la VPN se encuentra detrás de un dispositivo NAT (Network Address Translation), la configuración requiere pasos adicionales. Es necesario habilitar NAT Traversal (NAT-T) en IPsec, que utiliza el puerto UDP 4500 para encapsular los paquetes IPsec, permitiendo que el túnel atraviese el NAT. Además, se deben configurar reglas de NAT y reenvío de puertos en el dispositivo NAT para dirigir el tráfico IPsec al firewall o router VPN. En dispositivos como los firewalls Zyxel, la configuración de NAT-T y el reenvío de puertos son esenciales, junto con la configuración adecuada de las políticas locales y remotas.

Múltiples Subredes y Rutas de Política

En algunos dispositivos, como los firewalls Zyxel, existe la limitación de no poder seleccionar múltiples subredes directamente en la configuración de un túnel VPN. Para superar esto, se pueden emplear rutas de política. Estas rutas dirigen manualmente el tráfico de subredes específicas a través del túnel VPN, asegurando que todo el tráfico deseado sea enrutado correctamente. Es crucial verificar que los paquetes de respuesta también se enruten de vuelta a través del túnel en el sitio remoto.

Uso de Interfaces Virtuales de Túnel (VTI)

En entornos Linux, la configuración de túneles IPsec puede realizarse de manera eficiente utilizando interfaces virtuales de túnel (VTI). Libreswan, una implementación popular de IPsec, permite crear VTIs que se comportan como interfaces de red normales. Esto simplifica el enrutamiento y la gestión del tráfico, ya que el tráfico destinado a la red remota se dirige a la VTI, y Libreswan se encarga de encapsularlo y cifrarlo automáticamente. La configuración implica la creación de archivos .conf y .secrets para definir los parámetros de la conexión.

Parámetros de Configuración y Negociación

La correcta negociación de los parámetros de Fase 1 y Fase 2 es fundamental para el establecimiento del túnel IPsec. Algoritmos de cifrado (como AES256), algoritmos de hash (como SHA512), y grupos Diffie-Hellman (como DH14 para 2048 bits) deben coincidir en ambos extremos. La clave precompartida (PSK) debe ser robusta y secreta. La configuración de Perfect Forward Secrecy (PFS) añade una capa adicional de seguridad al generar claves únicas para cada sesión.

Verificación y Solución de Problemas

La verificación del túnel IPsec implica la comprobación de las SA de Fase 1 y Fase 2, así como la monitorización del tráfico cifrado y descifrado. Los comandos como show crypto isakmp sa y show crypto ipsec sa son herramientas indispensables. Los problemas comunes incluyen configuraciones de Fase 1 o Fase 2 no coincidentes, claves precompartidas incorrectas, o reglas de firewall que bloquean el tráfico IPsec (puertos UDP 500 y 4500, protocolos IP 50 y 51). Consultar los logs del dispositivo es crucial para identificar la causa raíz de los fallos.

Conclusión

La configuración de túneles GRE sobre IPsec es una habilidad esencial en la administración de redes modernas. La combinación de la flexibilidad de GRE para transportar diversos protocolos de red con la robusta seguridad de IPsec permite crear conexiones seguras y fiables entre redes remotas. Al comprender los parámetros clave, las fases de negociación y las consideraciones para escenarios complejos como NAT y múltiples subredes, los profesionales de redes pueden implementar soluciones VPN efectivas y robustas. La práctica en laboratorios virtuales y la consulta de documentación oficial son pasos recomendados para dominar esta tecnología.

tags: #parametros #para #establecer #tunel #ipsec #metaswitch