Esta configuración es muy sencilla cuando se encajan todas las piezas. Se debe utilizar FlexVPN en modo cliente/servidor, se puede elegir diferentes modos de autenticación: certificado, radius, tacacs+…En este artículo se utilizará la más sencilla, usuario y contraseñas locales.
Se utilizará un laboratorio ejecutado en el fantástico eve-ng :). El laboratorio utilizado es el siguiente:
Configuración del servidor
Puedes descargar la configuarción completa del servior en este enlace. A partir de aquí nos centraremos en las secciones relevantes para el fín del artículo.
Reglas de acceso
Empezaremos por las ACL y el pool utilizado para asignar direcciones a los clientes VPN:
ip local pool FlexVPNPool 10.10.10.1 10.10.10.254 recycle delay 60 ! ip access-list standard ServerNetwork permit 10.0.0.0 0.0.0.255 ! ip access-list extended Client1-ACL permit icmp host 10.0.0.3 192.168.1.0 0.0.0.255 echo permit icmp host 192.168.1.0 0.0.0.252 10.0.0.3 echo-reply permit tcp host 10.0.0.3 192.168.1.0 0.0.0.255 eq 22 deny ip any any ip access-list extended Client2-ACL permit icmp host 10.0.0.3 192.168.2.0 0.0.0.255 echo permit icmp host 192.168.2.0 0.0.0.252 10.0.0.3 echo-reply permit tcp host 10.0.0.3 192.168.2.0 0.0.0.255 eq 22 deny ip any any
Se ha elegido segmentar las reglas de acceso de cada cliente, pero se podría utilizar una genérica para todos. Hemos elegido esta arquitectura, que se replicará en otros elementos, para evitar que errores de configuración de un nuevo túnel, pueda afectar a túneles ya configurados. Se utiliza un único pool «FlexVPNPool» para todos los clientes, se podría usar uno para cada cliente, si se desea.
En cuanto a la red protegida por el servidor, se define mediante la ACL ServerNetwork, las ACL Client1-ACL y Client2-ACL se utilizan para limitar el tráfico permitido en cada túnel. En caso de haber un firewall entre la red servidor y las redes clientes, no hará falta definir estas reglas.
Política de autorización
A continuación se define la política de autorización utilizada, para este elemento también se ha escogido utiliizar uno compartido, pero se podría usar uno por túnel:
crypto ikev2 authorization policy FlexVPNIKEPOL pool FlexVPNPool route set access-list ServerNetwork
Mediante esta autorización se selecciona el pool a utilizar, es por utilizar un único bloque de autorización que se utiliza una pool compartida. Aquí también se específica el tráfico que será enrutada en el otro extremo, las rutas a inyectar en el cliente, en este caso la red de servidores.
Es el momento de definir las contraseñas de acceso para cada cliente, para ello se utiliza un anillo de claves, que las almacena:
crypto ikev2 keyring KR peer client1 identity fqdn client1.domain.com pre-shared-key local ServerToClient1Key pre-shared-key remote Client1Key ! peer client2 identity fqdn client2.domain.com pre-shared-key local ServerToClient2Key pre-shared-key remote Client2Key
Cada cliente se identificará mediante FQDN, es importante remarcar que en ningún caso se realiza resolución de nombres, tan solo se utilizan como elemento identificativo. Por lo tanto se puede utilizar cualquier combinación, sin necesidad de que cumpla con ningún estándar ni de que exista en ningún servidor DNS. Se puede definir una clave única para local y remoto, si se desea. En este elemento sí
Perfiles ikev2
Ahora se definen los perfiles para cada cliente, en estos bloques también se utiliza el FQDN para identificar a los clientes:
crypto ikev2 profile ikev2-profile match identity remote fqdn client1.domain.com authentication local pre-share authentication remote pre-share keyring local KR aaa authorization group psk list default FlexVPNIKEPOL virtual-template 1 ! crypto ikev2 profile ikev2-profile-client2 match identity remote fqdn client2.domain.com authentication local pre-share authentication remote pre-share keyring local KR aaa authorization group psk list default FlexVPNIKEPOL virtual-template 2
Se ha elegido separar los bloques por cliente, pero se podría definir un bloque único utilizando el dominio del FQDN como elemento identificativo, especificando del match de la siguiente manera:
match identity remote fqdn domain domain.com
Parámetros para IPSEC
A continuación se define la configuración para IPSEC, mediante un único transform-set y un perfil por cliente:
crypto ipsec transform-set transform1 esp-aes mode tunnel ! ! crypto ipsec profile ipsec-profile set transform-set transform1 set ikev2-profile ikev2-profile ! crypto ipsec profile ipsec-profile-client2 set transform-set transform1 set ikev2-profile ikev2-profile-client2
El perfil IPSEC enlaza el cifrado para IPSEC con el utilizado en la fase de intercambio de claves ikev2. Es decir específica qué cifrado se utilziará para la fas1 y la fase2 de la negoaciación.
Interfaces de red
Se finaliza mediante la configuración de las interfaces que intervendrán en el túnel:
interface Loopback0 ip address 10.10.11.1 255.255.255.255 ! interface Virtual-Template1 type tunnel ip unnumbered Loopback0 ip access-group Client1-ACL out tunnel mode ipsec ipv4 tunnel destination dynamic tunnel protection ipsec profile ipsec-profile ! interface Virtual-Template2 type tunnel ip unnumbered Loopback0 ip access-group Client2-ACL out tunnel mode ipsec ipv4 tunnel destination dynamic tunnel protection ipsec profile ipsec-profile-client2
La interfaz Loopback0 se utiliza como orígen para los túneles, es una buena práctica en cisco, ya que es una interfaz que siempre está activa y puede ser accesible desde cualquier interfaz mediante routing. Se suele utiizar como IP de gestión una Loopback, también como buena práctica. La IP de esta interfaz no interviene en el túnel y no tiene por qué coincidir con la pool o con cualquier otra IP del equipo.
Se utiliza un virtual-template para cada túnel, esto sirve para asociar al túnel las reglas de acceso de cada túnel «ip access-group…» y el perfil IPSEC de cada cliente «tunnel protection ipsec…«. En caso de no separar la configuración por cliente, bastaría con una única virtual-template.
Configuración de los clientes
Puedes descargar la configuarción completa de los clientes en el enlace a cliente 1 y en el enlace a cliente 2. A continuación se explican las partes más relevantes para el cliente1, el dos es igual modificando las direcciones IP que intervienen.
Política de autorización
Se define una política de autorización, que especifica las rutas que se inyectarán hacia el servidor:
crypto ikev2 authorization policy FlexVPNIKEPOL route set interface route set remote ipv4 192.168.1.0 255.255.255.0
La sentencia «route set interface» envía la direción del IP del túnel como ruta estática al otro extremo.
Se define un anillo de claves para la gestión de las contraseñas de conexión:
crypto ikev2 keyring KR peer SERVER1 address 172.16.0.3 pre-shared-key local Client1Key pre-shared-key remote ServerToClient1Key
Este paso no es obligatorio, las claves se pueden especificar en el perfil ikev2 directamente.
Perfiles ikev2
Igual que en el servidor se define un perfil ikev2:
crypto ikev2 profile prof match identity remote address 172.16.0.3 255.255.255.255 identity local fqdn client1.domain.com authentication local pre-share authentication remote pre-share keyring local KR aaa authorization group psk list default FlexVPNIKEPOL
En este bloque hay que resaltar varios parámetros:
- match identity remote address: indica la IP externa del otro extremo, normalmente será una IP pública, pero puede ser privada también, en función de las necesidades.
- identity local fqdn: Este parámetro debe coincidir con el nombre que se utiliza en el servidor para identificar al cliente. En caso de que se disponga de una IP fija externa, se puede utilizar esa IP como elemento identificativo del cliente.
- aaa authorization group psk list default: Esta sentencia tiene una doble función, por un lado especifica el nombre de grupo que se utilizará durante la fase de autenticación, debe coincidir con el indicado en el servidor. Por otro lado asocia la política de autorización a utilizar para el túnel.
Parámetros para IPSEC
Al igual que en el servidor o cualquier tipo de túnel IPSec, se deben configurar los parámetros para IPSec:
crypto ipsec transform-set trans esp-aes mode tunnel ! ! crypto ipsec profile ipsecprof set transform-set trans set ikev2-profile prof
Se establecen los parámetros de cifrado y firma para el túnel en el transform-set y mediaten el perfil se enlazan los parámetros para la fase 1 (perfil ikev2) y la fase2 (transform-set).
Interfaces de red
A continuación se define la interfaz túnel a utilizar:
interface Tunnel0 ip address negotiated tunnel source GigabitEthernet0/0 tunnel mode ipsec ipv4 tunnel destination dynamic tunnel protection ipsec profile ipsecprof
La dirección IP será negociada, la proporciona el servidor, como interfaz orígen se utiliza la deseada G0/0 en este caso, podría ser una loopback o cualquier otra interfaz que enrute hacia el servidor.
Se indica que el tunel será de tipo ipsec en ipv4, mediante tunnel destination dynamic indica que se obtendrá de un listado (se configura en el siguiente paso) y se asocia el perfil IPSec a utilizar.
Habilitar flexvpn
En el cliente se debe indicar que se utilizará flexvpn para la conexión:
crypto ikev2 client flexvpn flex peer 1 172.16.0.3 client connect Tunnel0
Se indica a qué extremo se va a conectar, permite indicar más de un extremo y si falla la conexión a uno sigue en orden por cada extremo definido. También indica qué interfaz túnel se va a utilizar para realizar la conexión. Es aquí donde es establecen los valores que utilizará la interfaz túnel para la sentencia «tunnel destination dynamic«