Group Encrypted Transport (GET) VPN es una tecnología utilizada para encriptar traffico unicast y multicast que pasa sobre redes inseguras. La diferencia entre las VPNs tradicionales (como Site to Site VPN) con GET VPN, es que GET VPN no requiere la creación de túneles para la protección de la información, la seguridad la realiza implementando los protocolos Group Domain Of Interpretation (GDOI) e IPsec.
La idea con GET VPN es crear grupos de dispositivos manteniendo un punto centralizado desde donde regir las politicas y SA (Security Associations), en este esquema se maneja un solo SA para todo el grupo no como se hace en las tradicionales VPN, las cuales son Punto a Punto y se requiere un IPsec SA para cada conexión como podemos observar en nuestra imagen:
GET VPN funciona similar a DMVPN en el sentido que habilita la comunicación entre los spokes pero sin generar diferentes IPsec SA, un solo IPsec SA puede ser utilizado para todo el grupo, lo que lo una solución bastante escalable.
¿Como funciona GET VPN?
Para conocer su funcionamiento primero debemos conocer los términos o protocolos claves:
KS = Key Server es punto centralizado de GET VPN, este router es el encargado del registro y autenticación de cada GM (Group Member), también es el encargado de crear y distribuir las políticas necesaria a los GMs, esta política incluye el trafico a encriptar y el algoritmo a utilizar.
GM = Group Member es cualquier router considerado Spoke, ellos son los encargados de encriptar y desencriptar el trafico incluso con el trafico entre los GMs, esto es posible debido a que poseen el mismo IPsec SA.
GDOI = Es un protocolo utilizado entre el KS y los GMs, trabaja con la fase 1 y es el encargado de proveer la protección durante la distribución de las llaves. GDOI utiliza 2 llaves: KEK y TEK.
- KEK = Es utilizado para proveer protección al control plane, encriptando los mensajes rekey, estos mensajes son los encargados de realizar la sincronización con las políticas y llaves. También es utilizado por los GMs para desencriptar los mensajes rekey recibidos desde el Key Server.
- TEK = Es utilizado para la encriptación de los datos. Funciona como IPsec SA y es utilizado por los GMs del mismo grupo.
IPsec = Es un protocolo utilizado para proteger y autenticar la información sobre el protocolo IP. GET VPN utiliza ESP.
GET VPN utiliza el puerto UDP 848
Escenario de configuración
Imaginemos la siguiente topología:
Configuración en el KS
Procedamos paso a paso con la configuración de cada router. Iniciemos con R1 quien sera el RS, a continuación, mostramos los pasos a seguir:
Paso 1) Creamos un nombre de dominio en el router:
ip domain-name <nombre de dominio>
Paso 2) Generar la llave RSA, recomendable como minimo 1024 bits.
crypto key generate rsa [Presionar la tecla de enter o incluir el parámetro: modules <tamaño en bits>]
Paso 3) Crear la fase 1 a traves de secuencia de políticas.
Crypto isakmp policy <secuencia>
authentication <tipo de autenticación>
hash <tipo de algoritmo>
Dentro de la política podemos indicar si utilizaremos PSK o PSI. En nuestro caso sera PSK (Pre Shared Key)
Paso 4) Generar las llaves que se utilizaran con cada GM, estas pueden ser diferente:
crypto isakmp key <llave | contraseña> address <dirección IP del GM>
Paso 5) Crear la fase 2 a traves de IPsec, la configuración es la misma que la utilizada en VPNs ordinarias.
crypto ipsec transform <Nombre> <tipo de encriptación> <tipo de autenticación>
crypto ipsec profile <nombre del perfil>
set transform-set <nombre del transform>
Paso 6: Creamos 2 listas de ACL, una para incluir las direcciones IP de los GM y otra ACL tal como lo hacemos con otras VPN para especificar los permisos entre las redes.
Ip access-list standard <nombre>
permit host a.a.a.a
permit host b.b.b.b
permit host c.c.c.c
etc.
ip access-list extended <nombre>
deny udp any eq 848 any eq 848
permit <permitir lo que deseemos de origen a destino>
Si notamos, es basicamente la mismas arquitectura de comandos utlizadas en las VPN punto a punto pero con ciertas variaciones minimas. Una vez hemos completado la configuración entramos ya en materia configurando los grupos utilizando GDOI:
Paso 7: Creacion del grupo y los paramentros de rekey
crypto gdoi group <nombre del grupo>
identity number <numero de la identidad>
server <tipo de servidor>
rekey restransmit <tiempo de retransmisión en segundos> <numero de retransmisiones>
rekey transport <unicast | multicast>
rekey authentication mypubkey rsa <nombre del equipo con su dominio>
Los rekey pueden trabajar en modalidad unicast y multicast, el uso depende de las características soportadas en la infraestructura. En nuestro caso utilizaremos unicast. mypubkey indica un par de llaves asociadas al equipo local.
El tipo de servidor indica si es local o externo, en nuestro caso utilizaremos local.
Paso 7.1: dentro de la configuración para GDOI incluir la lista de todos los GMs que son parte del grupo.
authorization address ipv4 <ACL con la direccion IP de los GM>
sa ipsec <identificador del IPsec SA>
Paso 7.2: Creación de los parámetros del IPsec SA donde incluiremos información del KS y los GM, también se incluyen los parámetros de IPsec. Cabe mencionar que esto siempre es dentro de la configuración del grupo.
sa ipsec <identificador del IPsec SA>
profile <perfil de IPSEC>
match address <ACL estándar de los GMs>
address ipv4 <dirección IP del KS>
replay counter window-size <tamaño de la ventana> es un método de protección contra transmisiones que tiene un fin malicioso y pueden generar repeticiones o retrasos.
Configuración en los GMs
La configuración en los GM suele ser mas sencilla y se pueden crear scripts para implementarlos en cada router GM.
Paso 1) Crear la politica de isakmp para la fase 1, tal como lo hicimos en el KS
crypto isakmp policy <secuencia>
authentication <tipo de autenticación>
hash <tipo de algoritmo>
Paso 2) Creamos la llave de isakmp a utilizar y la cual sera utilizada para habilitar la comunicación con el KS
crypto isakmp key <llave | contraseña> address <dirección IP del KS>
Paso 3) Crear el grupo al cual pertenece el GM
crypto gdoi group <nombre del grupo>
identity number <identificador del grupo>
server address ipv4 <dirección IP del KS>
Paso 4) Crear un crypto map tipo GDOI para incluir los parámetros previos y luego mapearlo a la interface de salida.
crypto map <nombre del map> <secuencia> gdoi
set group <nombre del grupo>
* Se pueden utilizar ACLs para bloquear cierto trafico que no es requerido entre GMs y luego aplicarlo en el crypto map tipo gdoi.
Paso 5) Aplicar el map a la interface de salida
crypto map <nombre del map>
Apliquemos la configuración pero primero observemos la configuración inicial
R1
R2
R3
R4
Podemos hacer una prueba de comunicación entre loopbacks desde R2 y funcionara la comunicación, pero el objetivo es poder protección para el trafico sin la necesidad de crear túneles y con comunicación directa con todos los nodos, es aquí donde entra GET VPN.
La idea de nuestra topología es simular una conexión a través de una red WAN.
Procedamos con la configuración de KS (R1)
Los parámetros a utilizar en este articulo son los siguientes:
R1
ip domain name midominio.com
crypto isakmp policy 1
authentication pre-share
crypto isakmp key GETVPN address 20.0.0.100
crypto isakmp key GETVPN address 30.0.0.100
crypto ipsec transform-set IPSEC esp-aes esp-sha-hmac
crypto ipsec profile IPSEC-PROFILE
set transform-set IPSEC
crypto gdoi group GETVPN-LAB
identity number 123
server local
rekey retransmit 20 number 5
rekey authentication mypubkey rsa YNH123
rekey transport unicast
authorization address ipv4 GM-ACL
sa ipsec 1
profile IPSEC-PROFILE
match address ipv4 PERMISOS
replay counter window-size 64
address ipv4 100.0.0.100
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
description HACIA-ISP
ip address 100.0.0.100 255.255.255.0
duplex auto
speed auto
ip route 0.0.0.0 0.0.0.0 100.0.0.1
ip access-list standard GM-ACL
permit 20.0.0.100
permit 30.0.0.100
ip access-list extended PERMISOS
deny udp any eq 848 any eq 848
permit ip host 1.1.1.1 host 2.2.2.2
permit ip host 1.1.1.1 host 3.3.3.3
permit ip host 2.2.2.2 host 3.3.3.3
permit ip host 2.2.2.2 host 1.1.1.1
permit ip host 3.3.3.3 host 1.1.1.1
Procedemos con la configuración de los GM, esta configuración es mucho mas sencilla.
R2
R3
R4
Si nuestra configuración es correcta, debemos observar que al aplicar el crypto map se realiza el registro con el KS, con un mensaje de complete de lo contrario puede aparecer failed o el GM intenta registrarse periódicamente.
crypto isakmp policy 1
authentication pre-share
crypto isakmp key GETVPN address 100.0.0.100
crypto gdoi group GETVPN-LAB
identity number 123
server address ipv4 100.0.0.100
crypto map GETVPN-MAP 1 gdoi
set group GETVPN-LAB
!interface FastEthernet0/0
crypto map GETVPN-MAP
La configuración para cada GM es basicamente la misma. Una vez los GM se han registrado con el KS, podemos verificar que los paquetes son protegidos por IPsec.
Verifiquemos la conectividad desde R2 hacia R3 y R4, es importante conocer que unicamente hay protección via IPsec en los GMs el siguiente comando no es aplicable en el KS: show crypto ipsec sa.
Ejecutando el comando: show crypto ipsec sa
Verificación en KS
Podemos utilizar los siguientes comandos:
show crypto gdoi, nos mostrara toda la información acerca del GET VPN, incluyendo la cantidad de equipos registrados en el KS:
show crypto gdoi ks members, con el cual podemos verificar que GMs se han logrado registrar en el KS:
Podemos observar que los 3 GMs se han registrado correctamente.
Con el comando show crypto gdoi group <nombre del grupo>, podemos observar con detalle la información del grupo creado.
Verificación GMs
En los GMs podemos ejecutar:
show crypto gdoi gm acl, para verificar la ACL aplicada en el KS.
A traves del comando show crypto gdoi en los GMs podemos ver con mas detalle la información del GET VPN, incluyendo la policy.
En resumen utilizando GET VPN, podemos proteger nuestro trafico de datos y a la vez comunicarnos con todos los nodos, manteniendo un punto centralizado para las políticas y IPsec SA.
