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. .
.
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.
La topologie logique de l'exemple fourni :
Déploiement initial :
Nous déployons des instances ASAv à partir des images des modèles qui nous intéressent (ASAv5/10/30/50).
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.
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 : -> 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, .
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 :
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-REDISTRIBUTENous 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 :
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
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish