Konfigurieren der ASA IPsec VTI-Verbindung zu Azure
Einleitung
In diesem Dokument wird beschrieben, wie Sie eine Adaptive Security Appliance (ASA) IPsec Virtual Tunnel Interface (VTI)-Verbindung mit Azure konfigurieren.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Eine direkt mit dem Internet verbundene ASA mit einer öffentlichen statischen IPv4-Adresse, die ASA 9.8.1 oder höher ausführt.
- Ein Azure-Konto
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
In ASA 9.8.1 wurde die IPsec-VTI-Funktion erweitert, um IKEv2 zu verwenden. Sie ist jedoch weiterhin auf sVTI IPv4 über IPv4 beschränkt. Dieser Konfigurationsleitfaden wurde unter Verwendung der ASA CLI-Schnittstelle und des Azure-Portals erstellt. Die Konfiguration des Azure-Portals kann auch über PowerShell oder API erfolgen. Weitere Informationen zu den Azure-Konfigurationsmethoden finden Sie in der Azure-Dokumentation.
Hinweis: VTI wird derzeit nur im Routing-Modus mit einem Kontext unterstützt.
Konfigurieren
In diesem Leitfaden wird davon ausgegangen, dass die Azure-Cloud nicht konfiguriert wurde. Einige dieser Schritte können übersprungen werden, wenn die Ressourcen bereits eingerichtet sind.
Schritt 1: Konfigurieren Sie ein Netzwerk in Azure.
Dies ist der Netzwerkadressraum, der sich in der Azure-Cloud befindet. Dieser Adressraum muss groß genug sein, um in ihm Subnetzwerke unterzubringen, wie im Bild gezeigt.
   |
|
Schritt 2: Ändern Sie das virtuelle Netzwerk, um ein Gateway-Subnetz zu erstellen.
Navigieren Sie zum virtuellen Netzwerk, und fügen Sie ein Gateway-Subnetz hinzu. In diesem Beispiel wird 10.1.1.0/24 verwendet.
Schritt 3: Erstellen eines virtuellen Netzwerk-Gateways
Dies ist der VPN-Endpunkt, der in der Cloud gehostet wird. Dies ist das Gerät, mit dem die ASA den IPsec-Tunnel erstellt. Bei diesem Schritt wird auch eine öffentliche IP erstellt, die dem virtuellen Netzwerk-Gateway zugewiesen wird. Dieser Schritt kann 15 bis 20 Minuten in Anspruch nehmen.
 |
|
Schritt 4: Erstellen eines lokalen Netzwerk-Gateways
Ein lokales Netzwerk-Gateway ist die Ressource, die die ASA darstellt.
  |
|
Schritt 5: Erstellen Sie eine neue Verbindung zwischen dem Gateway für das virtuelle Netzwerk und dem Gateway für das lokale Netzwerk, wie im Bild dargestellt.
Schritt 6: Konfigurieren der ASA
Aktivieren Sie zunächst IKEv2 auf der externen Schnittstelle, und konfigurieren Sie die IKEv2-Richtlinien.
crypto ikev2 policy 10 encryption aes-gcm-256 aes-gcm-192 aes-gcm integrity null group 14 5 2 prf sha512 sha384 sha256 sha lifetime seconds 86400 crypto ikev2 policy 20 encryption aes-256 aes-192 aes integrity sha512 sha384 sha256 sha group 14 5 2 prf sha512 sha384 sha256 sha lifetime seconds 86400 crypto ikev2 enable outside
Schritt 6: Konfigurieren eines IPsec-Transformationssatzes und eines IPsec-Profils.
crypto ipsec ikev2 ipsec-proposal AZURE-PROPOSAL protocol esp encryption aes-256 protocol esp integrity sha-256 crypto ipsec profile AZURE-PROPOSAL set ikev2 ipsec-proposal AZURE-PROPOSAL
Schritt 8: Konfigurieren Sie die Tunnelgruppe.
Rufen Sie die öffentliche IPv4-Adresse des Virtual Network Gateway ab, das in Schritt 3 erstellt wurde, wie im Bild gezeigt.
Konfigurieren Sie anschließend auf der ASA eine Gruppenrichtlinie und eine Tunnelgruppe mit dem in Schritt 3 definierten Pre-Shared Key.
group-policy AZURE internal group-policy AZURE attributes vpn-tunnel-protocol ikev2 tunnel-group A.A.A.A type ipsec-l2l tunnel-group A.A.A.A general-attributes default-group-policy AZURE tunnel-group A.A.A.A ipsec-attributes ikev2 remote-authentication pre-shared-key ***** ikev2 local-authentication pre-shared-key *****
Schritt 9. Konfigurieren Sie die Tunnelschnittstelle.
Konfigurieren Sie in Schritt 4 das lokale Netzwerk-Gateway, eine Netzwerkadresse und eine IP-Adresse für die konfigurierte BGP-Verbindung. Dabei handelt es sich um die IP-Adresse und das Netzwerk, die auf dem VTI konfiguriert werden müssen.
interface Tunnel1 nameif AZURE ip address 192.168.100.1 255.255.255.252 tunnel source interface outside tunnel destination A.A.A.A tunnel mode ipsec ipv4 tunnel protection ipsec profile AZURE-PROPOSAL no shutdown
Schritt 10.
Option 1: Konfigurieren von dynamischem Routing. Tauschen Sie Routen mithilfe von BGP mit Azure aus.
Suchen Sie die IP-Adresse des BGP-Routers in Azure, um die Konfiguration des in Schritt 3 erstellten virtuellen Netzwerkgateways anzuzeigen. In diesem Beispiel ist dies 10.1.2.254.
Konfigurieren Sie auf der ASA eine statische Route, die aus dem VTI-Tunnel heraus auf 10.1.2.254 verweist. In diesem Beispiel befindet sich 192.168.100.2 im gleichen Subnetz wie der VTI. Obwohl kein Gerät über diese IP-Adresse verfügt, installiert die ASA die Route, die auf die VTI-Schnittstelle verweist.
route AZURE 10.1.2.254 255.255.255.255 192.168.100.2 1
Konfigurieren Sie dann BGP auf der ASA. Das Netzwerk 192.168.2.0/24 ist die interne Schnittstelle der ASA und eine Route, die in die Cloud propagiert wird. Darüber hinaus werden die in Azure konfigurierten Netzwerke der ASA angekündigt.
router bgp 65000 bgp log-neighbor-changes bgp graceful-restart address-family ipv4 unicast neighbor 10.1.2.254 remote-as 65515 neighbor 10.1.2.254 ebgp-multihop 255 neighbor 10.1.2.254 activate
network 192.168.2.0 network 192.168.100.0 mask 255.255.255.252 no auto-summary no synchronization exit-address-family
Option 2: Konfigurieren von statischem Routing - Konfigurieren Sie Routen sowohl auf der ASA als auch auf Azure statisch. Konfigurieren Sie die ASA so, dass sie Datenverkehr über den VTI-Tunnel an die Azure-Netzwerke sendet.
route AZURE 10.1.0.0 255.255.0.0 192.168.100.2 1
Ändern Sie das in Schritt 4 erstellte Gateway für lokale Netzwerke mit Netzwerken, die sich hinter der ASA und dem Subnetz auf der Tunnelschnittstelle befinden, und fügen Sie die Präfixe im Abschnitt Zusätzliche Netzwerkbereiche hinzufügen hinzu.
Überprüfung
Verwenden Sie diesen Abschnitt, um zu überprüfen, ob Ihre Konfiguration ordnungsgemäß funktioniert.
Schritt 1: Überprüfen Sie, ob eine IKEv2-Sitzung mit dem Befehl show crypto ikev2 sa eingerichtet wurde.
ciscoasa# show crypto ikev2 sa
IKEv2 SAs:
Session-id:6, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
2006974029 B.B.B.B. /500 A.A.A.A/500 READY INITIATOR
Encr: AES-CBC, keysize: 256, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/4640 sec
Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0x74e90416/0xba17723a
Schritt 2: Überprüfen Sie, ob mit dem Befehl show crypto ipsec sa auch eine IPsec-SA ausgehandelt wird.
ciscoasa# show crypto ipsec sa
interface: AZURE
Crypto map tag: __vti-crypto-map-3-0-1, seq num: 65280, local addr: B.B.B.B
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer: A.A.A.A
#pkts encaps: 240, #pkts encrypt: 240, #pkts digest: 240
#pkts decaps: 377, #pkts decrypt: 377, #pkts verify: 377
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 240, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: B.B.B.B/500, remote crypto endpt.: A.A.A.A/500
path mtu 1500, ipsec overhead 78(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: BA17723A
current inbound spi : 74E90416
inbound esp sas:
spi: 0x74E90416 (1961427990)
SA State: active
transform: esp-aes-256 esp-sha-256-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, VTI, }
slot: 0, conn_id: 1722, crypto-map: __vti-crypto-map-3-0-1
sa timing: remaining key lifetime (kB/sec): (3962863/24100)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0xBA17723A (3122098746)
SA State: active
transform: esp-aes-256 esp-sha-256-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, VTI, }
slot: 0, conn_id: 1722, crypto-map: __vti-crypto-map-3-0-1
sa timing: remaining key lifetime (kB/sec): (4008947/24100)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
ciscoasa#
Schritt 3: Überprüfen Sie die Verbindung über den Tunnel zum BGP-Remote-Router mithilfe von Ping und Ping-TCP, um die Layer-3-Routing- und Layer-4-Verbindungen für BGP oder die Endpunktressourcen zu validieren, wenn Sie statisches Routing verwenden.
ciscoasa# ping 10.1.2.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.2.254, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/50 ms ciscoasa# ping tcp 10.1.2.254 179 Type escape sequence to abort. No source specified. Pinging from identity interface. Sending 5 TCP SYN requests to 10.1.2.254 port 179 from 192.168.100.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 41/42/42 ms ciscoasa#
Schritt 4: Wenn Sie BGP verwenden, überprüfen Sie die empfangenen und an Azure und die Routing-Tabelle der ASA weitergeleiteten BGP-Verbindungsrouten.
ciscoasa# show bgp summary
BGP router identifier 192.168.100.1, local AS number 65000
BGP table version is 6, main routing table version 6
4 network entries using 800 bytes of memory
5 path entries using 400 bytes of memory
2/2 BGP path/bestpath attribute entries using 416 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1640 total bytes of memory
BGP activity 14/10 prefixes, 17/12 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.2.254 4 65515 73 60 6 0 0 01:02:26 3
ciscoasa# show bgp neighbors 10.1.2.254 routes
BGP table version is 6, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.0.0/16 10.1.2.254 0 65515 i <<< This is the virtual network defined in Azure
* 192.168.100.0/30 10.1.2.254 0 65515 i
r> 192.168.100.1/32 10.1.2.254 0 65515 i
Total number of prefixes 3
ciscoasa# show bgp neighbors 10.1.2.254 advertised-routes
BGP table version is 6, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.2.0 0.0.0.0 0 32768 i <<< These are the routes being advertised to Azure
*> 192.168.100.0/30 0.0.0.0 0 32768 i <<<
Total number of prefixes 2
ciscoasa#
ciscoasa# show route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 10.1.251.33 to network 0.0.0.0
S* 0.0.0.0 0.0.0.0 [1/0] via B.B.B.C, outside
B 10.1.0.0 255.255.0.0 [20/0] via 10.1.1.254, 01:03:33
S 10.1.2.254 255.255.255.255 [1/0] via 192.168.100.2, AZURE
C B.B.B.A 255.255.255.224 is directly connected, outside
L B.B.B.B 255.255.255.255 is directly connected, outside
C 192.168.2.0 255.255.255.0 is directly connected, inside
L 192.168.2.2 255.255.255.255 is directly connected, inside
C 192.168.100.0 255.255.255.252 is directly connected, AZURE
L 192.168.100.1 255.255.255.255 is directly connected, AZURE
Schritt 5: Senden Sie einen Ping an ein Gerät über den Tunnel. In diesem Beispiel handelt es sich um ein virtuelles Ubuntu-System, das in Azure ausgeführt wird.
ciscoasa# ping 10.1.0.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.0.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/50 ms
Zeigen Sie jetzt die effektiven Routen auf der Remote-VM an. Sie müssen die von der ASA angekündigten Routen zur Cloud anzeigen, wie im Bild dargestellt.
Fehlerbehebung
Es sind derzeit keine spezifischen Informationen zur Fehlerbehebung für diese Konfiguration verfügbar.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
4.0 |
24-Sep-2024 |
Formatierung aktualisiert. |
3.0 |
19-Mar-2024 |
Aktualisierte technische Inhalte, maschinelle Übersetzung, alternativer Text und Formatierung. |
2.0 |
11-Jul-2022 |
Der Inhalt dieses Datensatzartikels ist weiterhin gültig.
PII entfernt.
Aktualisierungen von Formatierungen, Stilanforderungen, maschineller Übersetzung und Gerunds. |
1.0 |
18-Feb-2019 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)