En este artículo, me gustaría presentar una guía paso a paso sobre cómo se puede implementar rápidamente el esquema más escalable en este momento. VPN de Acceso Remoto basado en AnyConnect y Cisco ASA – Clúster de Balanceo de Carga VPN.
Introducción: Muchas empresas en todo el mundo, debido a la situación actual con el COVID-19, están haciendo esfuerzos para trasladar a sus empleados al trabajo remoto. Debido a la masividad de la transición al trabajo remoto, la carga sobre los gateways VPN existentes de las empresas aumenta de manera crítica y se requiere una escalabilidad muy rápida. Por otro lado, muchas empresas se ven obligadas a aprender apresuradamente un concepto como el trabajo remoto.
Para ayudar a las empresas a implementar rápidamente un acceso VPN conveniente, seguro y escalable para sus empleados, Cisco ofrece licencias de hasta 13 semanas para el cliente SSL-VPN multifuncional AnyConnect. .
.
He preparado una guía paso a paso de una opción simple para implementar un clúster de Balanceo de Carga VPN como la tecnología VPN más escalable.
El ejemplo a continuación será bastante simple en términos de algoritmos de autenticación y autorización empleados, pero será una buena opción para un inicio rápido (de lo que muchos carecen en este momento) con la posibilidad de adaptación profunda según sus necesidades durante el proceso de implementación.
Información Breve: La tecnología de Clúster de Balanceo de Carga VPN no es un failover ni una función de clustering en su comprensión nativa; esta tecnología puede combinar diferentes modelos de ASA (con ciertas limitaciones) con el fin de balancear la carga de las conexiones VPN de Acceso Remoto. La sincronización de sesiones y configuraciones entre nodos de este clúster no está presente, pero es posible balancear automáticamente la carga de las conexiones VPN y asegurar la resiliencia de las conexiones VPN mientras quede al menos un nodo activo en el clúster. La carga en el clúster se balancea automáticamente según la carga de los nodos en función del número de sesiones VPN.
Para garantizar la continuidad de ciertos nodos del clúster (si es necesario), se puede utilizar un filever, de modo que la conexión activa sea procesada por el nodo primario del filever. El filever no es un requisito para asegurar la continuidad dentro de un clúster de balanceo de carga; el propio clúster, en caso de fallo de un nodo, transferirá la sesión del usuario a otro nodo activo, aunque sin mantener el estado de la conexión, lo cual es precisamente proporcionado por el filever. Por lo tanto, se pueden combinar estas dos tecnologías según sea necesario.
El clúster de VPN Load-Balancing puede contener más de dos nodos.
El clúster de VPN Load-Balancing es compatible con ASA 5512-X y superiores.
Dado que cada ASA en el clúster de VPN Load-Balancing es una unidad independiente en términos de configuración, llevamos a cabo cada etapa de la configuración de manera individual en cada dispositivo.
Topología lógica del ejemplo dado:
Despliegue inicial:
Desplegamos instancias de ASAv a partir de las imágenes de los templates que necesitamos (ASAv5/10/30/50).
Asignamos las interfaces INSIDE/OUTSIDE a VLANs idénticas (Outside en su propia VLAN, INSIDE en la suya, pero común dentro del clúster, ver topología), es importante que las interfaces del mismo tipo se encuentren en el mismo segmento L2.
Licencias:
- Al momento de la instalación, ASAv no tendrá licencias y estará limitada a un rendimiento de 100 kbit/s.
- Para instalar la licencia, necesita generar un token en su cuenta de Smart-Account: -> Licenciamiento de Software Inteligente
- En la ventana que se abre, haga clic en el botón Nuevo Token
- Asegúrese de que en la ventana que se abre haya un campo activo y esté marcada la casilla Permitir funcionalidades controladas por exportación… Sin este campo activo no podrá utilizar funciones de fuerte cifrado y, en consecuencia, VPN. Si este campo no está activo, por favor contacte a su equipo de cuentas para solicitar la activación.
- Después de hacer clic en el botón Crear Token, se creará un token, que utilizaremos para obtener la licencia de ASAv, lo copiaremos:
- Repetiremos los pasos C, D, E para cada ASAv desplegada.
- Para facilitar la copia del token, permitamos temporalmente telnet. Configuraremos cada ASA (el ejemplo a continuación ilustra la configuración en ASA-1). telnet desde outside no funciona; si es absolutamente necesario, cambie el nivel de seguridad a 100 en outside, luego vuelva a configurarlo.
! ciscoasa(config)# int gi0/0 ciscoasa(config)# nameif outside ciscoasa(config)# ip address 192.168.31.30 255.255.255.0 ciscoasa(config)# no shut ! ciscoasa(config)# int gi0/1 ciscoasa(config)# nameif inside ciscoasa(config)# ip address 192.168.255.2 255.255.255.0 ciscoasa(config)# no shut ! ciscoasa(config)# telnet 0 0 inside ciscoasa(config)# username admin password cisco priv 15 ciscoasa(config)# ena password cisco ciscoasa(config)# aaa authentication telnet console LOCAL ! ciscoasa(config)# route outside 0 0 192.168.31.1 ! ciscoasa(config)# wr !- Para registrar el token en la nube Smart-Account, es necesario proporcionar acceso a Internet para el ASA, .
En breve, se necesita ASA:
- acceso HTTPS a Internet;
- sincronización de tiempo (mejor vía NTP);
- servidor DNS configurado;
- Accedemos por telnet a nuestros ASA y configuramos para activar la licencia a través de Smart-Account.
! ciscoasa(config)# clock set 19:21:00 Mar 18 2020 ciscoasa(config)# clock timezone MSK 3 ciscoasa(config)# ntp server 192.168.99.136 ! ciscoasa(config)# dns domain-lookup outside ciscoasa(config)# DNS server-group DefaultDNS ciscoasa(config-dns-server-group)# name-server 192.168.99.132 ! ! Comprobamos el funcionamiento de DNS: ! ciscoasa(config-dns-server-group)# ping ya.ru Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 87.250.250.242, timeout is 2 seconds: !!!!! ! ! Verificamos la sincronización NTP: ! ciscoasa(config)# show ntp associations address ref clock st when poll reach delay offset disp *~192.168.99.136 91.189.94.4 3 63 64 1 36.7 1.85 17.5 * master (sincronizado), # master (no sincronizado), + seleccionado, - candidato, ~ configurado ! ! Establecemos la configuración de nuestro ASAv para Smart-Licensing (según su perfil, en mi caso 100M como ejemplo) ! ciscoasa(config)# license smart ciscoasa(config-smart-lic)# feature tier standard ciscoasa(config-smart-lic)# throughput level 100M ! ! Si es necesario, se puede configurar acceso a Internet a través de un proxy usando el siguiente bloque de comandos: !call-home ! http-proxy ip_address port port ! ! A continuación, insertamos el token copiado del portal Smart-Account (<token>) y registramos la licencia ! ciscoasa(config)# end ciscoasa# license smart register idtoken <token>- Verificamos que el dispositivo ha registrado con éxito la licencia y que las opciones de cifrado están disponibles:
Configuramos un SSL-VPN básico en cada puerta de enlace
- A continuación, configuramos el acceso a través de SSH y ASDM:
ciscoasa(config)# ssh ver 2 ciscoasa(config)# aaa authentication ssh console LOCAL ciscoasa(config)# aaa authentication http console LOCAL ciscoasa(config)# hostname vpn-demo-1 vpn-demo-1(config)# domain-name ashes.cc vpn-demo-1(config)# cry key gen rsa general-keys modulus 4096 vpn-demo-1(config)# ssh 0 0 inside vpn-demo-1(config)# http 0 0 inside ! ! Levantamos el servidor HTTPS para ASDM en el puerto 445 para no interferir con el portal SSL-VPN ! vpn-demo-1(config)# http server enable 445 !- Para utilizar ASDM, primero hay que descargarlo desde el sitio cisco.com, en mi caso es el siguiente archivo:
- Para que el cliente AnyConnect funcione, es necesario cargar en cada ASA la imagen para cada sistema operativo de escritorio que se utilizará (se planifica utilizar Linux/Windows/MAC) se requerirá un archivo con Paquete de Implementación Headend en el nombre:
- Los archivos descargados pueden ser subidos, por ejemplo, a un servidor FTP y cargados en cada ASA individual:
- Configuramos ASDM y certificado autofirmado para SSL-VPN (en producción se recomienda utilizar un certificado confiable). El FQDN establecido de la dirección del clúster virtual (vpn-demo.ashes.cc), así como cada FQDN asociado con la dirección externa de cada nodo del clúster, debe resolverse en la zona DNS externa a la dirección IP de la interfaz OUTSIDE (o a la dirección mapeada, si se utiliza el reenvío del puerto udp/443 (DTLS) y tcp/443 (TLS)). La información detallada sobre los requisitos del certificado se indica en la sección Verificación de Certificado la documentación.
! vpn-demo-1(config)# crypto ca trustpoint SELF vpn-demo-1(config-ca-trustpoint)# enrollment self vpn-demo-1(config-ca-trustpoint)# fqdn vpn-demo.ashes.cc vpn-demo-1(config-ca-trustpoint)# subject-name cn=*.ashes.cc, ou=ashes-lab, o=ashes, c=ru vpn-demo-1(config-ca-trustpoint)# serial-number vpn-demo-1(config-ca-trustpoint)# crl configure vpn-demo-1(config-ca-crl)# cry ca enroll SELF % El nombre de dominio totalmente calificado en el certificado será: vpn-demo.ashes.cc ¿Generar certificado autofirmado? [yes/no]: yes vpn-demo-1(config)# ! vpn-demo-1(config)# sh cry ca certificates Certificado Estado: Disponible Número de serie del certificado: 4d43725e Uso del certificado: Propósito General Tipo de clave pública: RSA (4096 bits) Algoritmo de firma: SHA256 con cifrado RSA Nombre del emisor: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Nombre del sujeto: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Fecha de validez: fecha de inicio: 00:16:17 MSK Mar 19 2020 fecha de finalización: 00:16:17 MSK Mar 17 2030 Almacenamiento: config Puntos de confianza asociados: SELF Certificado CA Estado: Disponible Número de serie del certificado: 0509 Uso del certificado: Propósito General Tipo de clave pública: RSA (4096 bits) Algoritmo de firma: SHA1 con cifrado RSA Nombre del emisor: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Nombre del sujeto: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Fecha de validez: fecha de inicio: 21:27:00 MSK Nov 24 2006 fecha de finalización: 21:23:33 MSK Nov 24 2031 Almacenamiento: config Puntos de confianza asociados: _SmartCallHome_ServerCA- Para verificar el funcionamiento de ASDM, no se olvide de especificar el puerto, por ejemplo:
- Realizaremos la configuración básica de la túnel:
- Haremos que la red corporativa sea accesible a través del túnel, mientras que la Internet se conectará directamente (no es el método más seguro en ausencia de medidas de seguridad en el host conectado, puede haber intrusiones a través de un host comprometido y fuga de datos corporativos, opción split-tunnel-policy tunnelall enviará todo el tráfico del host al túnel. Sin embargo, Split-Tunnel permite descargar la carga del gateway VPN y no procesar el tráfico de Internet del host)
- Asignaremos a los hosts en el túnel direcciones de la subred 192.168.20.0/24 (rango de 10 a 30 direcciones (para el nodo #1)). En cada nodo del clúster VPN, debe haber un propio grupo.
- Realizaremos una autenticación básica con un usuario creado localmente en ASA (esto no se recomienda, es el método más sencillo), lo mejor es hacer la autenticación a través de LDAP/RADIUS, y aún mejor, vincular la Autenticación Multifactor (MFA), por ejemplo Cisco DUO.
! vpn-demo-1(config)# ip local pool vpn-pool 192.168.20.10-192.168.20.30 mask 255.255.255.0 ! vpn-demo-1(config)# access-list split-tunnel standard permit 192.168.0.0 255.255.0.0 ! vpn-demo-1(config)# group-policy SSL-VPN-GROUP-POLICY internal vpn-demo-1(config)# group-policy SSL-VPN-GROUP-POLICY attributes vpn-demo-1(config-group-policy)# vpn-tunnel-protocol ssl-client vpn-demo-1(config-group-policy)# split-tunnel-policy tunnelspecified vpn-demo-1(config-group-policy)# split-tunnel-network-list value split-tunnel vpn-demo-1(config-group-policy)# dns-server value 192.168.99.132 vpn-demo-1(config-group-policy)# default-domain value ashes.cc vpn-demo-1(config)# tunnel-group DefaultWEBVPNGroup general-attributes vpn-demo-1(config-tunnel-general)# default-group-policy SSL-VPN-GROUP-POLICY vpn-demo-1(config-tunnel-general)# address-pool vpn-pool ! vpn-demo-1(config)# username dkazakov password cisco vpn-demo-1(config)# username dkazakov attributes vpn-demo-1(config-username)# service-type remote-access ! vpn-demo-1(config)# ssl trust-point SELF vpn-demo-1(config)# webvpn vpn-demo-1(config-webvpn)# enable outside vpn-demo-1(config-webvpn)# anyconnect image disk0:/anyconnect-win-4.8.03036-webdeploy-k9.pkg vpn-demo-1(config-webvpn)# anyconnect enable !- (OPCIONAL): En el ejemplo anterior, utilizamos un usuario local en MSE para autenticar a los usuarios remotos, lo cual, por supuesto, fuera de un laboratorio, tiene poco sentido. Voy a dar un ejemplo de cómo adaptar rápidamente la configuración para la autenticación en RADIUS el servidor, usando como ejemplo Cisco Identity Services Engine:
vpn-demo-1(config-aaa-server-group)# dynamic-authorization vpn-demo-1(config-aaa-server-group)# interim-accounting-update vpn-demo-1(config-aaa-server-group)# aaa-server RADIUS (outside) host 192.168.99.134 vpn-demo-1(config-aaa-server-host)# key cisco vpn-demo-1(config-aaa-server-host)# exit vpn-demo-1(config)# tunnel-group DefaultWEBVPNGroup general-attributes vpn-demo-1(config-tunnel-general)# authentication-server-group RADIUS !Esta integración permitió no solo integrar rápidamente el procedimiento de autenticación con el servicio de directorios de AD, sino también diferenciar la pertenencia de la computadora conectada a AD, entendiendo si se trata de un dispositivo corporativo o personal y evaluando el estado del dispositivo conectado.
- Configuraremos NAT Transparente para que el tráfico entre el cliente y los recursos de la red corporativa no sea traducido:
vpn-demo-1(config-network-object)# subnet 192.168.20.0 255.255.255.0 ! vpn-demo-1(config)# nat (inside,outside) source static any any destination static vpn-users vpn-users no-proxy-arp- (OPCIONAL): Para permitir que nuestros clientes accedan a Internet a través de ASA (usando tunnelall opciones) usando PAT, así como salir a través de la misma interfaz OUTSIDE, desde donde se conectan, se deben hacer las siguientes configuraciones
vpn-demo-1(config-network-object)# nat (outside,outside) source dynamic vpn-users interface vpn-demo-1(config)# nat (inside,outside) source dynamic any interface vpn-demo-1(config)# same-security-traffic permit intra-interface !- Es extremadamente importante al usar un clúster permitir que la red interna entienda a qué ASA enrutar el tráfico de retorno a los usuarios, para ello es necesario redistribuir las rutas /32 asignadas a los clientes.
En este momento, aún no hemos configurado el clúster, pero ya tenemos puertas de enlace VPN operativas a las que se puede conectar individualmente por FQDN o IP.
Vemos al cliente conectado en la tabla de enrutamiento de la primera ASA:
Para que todo nuestro clúster VPN y toda la red corporativa conozcan la ruta hasta nuestro cliente, realizaremos la redistribución del prefijo del cliente en el protocolo de enrutamiento dinámico, por ejemplo, OSPF:
! vpn-demo-1(config)# route-map RMAP-VPN-REDISTRIBUTE permit 1 vpn-demo-1(config-route-map)# match ip address VPN-REDISTRIBUTE ! vpn-demo-1(config)# router ospf 1 vpn-demo-1(config-router)# network 192.168.255.0 255.255.255.0 area 0 vpn-demo-1(config-router)# log-adj-changes vpn-demo-1(config-router)# redistribute static metric 5000 subnets route-map RMAP-VPN-REDISTRIBUTEAhora tenemos una ruta hasta el cliente desde la segunda puerta de enlace ASA-2 y los usuarios conectados a diferentes puertas de enlace VPN dentro del clúster pueden, por ejemplo, comunicarse a través del software corporativo directamente, así como el tráfico de retorno de los recursos solicitados por el usuario llegará a la puerta de enlace VPN adecuada:
Pasamos a la configuración de Load-Balancing del clúster.
La dirección 192.168.31.40 se utilizará como IP Virtual (VIP — a la que se conectarán inicialmente todos los clientes VPN), desde esta dirección el Maestro del clúster hará REDIRECT a un nodo del clúster con menos carga. No olvide configurar los registros DNS directo e inverso tanto para cada dirección externa/FQDN de cada nodo del clúster, como para el VIP.
vpn-demo-1(config)# vpn load-balancing vpn-demo-1(config-load-balancing)# interface lbpublic outside vpn-demo-1(config-load-balancing)# interface lbprivate inside vpn-demo-1(config-load-balancing)# priority 10 vpn-demo-1(config-load-balancing)# cluster ip address 192.168.31.40 vpn-demo-1(config-load-balancing)# cluster port 4000 vpn-demo-1(config-load-balancing)# redirect-fqdn enable vpn-demo-1(config-load-balancing)# cluster key cisco vpn-demo-1(config-load-balancing)# cluster encryption vpn-demo-1(config-load-balancing)# cluster port 9023 vpn-demo-1(config-load-balancing)# participate vpn-demo-1(config-load-balancing)#- Verificamos el funcionamiento del clúster con dos clientes conectados:
- Haremos que la experiencia del cliente sea más cómoda con el perfil de AnyConnect que se carga automáticamente a través de ASDM.
Nombramos el perfil de manera conveniente y lo asociamos con nuestra política grupal:
Después de la próxima conexión del cliente, este perfil se descargará e instalará automáticamente en el cliente de AnyConnect, por lo que solo quedará seleccionarlo de la lista si es necesario:
Dado que, al utilizar ASDM, creamos este perfil solo en una ASA, no olvides repetir los pasos en las demás ASA del clúster.
Salida: De esta manera, desplegamos rápidamente un clúster de múltiples puertas de enlace VPN con balanceo de carga automático. Agregar nuevos nodos al clúster no es difícil, logrando una escalabilidad horizontal simple mediante el despliegue de nuevas máquinas virtuales ASAv o utilizando ASAs de hardware. El cliente multifuncional AnyConnect puede ampliar significativamente las capacidades de conexión remota segura utilizando la función de Posture (evaluación de estado), aplicada de manera más efectiva junto con el sistema de control y contabilidad de acceso centralizado. Identity Services Engine.
Fuente: habr.com
