Déploiement d'un cluster ASA VPN Load-Balancing

Dans cet article, je voudrais fournir un guide étape par étape sur la façon de déployer rapidement le schéma le plus évolutif à ce jour. VPN d'accès à distance basé sur AnyConnect et Cisco ASA – Cluster de répartition de charge VPN.

Introduction : De nombreuses entreprises dans le monde entier, compte tenu de la situation actuelle avec la COVID-19, font des efforts pour transférer leurs employés en mode de travail à distance. En raison de la masse de cette transition vers le travail à distance, la charge sur les passerelles VPN existantes des entreprises augmente de manière critique et il est nécessaire de les évoluer très rapidement. D'autre part, beaucoup d'entreprises doivent apprendre à la hâte ce qu'est le travail à distance.

Pour aider les entreprises à mettre en place un accès VPN pratique, sécurisé et évolutif pour leurs employés dans les plus brefs délais, Cisco propose des licences pour le client SSL-VPN multifonctionnel AnyConnect pendant une durée pouvant aller jusqu'à 13 semaines. Il est également possible d'obtenir ASAv en version d'essai (ASA virtuelle pour hyperviseurs VMWare/Hyper-V/KVM et plates-formes cloud AWS/Azure) auprès de partenaires autorisés ou en contactant les représentants de Cisco qui travaillent avec vous..

La procédure d'obtention des licences AnyConnect COVID-19 est décrite ici..

J'ai préparé un guide étape par étape pour un déploiement simple d'un cluster de répartition de charge VPN comme la technologie VPN la plus évolutive.

L'exemple ci-dessous sera assez simple en termes d'algorithmes d'authentification et d'autorisation utilisés, mais sera un bon point de départ (ce qui fait défaut à beaucoup en ce moment) avec la possibilité d'une adaptation approfondie en fonction de vos besoins lors du déploiement.

Informations succinctes : La technologie Cluster de répartition de charge VPN n'est pas un basculement et n'est pas une fonction de clustering au sens natif, cette technologie permet de regrouper différents modèles ASA (avec certaines limitations) en vue de la répartition de charge des connexions VPN d'accès à distance. La synchronisation des sessions et des configurations entre les nœuds de ce cluster est absente, mais une répartition automatique de la charge des connexions VPN et une garantie de disponibilité des connexions VPN sont possibles tant qu'il reste au moins un nœud actif dans le cluster. La charge dans le cluster est répartie automatiquement en fonction de l'utilisation des nœuds par le nombre de sessions VPN.

Pour assurer la redondance des nœuds spécifiques du cluster (si nécessaire), on peut utiliser un file-over, de sorte que la connexion active soit gérée par le nœud primaire du file-over. Le file-over n'est pas une condition nécessaire à la redondance au sein du cluster de répartition de charge, le cluster lui-même, en cas de défaillance d'un nœud, transférera la session utilisateur vers un autre nœud actif, mais sans conserver l'état de la connexion, ce que garantit justement le file-over. Par conséquent, il est possible de combiner ces deux technologies si besoin.

Un cluster de répartition de charge VPN peut contenir plus de deux nœuds.

Le cluster de répartition de charge VPN est pris en charge sur ASA 5512-X et versions supérieures.

Étant donné que chaque ASA au sein d'un cluster de répartition de charge VPN est une unité indépendante en ce qui concerne les configurations, toutes les étapes de la configuration sont effectuées individuellement sur chaque appareil.

Détails de la technologie ici

La topologie logique de l'exemple fourni :

Déploiement initial :

1. Nous déployons des instances ASAv à partir des images des modèles qui nous intéressent (ASAv5/10/30/50).

2. Nous attribuons les interfaces INSIDE/OUTSIDE aux VLAN identiques (Outside dans son propre VLAN, INSIDE dans le sien, mais commun dans le cadre du cluster, voir la topologie), il est important que les interfaces d'un même type soient dans le même segment L2.

3. Licences :

   • Au moment de l'installation, ASAv n'aura aucune licence et sera limitée à une performance de 100 kbit/s.
   • Pour installer la licence, vous devez générer un jeton dans votre compte Smart-Account : https://software.cisco.com/ -> Smart Software Licensing
   • Dans la fenêtre qui s'ouvre, cliquez sur le bouton Nouveau jeton

   

   • Assurez-vous que dans la fenêtre ouverte, il y a un champ actif et que la case est cochée Autoriser la fonctionnalité contrôlée par exportation… Sans ce champ actif, vous ne pourrez pas utiliser les fonctions de cryptage fort et donc VPN. Si ce champ n'est pas actif, veuillez contacter votre équipe de comptes pour demander son activation.

   

   • Après avoir cliqué sur le bouton Créer un jeton, un jeton sera créé que nous utiliserons pour obtenir la licence pour ASAv, nous le copierons :

   

   • Répétez les étapes C, D, E pour chaque ASAv déployée.
   • Pour faciliter la copie du jeton, nous allons temporairement autoriser telnet. Nous configurerons chaque ASA (l'exemple ci-dessous illustre les configurations sur ASA-1). telnet depuis l'extérieur ne fonctionne pas, si vraiment nécessaire, changez le niveau de sécurité à 100 sur l'extérieur, puis revenez en arrière.

   !
   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
   !

   • Pour enregistrer le jeton dans le cloud Smart-Account, il est nécessaire d'accorder un accès Internet à l'ASA, les détails ici.

   En résumé, l'ASA a besoin de :

   • un accès HTTPS à Internet ;
   • une synchronisation horaire (de préférence via NTP) ;
   • un serveur DNS configuré ;
     • Nous nous connectons par telnet à nos ASA et effectuons les réglages pour activer la licence via 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 
   !
   ! Vérifions le bon fonctionnement du 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:
   !!!!!
   !
   ! Vérifions la synchronisation 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 (synced), # master (unsynced), + selected, - candidate, ~ configured
   !
   ! Configurons notre ASAv pour Smart-Licensing (selon votre profil, dans mon cas 100M à titre d'exemple)
   !
   ciscoasa(config)# license smart
   ciscoasa(config-smart-lic)# feature tier standard
   ciscoasa(config-smart-lic)# throughput level 100M
   !
   ! Si nécessaire, vous pouvez configurer l'accès Internet via un proxy, utilisez le bloc de commandes suivant :
   !call-home
   !  http-proxy ip_address port port
   !
   ! Ensuite, nous insérons le jeton copié depuis le portail Smart-Account (<token>) et enregistrons la licence
   !
   ciscoasa(config)# end
   ciscoasa# license smart register idtoken <token>

   • Vérifions que l'appareil a bien enregistré la licence et que les options de cryptage sont disponibles :

   

   

4. Configurons un VPN SSL de base sur chaque passerelle

   • Ensuite, configurons l'accès via SSH et 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
   !
   ! Démarrons le serveur HTTPS pour ASDM sur le port 445 afin de ne pas entrer en conflit avec le portail SSL-VPN
   !
   vpn-demo-1(config)# http server enable 445 
   !

   • Pour faire fonctionner ASDM, il faut d'abord le télécharger depuis le site cisco.com, dans mon cas, il s'agit du fichier suivant :

   

   • Pour faire fonctionner le client AnyConnect, il est nécessaire de télécharger sur chaque ASA une image pour chaque système d'exploitation de bureau utilisé (prévu pour Linux/Windows/MAC), il faudra un fichier avec Package de Déploiement Headend dans le nom :

   

   • Les fichiers téléchargés peuvent être téléchargés, par exemple, sur un serveur FTP et transférés sur chaque ASA :

   

   • Configurez ASDM et le certificat auto-signé pour le SSL-VPN (il est recommandé d'utiliser un certificat de confiance en production). Le FQDN configuré de l'adresse virtuelle du cluster (vpn-demo.ashes.cc), ainsi que chaque FQDN associé à l'adresse externe de chaque nœud du cluster doit être résolu dans la zone DNS externe sur l'adresse IP de l'interface OUTSIDE (ou sur l'adresse mappée, si un transfert de port udp/443 (DTLS) et tcp/443 (TLS) est utilisé). Des informations détaillées sur les exigences relatives au certificat sont indiquées dans la section Vérification du Certificat la documentation.

   !
   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
   % Le nom de domaine complètement qualifié dans le certificat sera : vpn-demo.ashes.cc
   Générer un certificat auto-signé ? [yes/no]: yes
   vpn-demo-1(config)# 
   !
   vpn-demo-1(config)# sh cry ca certificates 
   Certificat
   Statut : Disponible
   Numéro de Série du Certificat : 4d43725e
   Utilisation du Certificat : Usage Général
   Type de Clé Publique : RSA (4096 bits)
   Algorithme de Signature : SHA256 avec Chiffrement RSA
   Nom de l'Émetteur : 
   serialNumber=9A439T02F95
   hostname=vpn-demo.ashes.cc
   cn=*.ashes.cc
   ou=ashes-lab
   o=ashes
   c=ru
   Nom du Sujet :
   serialNumber=9A439T02F95
   hostname=vpn-demo.ashes.cc
   cn=*.ashes.cc
   ou=ashes-lab
   o=ashes
   c=ru
   Date de Validité : 
   date de début : 00:16:17 MSK Mar 19 2020
   date de fin : 00:16:17 MSK Mar 17 2030
   Stockage : config
   Points de Confiance Associés : SELF 
   
   Certificat CA
   Statut : Disponible
   Numéro de Série du Certificat : 0509
   Utilisation du Certificat : Usage Général
   Type de Clé Publique : RSA (4096 bits)
   Algorithme de Signature : SHA1 avec Chiffrement RSA
   Nom de l'Émetteur : 
   cn=QuoVadis Root CA 2
   o=QuoVadis Limited
   c=BM
   Nom du Sujet : 
   cn=QuoVadis Root CA 2
   o=QuoVadis Limited
   c=BM
   Date de Validité : 
   date de début : 21:27:00 MSK Nov 24 2006
   date de fin : 21:23:33 MSK Nov 24 2031
   Stockage : config
   Points de Confiance Associés : _SmartCallHome_ServerCA               

   • Pour vérifier le fonctionnement d'ASDM, n'oubliez pas d'indiquer le port, par exemple :

   

   • Nous allons effectuer les configurations de base du tunnel :
   • Rendons le réseau d'entreprise accessible via le tunnel, tandis que l'Internet sera accessible directement (ce n'est pas la méthode la plus sûre en l'absence de mesures de protection sur l'hôte connecté, une intrusion par un hôte infecté est possible et des données d'entreprise peuvent être compromises, option split-tunnel-policy tunnelall aurachemise tout le trafic de l'hôte dans le tunnel. Cela dit, Le Split-Tunnel permet de décharger la passerelle VPN et de ne pas traiter le trafic Internet de l'hôte)
   • Nous attribuerons aux hôtes dans le tunnel des adresses du sous-réseau 192.168.20.0/24 (pool avec 10 à 30 adresses (pour le nœud #1)). Chaque nœud du cluster VPN doit avoir son propre pool.
   • Nous allons effectuer une authentification de base avec un utilisateur créé localement sur l'ASA (ce n'est pas recommandé, c'est la méthode la plus simple), il est préférable de faire l'authentification via LDAP/RADIUS, et encore mieux de lier Multi-Factor Authentication (MFA), par exemple 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
   !

   • (OPTIONNEL): Dans l'exemple ci-dessus, nous avons utilisé un utilisateur local sur l'ASA pour authentifier des utilisateurs distants, ce qui, bien sûr, à part en laboratoire, n'est guère applicable. Je vais donner un exemple de la façon d'adapter rapidement la configuration pour l'authentification sur RADIUS le serveur, pour l'exemple c'est utilisé 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 
   !

   Cette intégration a permis non seulement d'intégrer rapidement la procédure d'authentification avec le service d'annuaire AD, mais aussi de différencier l'appartenance de l'ordinateur connecté à l'AD, de comprendre si c'est un appareil d'entreprise ou personnel et d'évaluer l'état de l'appareil connecté.

   

   

   • Faisons une configuration de NAT Transparent pour que le trafic entre le client et les ressources du réseau d'entreprise ne soit pas NATé :

   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

   • (OPTIONNEL) : Pour faire accéder nos clients à Internet via l'ASA (en utilisant tunnelall options) en utilisant PAT, et sortir également par la même interface OUTSIDE, depuis laquelle ils se connectent, il est nécessaire de réaliser les configurations suivantes.

   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
   !

   • Il est extrêmement important, lors de l'utilisation d'un cluster, de permettre au réseau interne de comprendre vers quel ASA router le trafic retour des utilisateurs. Pour cela, il est nécessaire de réaliser la redistribution des routes des adresses /32 attribuées aux clients.
     À ce jour, nous n'avons pas encore configuré le cluster, mais nous avons déjà des passerelles VPN fonctionnelles auxquelles on peut se connecter individuellement par FQDN ou IP.

   

   Nous voyons le client connecté dans la table de routage du premier ASA :

   

   Pour que tout notre cluster VPN et l'ensemble du réseau d'entreprise connaissent le chemin vers notre client, nous allons procéder à la redistribution du préfixe client dans le protocole de routage dynamique, par exemple 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-REDISTRIBUTE

   Nous avons maintenant un chemin vers le client depuis la seconde passerelle ASA-2, et les utilisateurs connectés à différentes passerelles VPN au sein du cluster peuvent, par exemple, communiquer directement via le logiciel de téléphonie de l'entreprise, tout comme le trafic retour des ressources demandées par l'utilisateur arrivera sur la passerelle VPN appropriée :

   

5. Passons à la configuration du Load-Balancing du cluster.

   L'adresse 192.168.31.40 sera utilisée comme IP Virtuelle (VIP — tous les clients VPN se connecteront initialement à celle-ci), à partir de cette adresse, le Maître du cluster fera une REDIRECTION vers un nœud du cluster moins chargé. N'oubliez pas d'indiquer l'enregistrement DNS direct et inverse pour chaque adresse externe/FQDN de chaque nœud du cluster, ainsi que pour le 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)#

   • Nous vérifions le fonctionnement du cluster avec deux clients connectés :

   

   • Améliorons l'expérience utilisateur avec un profil AnyConnect chargé automatiquement via ASDM.

   

   Nommons le profil de manière pratique et associons notre politique de groupe à celui-ci :

   

   Après la prochaine connexion du client, ce profil sera téléchargé et installé automatiquement dans le client AnyConnect, il suffira alors de le sélectionner dans la liste si nécessaire :

   

   Comme nous avons créé ce profil uniquement sur une ASA à l'aide d'ASDM, n'oubliez pas de répéter les étapes sur les autres ASA du cluster.

Conclusion : Ainsi, nous avons rapidement déployé un cluster de plusieurs passerelles VPN avec équilibrage de charge automatique. Ajouter de nouveaux nœuds au cluster est facile, en obtenant un simple redimensionnement horizontal en déployant de nouvelles machines virtuelles ASAv ou en utilisant des ASA matériels. Le client polyvalent AnyConnect peut considérablement étendre les capacités de connexion sécurisée à distance grâce à la fonction Posture (évaluation de l'état), qui est le plus efficace lorsqu'elle est utilisée conjointement avec le système de contrôle centralisé et de suivi des accès Identity Services Engine.

Source : habr.com