In diesem Artikel möchte ich eine Schritt-für-Schritt-Anleitung vorstellen, wie man schnell das derzeit am besten skalierbare Modell Remote-Access VPN für den Zugang auf Basis von AnyConnect und Cisco ASA – VPN Load Balancing Cluster.
Einführung: Viele Unternehmen weltweit versuchen aufgrund der aktuellen Situation mit COVID-19, ihre Mitarbeiter in den Homeoffice-Modus zu versetzen. Durch den massenhaften Übergang zur Fernarbeit steigt die Belastung der bestehenden VPN-Gateways der Unternehmen erheblich, und es wird eine sehr schnelle Skalierung benötigt. Auf der anderen Seite müssen viele Unternehmen hastig ein neues Konzept wie die Fernarbeit erlernen.
Um Unternehmen zu helfen, schnell einen benutzerfreundlichen, sicheren und skalierbaren VPN-Zugang für Mitarbeiter zu realisieren, stellt Cisco für einen Zeitraum von bis zu 13 Wochen Lizenzen für den multifunktionalen SSL-VPN-Client AnyConnect zur Verfügung. .
.
Ich habe eine schrittweise Anleitung für eine einfache Implementierung eines VPN-Load-Balancing-Clusters vorbereitet, die als die skalierbarste Technologie für VPNs gilt.
Das folgende Beispiel wird in Bezug auf die verwendeten Authentifizierungs- und Autorisierungsalgorithmen recht einfach sein, bietet jedoch eine gute Möglichkeit für einen schnellen Einstieg (was vielen derzeit fehlt) mit der Möglichkeit zur vertieften Anpassung während der Implementierung.
Kurzinformationen: Die Technologie des VPN-Load-Balancing-Clusters ist weder ein Failover noch eine Clusterfunktion im herkömmlichen Sinne. Diese Technologie ermöglicht es, völlig unterschiedliche ASA-Modelle (mit bestimmten Einschränkungen) zu kombinieren, um die Last von Remote-Access-VPN-Verbindungen zu balancieren. Die Synchronisierung von Sitzungen und Konfigurationen zwischen den Knoten eines solchen Clusters fehlt, jedoch ist eine automatische Lastverteilung von VPN-Verbindungen und die Gewährleistung der Ausfallsicherheit der Verbindungen möglich, solange noch mindestens ein aktiver Knoten im Cluster vorhanden ist. Die Last im Cluster wird automatisch je nach Auslastung der Knoten in Bezug auf die Anzahl der VPN-Sitzungen verteilt.
Um die Ausfallsicherheit spezifischer Knoten im Cluster sicherzustellen (falls erforderlich), kann ein Filever verwendet werden, sodass die aktive Verbindung von der primären Knoten des Filevers verarbeitet wird. Ein Filever ist keine zwingende Voraussetzung zur Gewährleistung der Ausfallsicherheit innerhalb eines Load-Balancing-Clusters; der Cluster selbst wird im Falle eines Knotenausfalls die Benutzersitzung auf einen anderen aktiven Knoten übertragen, jedoch ohne den Verbindungsstatus zu speichern, was durch den Filever gewährleistet wird. Daher können diese beiden Technologien bei Bedarf kombiniert werden.
Ein VPN-Load-Balancing-Cluster kann mehr als zwei Knoten enthalten.
Der VPN-Load-Balancing-Cluster wird auf ASA 5512-X und höher unterstützt.
Da jede ASA innerhalb des VPN-Load-Balancing-Clusters als unabhängige Einheit hinsichtlich der vorgenommenen Einstellungen betrachtet wird, führen wir alle Konfigurationsschritte individuell auf jedem einzelnen Gerät durch.
Logische Topologie des dargestellten Beispiels:
Erstbereitstellung:
Wir stellen Instanzen von ASAv aus den benötigten Vorlagen (ASAv5/10/30/50) aus dem Image bereit.
Wir ordnen die Schnittstellen INSIDE/OUTSIDE den gleichen VLANs zu (Outside in seinem VLAN, INSIDE in seinem, aber gemeinsam im Cluster, siehe Topologie). Es ist wichtig, dass Schnittstellen desselben Typs sich im selben L2-Segment befinden.
Lizenzen:
- Zum Zeitpunkt der Installation wird ASAv keine Lizenzen haben und die Leistung auf 100 kbit/s begrenzen.
- Um eine Lizenz zu installieren, müssen Sie ein Token in Ihrem Smart-Account generieren: -> Smart Software Licensing
- Klicken Sie im geöffneten Fenster auf die Schaltfläche Neues Token
- Stellen Sie sicher, dass im geöffneten Fenster das Feld aktiv ist und das Häkchen gesetzt ist Exportkontrollierte Funktionalität zulassen… Ohne dieses aktive Feld können Sie starke Verschlüsselungsfunktionen und entsprechend VPN nicht verwenden. Wenn dieses Feld nicht aktiv ist, wenden Sie sich bitte an Ihr Konto-Team mit der Bitte um Aktivierung.
- Nach dem Klicken auf die Schaltfläche Token erstellen, ein Token wird erstellt, das wir zur Lizenzierung von ASAv verwenden werden. Wir kopieren es:
- Wiederholen Sie die Schritte C, D, E für jede bereitgestellte ASAv.
- Um das Kopieren des Tokens zu erleichtern, aktivieren wir vorübergehend Telnet. Wir konfigurieren jede ASA (das untenstehende Beispiel veranschaulicht die Einstellungen für ASA-1). Telnet funktioniert nicht mit outside. Wenn es unbedingt nötig ist, setzen Sie das security-level auf 100 für outside und stellen Sie es anschließend wieder zurück.
! 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 !- Um das Token im Smart-Account zu registrieren, muss ASA Internetzugang haben. .
Kurz gesagt, ASA benötigt:
- HTTPS-Zugang zum Internet;
- Zeit Synchronisation (idealerweise über NTP);
- einen konfigurierten DNS-Server;
- Wir gehen per Telnet auf unsere ASAs und nehmen die Einstellungen für die Aktivierung der Lizenz über den Smart-Account vor.
! 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 ! ! Überprüfen wir die Funktionsweise des 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: !!!!! ! ! Überprüfen wir die NTP-Synchronisation: ! 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 ! ! Konfigurieren wir unsere ASAv für Smart-Licensing (gemäß Ihrem Profil, in meinem Fall 100M als Beispiel) ! ciscoasa(config)# license smart ciscoasa(config-smart-lic)# feature tier standard ciscoasa(config-smart-lic)# throughput level 100M ! ! Bei Bedarf können Sie den Internetzugang über einen Proxy einrichten, verwenden Sie den folgenden Befehlsblock: !call-home ! http-proxy ip_address port port ! ! Danach fügen wir das aus dem Smart-Account-Portal kopierte Token (<token>) ein und registrieren die Lizenz ! ciscoasa(config)# end ciscoasa# license smart register idtoken <token>- Wir überprüfen, ob das Gerät die Lizenz erfolgreich registriert hat und die Verschlüsselungsoptionen verfügbar sind:
Wir konfigurieren das grundlegende SSL-VPN an jedem Gateway
- Dann richten wir den Zugang über SSH und ASDM ein:
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 ! ! Wir werden den HTTPS-Server für ASDM auf Port 445 aktivieren, um keine Überschneidungen mit dem SSL-VPN-Portal zu haben ! vpn-demo-1(config)# http server enable 445 !- Um ASDM zu verwenden, muss man es zuerst von der Website cisco.com herunterladen; in meinem Fall handelt es sich um die folgende Datei:
- Für die Verwendung des AnyConnect-Clients muss auf jede ASA ein Image für jedes verwendete Desktop-Betriebssystem (geplantes Linux/Windows/MAC) geladen werden; dafür wird eine Datei mit Headend Deployment Package im Namen benötigt:
- Die heruntergeladenen Dateien können beispielsweise auf einem FTP-Server bereitgestellt und auf jede einzelne ASA hochgeladen werden:
- Wir konfigurieren ASDM und ein selbstsigniertes Zertifikat für SSL-VPN (in der Produktivumgebung wird empfohlen, ein vertrauenswürdiges Zertifikat zu verwenden). Der installierte FQDN des virtuellen Clusteradresses (vpn-demo.ashes.cc) sowie jeder FQDN, der mit der externen Adresse jeder Clusterknotens assoziiert ist, müssen in der externen DNS-Zone auf die IP-Adresse des OUTSIDE-Interfaces aufgelöst werden (oder auf die gemappte Adresse, wenn Portweiterleitung für udp/443 (DTLS) und tcp/443 (TLS) verwendet wird). Detaillierte Informationen zu den Anforderungen an das Zertifikat finden Sie im Abschnitt Zertifikatsüberprüfung der Dokumentation.
! 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=de 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 % Der vollständig qualifizierte Domainname im Zertifikat lautet: vpn-demo.ashes.cc Selbstsigniertes Zertifikat generieren? [ja/nein]: ja vpn-demo-1(config)# ! vpn-demo-1(config)# sh cry ca certificates Zertifikat Status: Verfügbar Zertifikatsseriennummer: 4d43725e Zertifikatsnutzung: Allgemeiner Zweck Öffentlicher Schlüsseltpy: RSA (4096 Bit) Signaturalgorithmus: SHA256 mit RSA-Verschlüsselung Ausstellername: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=de Betreffname: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=de Gültigkeitsdatum: startdatum: 00:16:17 MSK 19. März 2020 enddatum: 00:16:17 MSK 17. März 2030 Speicher: config Zuordnete Vertrauenspunkte: SELF CA-Zertifikat Status: Verfügbar Zertifikatsseriennummer: 0509 Zertifikatsnutzung: Allgemeiner Zweck Öffentlicher Schlüsseltpy: RSA (4096 Bit) Signaturalgorithmus: SHA1 mit RSA-Verschlüsselung Ausstellername: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Betreffname: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Gültigkeitsdatum: startdatum: 21:27:00 MSK 24. November 2006 enddatum: 21:23:33 MSK 24. November 2031 Speicher: config Zuordnete Vertrauenspunkte: _SmartCallHome_ServerCA- Um die Funktionsweise von ASDM zu überprüfen, vergessen Sie nicht, den Port anzugeben, zum Beispiel:
- Wir werden die Grundeinstellungen des Tunnels vornehmen:
- Wir ermöglichen den Zugriff auf das Unternehmensnetzwerk über ein Tunnel, während das Internet direkt weitergeleitet wird (dies ist nicht die sicherste Methode, wenn auf dem verbundenen Host keine Sicherheitsvorkehrungen vorhanden sind; es kann zu einer Kompromittierung durch einen infizierten Host und zum Verlust von Unternehmensdaten kommen, Option split-tunnel-policy tunnelall leitet den gesamten Traffic des Hosts in den Tunnel. Dennoch Split-Tunnel ermöglicht es, das VPN-Gateway zu entlasten und den Internettraffic des Hosts nicht zu verarbeiten)
- Wir stellen den Hosts im Tunnel Adressen aus dem Subnetz 192.168.20.0/24 zur Verfügung (Pool von 10 bis 30 Adressen für Node #1). Auf jeder Node des VPN-Clusters sollte der Pool unterschiedlich sein.
- Wir führen eine grundlegende Authentifizierung mit einem lokal erstellten Benutzer auf der ASA durch (dies wird nicht empfohlen, es ist die einfachste Methode); besser ist die Authentifizierung über LDAP/RADIUS, und noch besser ist es, Multi-Factor Authentication (MFA), wie zum Beispiel 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 !- (OPTIONAL): Im obigen Beispiel haben wir einen lokalen Benutzer im ICE für die Authentifizierung von Remotebenutzern verwendet, was natürlich, abgesehen von einem Laboreinsatz, kaum Anwendung findet. Ich werde ein Beispiel geben, wie man die Konfiguration schnell für die Authentifizierung anpasst auf RADIUS einem Server, verwendet wurde Cisco Identity Services Engine:
vpn-demo-1(config-aaa-server-group)# dynamische-Authorization vpn-demo-1(config-aaa-server-group)# vorläufige-Abrechnungsaktualisierung vpn-demo-1(config-aaa-server-group)# aaa-server RADIUS (außen) host 192.168.99.134 vpn-demo-1(config-aaa-server-host)# Schlüssel cisco vpn-demo-1(config-aaa-server-host)# beenden vpn-demo-1(config)# Tunnel-Gruppe DefaultWEBVPNGroup allgemeine-Attribute vpn-demo-1(config-tunnel-general)# Authentifizierungsserver-Gruppe RADIUS !Diese Integration ermöglicht es nicht nur, das Authentifizierungsverfahren schnell mit dem AD-Verzeichnisdienst zu integrieren, sondern auch, die Zugehörigkeit des angeschlossenen Computers zum AD zu unterscheiden und zu erkennen, ob es sich um ein Unternehmensgerät oder ein persönliches Gerät handelt, sowie den Zustand des angeschlossenen Geräts zu bewerten.
- Lassen Sie uns Transparent NAT einrichten, damit der Datenverkehr zwischen dem Client und den Ressourcen des Unternehmensnetzwerks nicht übersetzt wird:
vpn-demo-1(config-network-object)# subnet 192.168.20.0 255.255.255.0 ! vpn-demo-1(config)# nat (innen, außen) Quelle statisch any any Ziel statisch vpn-users vpn-users no-proxy-arp- (OPTIONAL): Um unsere Kunden über ASA ins Internet zu entlassen (bei Verwendung von tunnelall Optionen) unter Verwendung von PAT und um über dasselbe OUTSIDE-Interface auszugehen, über das sie sich verbinden, müssen die folgenden Einstellungen vorgenommen werden
vpn-demo-1(config-network-object)# nat (außen, außen) Quelle dynamisch vpn-users Schnittstelle vpn-demo-1(config)# nat (innen, außen) Quelle dynamisch any Schnittstelle vpn-demo-1(config)# gleicher-Sicherheitsverkehr Erlauben intra-Schnittstelle !- Es ist äußerst wichtig, beim Einsatz eines Clusters sicherzustellen, dass das interne Netzwerk versteht, an welche ASA der Rückverkehr zu den Nutzern geroutet werden soll. Dafür muss eine Redistribution der /32 Adressen, die an die Kunden vergeben werden, durchgeführt werden.
Aktuell haben wir den Cluster noch nicht konfiguriert, aber wir verfügen bereits über funktionierende VPN-Gateways, zu denen man sich individuell über FQDN oder IP verbinden kann.
Wir sehen den verbundenen Kunden in der Routing-Tabelle der ersten ASA:
Damit unser gesamter VPN-Cluster und das gesamte Unternehmensnetzwerk die Route zu unserem Kunden kennen, werden wir den Kunden-Prefix in das Protokoll der dynamischen Routenverteilung integrieren, beispielsweise 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-REDISTRIBUTEJetzt haben wir eine Route zum Kunden über das zweite ASA-2-Gateway, und Benutzer, die mit verschiedenen VPN-Gateways innerhalb des Clusters verbunden sind, können beispielsweise direkt über die Unternehmenssoftware kommunizieren. Der Rückverkehr von den angeforderten Ressourcen kommt ebenfalls am entsprechenden VPN-Gateway an:
Lassen Sie uns mit der Einrichtung des Load-Balancing-Clusters fortfahren.
Die Adresse 192.168.31.40 wird als Virtual IP (VIP — zu der alle VPN-Clients zuerst verbinden) verwendet. Von dieser Adresse wird der Master des Clusters eine REDIRECT zu einem weniger belasteten Knoten des Clusters durchführen. Vergessen Sie nicht, die direkte und umgekehrte DNS-Eintragung sowohl für jede externe Adresse/FQDN jedes Knotens im Cluster als auch für das VIP einzutragen.
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)#- Überprüfen wir die Funktionsweise des Clusters mit zwei verbundenen Clients:
- Wir gestalten die Benutzererfahrung für den Kunden komfortabler, indem wir das AnyConnect-Profil automatisch über ASDM laden.
Wir benennen das Profil sinnvoll und verknüpfen unsere Gruppennutzungsrichtlinien damit:
Nach der nächsten Verbindung des Clients wird dieses Profil automatisch heruntergeladen und im AnyConnect-Client installiert, sodass es bei Bedarf einfach aus der Liste ausgewählt werden kann:
Da wir dieses Profil mit ASDM nur auf einer ASA erstellt haben, vergessen Sie nicht, die Schritte auf den anderen ASAs im Cluster zu wiederholen.
Fazit: Auf diese Weise haben wir schnell ein Cluster aus mehreren VPN-Gateways mit automatischer Lastverteilung bereitgestellt. Das Hinzufügen neuer Knoten zum Cluster ist unproblematisch und ermöglicht eine einfache horizontale Skalierung durch das Bereitstellen neuer ASAv-VMs oder die Nutzung von Hardware-ASAs. Der multifunktionale AnyConnect-Client kann die Möglichkeiten für sichere Remote-Verbindungen erheblich erweitern, wobei die Funktion Posture (Zustandsbewertung), die am effektivsten in Kombination mit einem zentralen System zur Kontrolle und Überwachung des Zugangs eingesetzt wird, Identity Services Engine.
Quelle: habr.com
