Freigeben über


Verwenden von S2S-VPN als Sicherung für privates ExpressRoute-Peering

Im Artikel Entwurf für die Notfallwiederherstellung mit privatem ExpressRoute-Peering wurde die Notwendigkeit einer redundanten Konnektivitätslösung erörtert, wenn ein privates ExpressRoute-Peering verwendet wird. Außerdem wurde erläutert, wie georedundante ExpressRoute-Leitungen für Hochverfügbarkeit verwendet werden können. In diesem Artikel wird erläutert, wie Sie ein Site-to-Site-VPN (S2S-VPN) als Backup für privates ExpressRoute-Peering nutzen und verwalten können.

Hinweis

Die Verwendung von Site-to-Site-VPN als Sicherungslösung für ExpressRoute-Konnektivität wird nicht empfohlen, wenn Sie latenzempfindliche, unternehmenskritische oder bandbreitenintensive Workloads verwenden. In solchen Fällen ist es ratsam, für die Notfallwiederherstellung mit ExpressRoute Resilienz über mehrere Standorte zu entwerfen, um eine maximale Verfügbarkeit sicherzustellen.

Im Gegensatz zu georedundanten ExpressRoute-Verbindungen können Sie die ExpressRoute/VPN-Kombination für eine Notfallwiederherstellung nur in einem Aktiv/Passiv-Setup verwenden. Bei Verwendung einer Sicherungsnetzwerkkonnektivität im passiven Modus liegt eine große Herausforderung darin, dass die passive Verbindung häufig zusammen mit der primären Verbindung fehlschlägt. Der häufige Grund für die Fehler bei der passiven Verbindung ist die fehlende aktive Verwaltung. Daher konzentrieren wir uns in diesem Artikel darauf, wie Sie die S2S-VPN-Konnektivität als Backup für ein privates ExpressRoute-Peering überprüfen und verwalten können.

Hinweis

Wenn eine bestimmte Route sowohl über ExpressRoute als auch über VPN angekündigt wird, bevorzugt Azure das Routing über ExpressRoute.

In diesem Artikel wird auch beschrieben, wie Sie die Konnektivität aus Azure-Sicht sowie an der Edgeseite des lokalen Netzwerks überprüfen. Die Fähigkeit, die Überprüfung von beiden Seiten aus durchzuführen, ist unabhängig davon hilfreich, ob Sie die lokalen Netzwerkgeräte verwalten, mit denen ein Peering mit den Microsoft-Netzwerkentitäten erfolgt.

Topologiebeispiel

In unserem Setup ist ein lokales Netzwerk über eine ExpressRoute-Leitung und eine S2S-VPN-Verbindung mit einem Azure-Hub-VNet verbunden. Das Azure-Hub-VNet ist wiederum mittels Peering mit einem Spoke-VNet verbunden, wie in der folgenden Abbildung dargestellt:

1

In diesem Setup wird die ExpressRoute-Verbindung auf einem Paar von Edgeroutern des Kunden (Customer Edge, CE) am lokalen Standort beendet. Das lokale Netzwerk ist mit den CE-Routern über ein Paar von Firewalls verbunden, die im Leader-Follower-Modus ausgeführt werden. Die S2S-VPN-Verbindung wird direkt auf den Firewalls beendet.

In der folgenden Tabelle sind die wichtigsten IP-Präfixe der Topologie aufgelistet:

Entität Präfix
Lokales LAN 10.1.11.0/25
Azure-Hub-VNet 10.17.11.0/25
Virtuelles Azure Spoke-Netzwerk 10.17.11.128/26
Lokaler Testserver 10.1.11.10
Test-VM im virtuellen Spoke-Netzwerk 10.17.11.132
Primäre ExpressRoute-Verbindung im P2P-Subnetz 192.168.11.16/30
Sekundäre ExpressRoute-Verbindung im P2P-Subnetz 192.168.11.20/30
Primäre BGP-Peer-IP-Adresse des VPN-Gateways 10.17.11.76
Sekundäre BGP-Peer-IP-Adresse des VPN-Gateways 10.17.11.77
BGP-Peer-IP-Adresse der lokalen Firewall für VPN 192.168.11.88
Primäre CE-Router-I/F für Firewall-IP 192.168.11.0/31
Firewall-I/F für primäre CE-Router-IP 192.168.11.1/31
Sekundäre CE-Router-I/F für Firewall-IP 192.168.11.2/31
Firewall-I/F für sekundäre CE-Router-IP 192.168.11.3/31

In der folgenden Tabelle sind die ASNs der Topologie aufgelistet:

Autonomes System ASN
Lokal 65020
Microsoft Enterprise Edge 12076
VNet-GW (ExR) 65515
VNet-GW (VPN) 65515

Hochverfügbarkeit ohne Asymmetrie

Konfigurieren für Hochverfügbarkeit

Im Artikel Konfigurieren von parallel bestehenden ExpressRoute- und Site-to-Site-Verbindungen wird erläutert, wie Sie parallel bestehende ExpressRoute- und S2S-VPN-Verbindungen einrichten. Wie unter Entwurf für Hochverfügbarkeit mit ExpressRoute erwähnt, wird in unserem Setup die Netzwerkredundanz gewährleistet, um einzelne Fehlerquellen (Single Point of Failure) bis zu den Endpunkten zu vermeiden. Dadurch wird die Hochverfügbarkeit von ExpressRoute verbessert. Außerdem sind die primäre und die sekundäre Verbindung der ExpressRoute-Leitungen aktiv und kündigen die lokalen Präfixe über beide Verbindungen auf dieselbe Weise an.

Die lokale Routenankündigung des primären CE-Routers über die primäre Verbindung der ExpressRoute-Verbindung ist unten dargestellt (Junos-Befehle):

user@SEA-MX03-01> show route advertising-protocol bgp 192.168.11.18 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

Die lokale Routenankündigung des sekundären CE-Routers über die sekundäre Verbindung der ExpressRoute-Verbindung ist unten dargestellt (Junos-Befehle):

user@SEA-MX03-02> show route advertising-protocol bgp 192.168.11.22 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

Um die Hochverfügbarkeit der Sicherungsverbindung zu verbessern, wird das S2S-VPN ebenfalls im Aktiv/Aktiv-Modus konfiguriert. Die Konfiguration des Azure-VPN-Gateways ist unten dargestellt. Beachten Sie, dass die BGP-Peer-IP-Adressen des VPN-Gateways (10.17.11.76 und 10.17.11.77) als Teil der VPN-Konfiguration ebenfalls aufgelistet sind.

2

Die lokale Route wird dem primären und dem sekundären BGP-Peer des VPN-Gateways von den Firewalls angekündigt. Die Routenankündigungen sind unten dargestellt (Junos):

user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.76 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

{primary:node0}
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.77    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

Hinweis

Die Konfiguration des S2S-VPNs im Aktiv/Aktiv-Modus bietet nicht nur Hochverfügbarkeit für die Sicherungsnetzwerkkonnektivität zur Notfallwiederherstellung, sondern auch einen höheren Durchsatz für die Backupkonnektivität. Daher wird empfohlen, das S2S-VPN im Aktiv/Aktiv-Modus zu konfigurieren, weil dadurch mehrere zugrunde liegende Tunnel erstellt werden.

Konfigurieren für den symmetrischen Datenverkehrsfluss

Wie bereits erwähnt, bevorzugt Azure den ExpressRoute-Pfad, wenn eine bestimmte lokale Route sowohl über ExpressRoute als auch über S2S-VPN angekündigt wird. Damit Azure den S2S-VPN-Pfad gegenüber der parallel bestehenden ExpressRoute-Verbindung bevorzugt, müssen Sie spezifischere Routen (längeres Präfix mit größerer Subnetzmaske) über die VPN-Verbindung ankündigen. Wir möchten die VPN-Verbindungen nur als Backup verwenden. Daher steht das Standardverhalten bei der Pfadauswahl von Azure mit unserem Ziel im Einklang.

Wir müssen sicherstellen, dass der Datenverkehr, der von der lokalen Umgebung an Azure geleitet wird, auch den ExpressRoute-Pfad der S2S-VPN-Verbindung vorzieht. Die lokale Standardeinstellung der CE-Router und Firewalls in unserem lokalen Setup ist 100. Wenn wir also die lokale Einstellung der über die privaten ExpressRoute-Peerings empfangenen Routen auf über 100 festlegen, können wir dafür sorgen, dass der für Azure bestimmte Datenverkehr die ExpressRoute-Verbindung bevorzugt.

Die BGP-Konfiguration des primären CE-Routers, der die primäre Verbindung der ExpressRoute-Verbindung beendet, ist unten dargestellt. Beachten Sie, dass der Wert der lokalen Einstellung der Routen, die über die iBGP-Sitzung angekündigt werden, auf 150 festgelegt ist. Ebenso müssen wir sicherstellen, dass die lokale Einstellung des sekundären CE-Routers, der die sekundäre Verbindung der ExpressRoute-Verbindung beendet, auch auf 150 festgelegt ist.

user@SEA-MX03-01> show configuration routing-instances Cust11
description "Customer 11 VRF";
instance-type virtual-router;
interface xe-0/0/0:0.110;
interface ae0.11;
protocols {
  bgp {
    group ibgp {
        type internal;
        local-preference 150;
        neighbor 192.168.11.1;
    }
    group ebgp {
        peer-as 12076;
        bfd-liveness-detection {
            minimum-interval 300;
            multiplier 3;
        }
        neighbor 192.168.11.18;
    }
  }
}

Die Routingtabelle der lokalen Firewalls bestätigt, dass der bevorzugte Pfad für den lokalen Datenverkehr, der für Azure bestimmt ist, über die ExpressRoute-Verbindung im stabilen Zustand verläuft.

user@SEA-SRX42-01> show route table Cust11.inet.0 10.17.11.0/24

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.17.11.0/25      *[BGP/170] 2d 00:34:04, localpref 150
                      AS path: 12076 I, validation-state: unverified
                    > to 192.168.11.0 via reth1.11
                      to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                    [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119
10.17.11.76/32     *[Static/5] 2d 21:12:16
                     > via st0.118
10.17.11.77/32     *[Static/5] 2d 00:41:56
                    > via st0.119
10.17.11.128/26    *[BGP/170] 2d 00:34:04, localpref 150
                       AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.0 via reth1.11
                       to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                     [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119

Aus der obigen Routingtabelle geht hervor, dass für die Hub- und Spoke-VNet-Routen (10.17.11.0/25 und 10.17.11.128/26) die ExpressRoute-Verbindung den VPN-Verbindungen vorgezogen wird. 192.168.11.0 und 192.168.11.2 sind IP-Adressen der Firewallschnittstelle für CE-Router.

Überprüfung des Routenaustauschs über S2S-VPN

Weiter oben in diesem Artikel haben wir die lokale Routenankündigung der Firewalls für den primären und den sekundären BGP-Peer des VPN-Gateways überprüft. Außerdem bestätigen wir, dass Azure-Routen von den Firewalls vom primären und sekundären BGP-Peer des VPN-Gateways empfangen werden.

user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.76 table Cust11.inet.0 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.76                             65515 I
  10.17.11.128/26         10.17.11.76                             65515 I

{primary:node0}
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.77 table Cust11.inet.0    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.77                             65515 I
  10.17.11.128/26         10.17.11.77                             65515 I

Ebenso überprüfen wir, ob lokale Netzwerkroutenpräfixe vom Azure-VPN-Gateway empfangen werden.

PS C:\Users\user> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | where {$_.Network -eq "10.1.11.0/25"} | select Network, NextHop, AsPath, Weight

Network      NextHop       AsPath      Weight
-------      -------       ------      ------
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.76   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.77   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769

Wie oben gezeigt, verfügt das VPN-Gateway über Routen, die sowohl vom primären als auch vom sekundären BGP-Peer des VPN-Gateways empfangen werden. Außerdem sind die über primäre und sekundäre ExpressRoute-Verbindungen empfangenen Routen (bei denen „AsPath“ der Wert „12076“ vorangestellt ist) sichtbar. Um die über VPN-Verbindungen empfangenen Routen zu bestätigen, müssen wir die lokale BGP-Peer-IP-Adresse der Verbindungen kennen. Im vorliegenden Setup lautet die IP-Adresse 192.168.11.88, und wir sehen die von ihr empfangenen Routen.

Als Nächstes überprüfen wir die Routen, die vom Azure-VPN-Gateway für den BGP-Peer für die lokale Firewall (192.168.11.88) angekündigt werden.

PS C:\Users\user> Get-AzVirtualNetworkGatewayAdvertisedRoute -Peer 192.168.11.88 -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn |  select Network, NextHop, AsPath, Weight

Network         NextHop     AsPath Weight
-------         -------     ------ ------
10.17.11.0/25   10.17.11.76 65515       0
10.17.11.128/26 10.17.11.76 65515       0
10.17.11.0/25   10.17.11.77 65515       0
10.17.11.128/26 10.17.11.77 65515       0

Wenn kein Routenaustausch angezeigt wird, deutet dies auf einen Verbindungsfehler hin. Informationen zum Beheben von VPN-Verbindungsproblemen finden Sie unter Problembehandlung: Azure-Site-to-Site-VPN-Verbindung kann nicht hergestellt werden und reagiert nicht mehr.

Testen des Failovers

Nachdem wir den erfolgreichen Routenaustausch über die VPN-Verbindung (Steuerungsebene) bestätigt haben, können wir den Datenverkehr (Datenebene) von der ExpressRoute-Konnektivität auf die VPN-Konnektivität umstellen.

Hinweis

In Produktionsumgebungen müssen Failovertests während der geplanten Netzwerkwartungsarbeiten durchgeführt werden, weil sie zu Dienstunterbrechungen führen können.

Vor der Umstellung des Datenverkehrs verfolgen wir die Route des aktuellen Pfads in unserem Setup vom lokalen Testserver zur Test-VM im Spoke-VNet.

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2    <1 ms    <1 ms    11 ms  192.168.11.0
  3    <1 ms    <1 ms    <1 ms  192.168.11.18
  4     *        *        *     Request timed out.
  5     6 ms     6 ms     5 ms  10.17.11.132

Trace complete.

Die primäre und die sekundäre ExpressRoute-Verbindung im P2P-Subnetz unseres Setups lauten 192.168.11.16/30 und 192.168.11.20/30. In der obigen Routenverfolgung ist in Schritt 3 zu sehen, dass wir auf 192.168.11.18 stoßen. Dies ist die Schnittstellen-IP des primären MSEE. Das Vorhandensein der MSEE-Schnittstelle bestätigt, dass unser aktueller Pfad wie erwartet über die ExpressRoute-Verbindung verläuft.

Wie im Artikel Zurücksetzen von ExpressRoute-Verbindungspeerings beschrieben, verwenden wir die folgenden PowerShell-Befehle, um das primäre und das sekundäre Peering der ExpressRoute-Verbindung zu deaktivieren.

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

Die Dauer der Umstellung beim Failover hängt von der BGP-Konvergenzzeit ab. In unserem Setup dauert die Umstellung beim Failover einige Sekunden (weniger als 10 Sekunden). Nach der Umstellung wird beim Wiederholen der Routenverfolgung der folgende Pfad angezeigt:

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2     *        *        *     Request timed out.
  3     6 ms     7 ms     9 ms  10.17.11.132

Trace complete.

Das Ergebnis der Routenverfolgung bestätigt, dass die Sicherungsverbindung über S2S-VPN aktiv ist und Dienstkontinuität gewährleisten kann, wenn sowohl die primäre als auch die sekundäre ExpressRoute-Verbindung ausfällt. Um die Failovertests abzuschließen, aktivieren wir die ExpressRoute-Verbindungen wieder und normalisieren den Datenverkehrsfluss mithilfe der folgenden Befehle.

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

Um zu bestätigen, dass der Datenverkehr wieder auf ExpressRoute umgestellt wird, wiederholen Sie die Routenverfolgung, und stellen Sie sicher, dass die private ExpressRoute-Peeringverbindung verwendet wird.

Nächste Schritte

ExpressRoute ist für Hochverfügbarkeit ohne einzelne Fehlerquelle im Microsoft-Netzwerk konzipiert. Trotzdem ist eine ExpressRoute-Verbindung auf eine einzige geografische Region und einen Dienstanbieter beschränkt. S2S-VPN kann eine gute passive Sicherungslösung zur Notfallwiederherstellung für eine ExpressRoute-Verbindung sein. Damit eine passive Sicherungsverbindungslösung zuverlässig funktioniert, sind die regelmäßige Wartung der passiven Konfiguration und die periodische Überprüfung der Verbindung wichtig. Sie müssen unbedingt darauf achten, dass die VPN-Konfiguration nicht veraltet und dass die in diesem Artikel beschriebenen Schritte zur Überprüfung und zum Durchführen von Failovertests während des Wartungsfensters regelmäßig (z. B. vierteljährlich) wiederholt werden.

Informationen zum Aktivieren der Überwachung und von Warnungen basierend auf den Metriken des VPN-Gateways finden Sie unter Einrichten von Warnungen zu VPN Gateway-Metriken.

Um die BGP-Konvergenz nach einem ExpressRoute-Fehler zu beschleunigen, konfigurieren Sie BFD über ExpressRoute.