Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az ExpressRoute privát társviszony-létesítéssel történő vészhelyreállítás tervezése című cikkben a biztonsági mentési kapcsolat megoldásának szükségességét tárgyaltuk az ExpressRoute privát társviszony-létesítés használatakor. Azt is megvitattuk, hogyan használhatók georedundáns ExpressRoute-kapcsolatcsoportok a magas rendelkezésre álláshoz. Ebben a cikkben bemutatjuk, hogyan használható és tartható fenn egy helyek közötti (S2S) VPN tartalékként az ExpressRoute privát peeringhez.
Megjegyzés:
A helyek közötti VPN használata az ExpressRoute-kapcsolat biztonsági mentési megoldásaként nem ajánlott a késésre érzékeny, a kritikus fontosságú vagy a sávszélesség-igényes számítási feladatok kezelésekor. Ilyen esetekben célszerű az ExpressRoute többhelyes rugalmasságával vészhelyreállítást tervezni a maximális rendelkezésre állás biztosítása érdekében.
A georedundáns ExpressRoute-kapcsolatcsoportoktól eltérően csak az ExpressRoute és a VPN vészhelyreállítási kombinációját használhatja aktív-passzív beállításban. A biztonsági mentési hálózati kapcsolatok passzív módban való használatának egyik fő kihívása, hogy a passzív kapcsolat gyakran meghiúsul az elsődleges kapcsolat mellett. A passzív kapcsolat hibáinak gyakori oka az aktív karbantartás hiánya. Ezért ebben a cikkben arra összpontosítunk, hogyan ellenőrizhető és aktívan fenntartható egy olyan S2S VPN-kapcsolat, amely támogatja az ExpressRoute privát társviszony-létesítéshez.
Megjegyzés:
Ha egy adott útvonalat az ExpressRoute-on és a VPN-en keresztül is meghirdetnek, az Azure inkább az ExpressRoute-on keresztüli útválasztást részesíti előnyben.
Ebben a cikkben azt is megtudhatja, hogyan ellenőrizheti a kapcsolatot mind az Azure, mind a helyszíni hálózati peremhálózat szempontjából. A két oldalról történő ellenőrzés lehetősége segít függetlenül attól, hogy ön kezeli-e a Microsoft hálózati entitásaival társviszonyban álló helyszíni hálózati eszközöket.
Példa topológia
A beállításban van egy helyszíni hálózat, amely expressRoute-kapcsolatcsoporton és S2S VPN-kapcsolaton keresztül csatlakozik egy Azure Hub virtuális hálózathoz. Az Azure központi virtuális hálózat viszont össze van kapcsolva egy küllő virtuális hálózattal, ahogy az a diagramon látható.
A beállítás során az ExpressRoute-kapcsolat az ügyfél oldali helyszíni (CE) útválasztók egy párján végződik. A helyszíni LAN egy vezető-követő módban működő tűzfalpár révén csatlakozik a CE-útválasztókhoz. Az S2S VPN közvetlenül leáll a tűzfalakon.
Az alábbi táblázat a topológia fő IP-előtagját sorolja fel:
| Entitás | előtag |
|---|---|
| Helyszíni LAN | 10.1.11.0/25 |
| Azure Hub virtuális hálózat | 10.17.11.0/25 |
| Azure kapcsolati virtuális hálózat | 10.17.11.128/26 |
| Helyszíni tesztkiszolgáló | 10.1.11.10 |
| Küllős virtuális hálózati teszt virtuális gép | 10.17.11.132 |
| ExpressRoute elsődleges kapcsolat P2P alhálózat | 192.168.11.16/30 |
| ExpressRoute másodlagos kapcsolat P2P alhálózat | 192.168.11.20/30 |
| VPN-átjáró elsődleges BGP-társ IP-címe | 10.17.11.76 |
| VPN-átjáró másodlagos BGP-társ IP-címe | 10.17.11.77 |
| Helyszíni tűzfal VPN BGP-társ IP-címe | 192.168.11.88 |
| Elsődleges CE-router interfész a tűzfal IP-címe felé | 192.168.11.0/31 |
| Tűzfal interfész az elsődleges CE-útválasztó IP-címe felé | 192.168.11.1/31 |
| Másodlagos CE router interfész a tűzfal IP-címe felé | 192.168.11.2/31 |
| Interfész a tűzfal és a másodlagos CE útválasztó IP-címe között | 192.168.11.3/31 |
Az alábbi táblázat a topológia ASN-eit sorolja fel:
| Autonóm rendszer | ASN |
|---|---|
| Helyszíni telepítésű | 65020 |
| Microsoft Enterprise Edge | 12076 |
| Virtuális hálózati GW (ExR) | 65515 |
| Virtuális hálózati GW (VPN) | 65515 |
Magas rendelkezésre állás aszimmetrikusság nélkül
Magas rendelkezésre állás konfigurálása
Az ExpressRoute és a helyek közötti párhuzamos kapcsolatok konfigurálása című cikk bemutatja, hogyan állíthat be egyidejű ExpressRoute- és S2S-VPN-kapcsolatokat. Amint azt az ExpressRoute-tal való magas rendelkezésre állás tervezésekor említettük, a beállítás biztosítja a hálózati redundanciát, hogy a végpontokig minden meghibásodási pont kiküszöbölhető legyen, ami javítja az ExpressRoute magas rendelkezésre állását. Emellett az ExpressRoute-kapcsolatcsoportok elsődleges és másodlagos kapcsolatai is aktívak, és mindkét kapcsolaton keresztül azonos módon hirdetik a helyszíni előtagokat.
Az elsődleges CE-útválasztó helyszíni útvonalhirdetése az ExpressRoute-kapcsolatcsoport elsődleges kapcsolatán keresztül az alábbiak szerint jelenik meg (Junos-parancsok):
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
A másodlagos CE-útválasztó helyszíni útvonalhirdetése az ExpressRoute-kapcsolatcsoport másodlagos kapcsolatán keresztül az alábbiak szerint jelenik meg (Junos-parancsok):
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
A biztonsági mentési kapcsolat magas rendelkezésre állásának javítása érdekében az S2S VPN aktív-aktív módban is konfigurálva van. Az Azure VPN Gateway konfigurációja a következőképpen jelenik meg. Vegye figyelembe, hogy a VPN-konfiguráció részeként az átjáró BGP partner IP-címei -- 10.17.11.76 és 10.17.11.77 -- is szerepelnek a listán.
A helyszíni útvonalat a tűzfal meghirdeti a VPN-átjáró elsődleges és másodlagos BGP-társainak. Az útvonalhirdetések a következőképpen jelennek meg (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
Megjegyzés:
Az S2S VPN aktív-aktív módban való konfigurálása nem csak magas rendelkezésre állást biztosít a vészhelyreállítási biztonsági mentési hálózati kapcsolat számára, hanem magasabb átviteli sebességet is biztosít a biztonsági mentési kapcsolathoz. Ezért ajánlott aktív-aktív módban konfigurálni az S2S VPN-t, mivel több mögöttes alagutat hoz létre.
Konfigurálás szimmetrikus forgalomhoz
Megjegyeztük, hogy ha egy adott helyszíni útvonalat az ExpressRoute és az S2S VPN-en keresztül is meghirdetnek, az Azure az ExpressRoute-útvonalat részesíti előnyben. Ahhoz, hogy az Azure az egyidejű ExpressRoute-tal szemben előnyben részesítse az S2S VPN-útvonalat, a VPN-kapcsolaton keresztül konkrétabb útvonalakat (hosszabb előtagot nagyobb alhálózati maszkkal) kell meghirdetnie. Célunk, hogy a VPN-kapcsolatokat csak biztonsági mentésként használjuk. Az Azure alapértelmezett útvonalválasztási viselkedése tehát összhangban van a célkitűzésünkkel.
A mi felelősségünk annak biztosítása, hogy a helyszíni Azure-ba irányuló forgalom az ExpressRoute útvonalát is előnyben részesítse a helyek közötti VPN-en. A helyszíni beállításunkban a CE-útválasztók és tűzfalak alapértelmezett helyi preferenciája 100. Így az ExpressRoute privát kapcsolataikon keresztül fogadott útvonalak helyi preferenciájának 100-nál nagyobbra történő beállításával az Azure-ba irányuló forgalom automatikusan az ExpressRoute-kapcsolatot fogja előnyben részesíteni.
Az ExpressRoute-kapcsolatcsoport elsődleges kapcsolatát megszakító elsődleges CE-útválasztó BGP-konfigurációja az alábbiak szerint jelenik meg. Vegye figyelembe, hogy az iBGP-munkamenet során meghirdetett útvonalak helyi preferenciájának értéke úgy van beállítva, hogy 150-es értéket kapjon. Hasonlóképpen meg kell győződnünk arról, hogy az ExpressRoute-kapcsolatcsoport másodlagos kapcsolatát megszakító másodlagos CE-útválasztó helyi beállítása is 150-ra van konfigurálva.
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;
}
}
}
A helyszíni tűzfalak útválasztási táblázata megerősíti, hogy az Azure-ba irányuló helyszíni forgalom esetében az előnyben részesített útvonal az ExpressRoute-on keresztül halad állandó állapotban.
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
A fenti útvonaltáblában a küllős virtuális hálózati útvonalak esetében –-10.17.11.0/25 és 10.17.11.128/26 - azt látjuk, hogy az ExpressRoute-kapcsolatcsoport előnyben részesül a VPN-kapcsolatoknál. A 192.168.11.0 és 192.168.11.2 IP-címek a CE-útválasztókhoz kapcsolódó tűzfalfelületen találhatók.
Útvonalcsere ellenőrzése S2S VPN-en keresztül
A cikk korábbi részében ellenőriztük a tűzfalak helyszíni útvonalhirdetését a VPN-átjáró elsődleges és másodlagos BGP-társainak. Emellett erősítsük meg, hogy a tűzfalak megkapták az Azure-útvonalakat a VPN-átjáró elsődleges és másodlagos BGP-partnereitől.
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
Hasonlóképpen ellenőrizzük az Azure VPN Gateway által fogadott helyszíni hálózati útvonalelőtagokat is.
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
Ahogy korábban láttuk, a VPN-átjárónak vannak olyan útvonalai, amelyeket a VPN-átjáró elsődleges és másodlagos BGP-társai egyaránt fogadnak. Továbbá rálát az elsődleges és másodlagos ExpressRoute-kapcsolatokon keresztül fogadott útvonalakra is (azok, amelyek AS-útvonala 12076-tal van előtagolva). A VPN-kapcsolatokon keresztül kapott útvonalak megerősítéséhez ismerni kell a kapcsolatok helyszíni BGP-társ IP-címét. A vizsgált beállításban az IP-cím 192.168.11.88, és látjuk a kapott útvonalakat.
Ezután ellenőrizzük az Azure VPN Gateway által meghirdetett útvonalakat a helyszíni BGP-társ tűzfalhoz (192.168.11.88).
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
Az útvonalcserék sikertelensége kapcsolati hibát jelez. Lásd Hibaelhárítás: Ha egy Azure-beli helyek közötti VPN-kapcsolat nem tud csatlakozni és leáll, hogy segítséget kapjon a VPN-kapcsolat hibaelhárításában.
Átállási tesztelés
Most, hogy meggyőződtünk a VPN-kapcsolat (vezérlősík) sikeres útvonalcseréiről, úgy van beállítva, hogy a forgalmat (adatsíkot) az ExpressRoute-kapcsolatról a VPN-kapcsolatra váltsuk.
Megjegyzés:
Éles környezetben a feladatátvételi tesztelést az ütemezett hálózatkarbantartási munkaablakban kell elvégezni, mivel az szolgáltatásromboló lehet.
Mielőtt elvégezzük a forgalom átkapcsolását, kövessük nyomon az útvonalat a helyszíni tesztkiszolgálóról a sugárirányú virtuális hálózat teszt virtuális gépére.
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.
Az elsődleges és a másodlagos ExpressRoute pont–pont kapcsolat alhálózatai a mi beállításunkhoz tartoznak: 192.168.11.16/30 és 192.168.11.20/30. A fenti nyomkövetési útvonalon a 3. lépésben azt látjuk, hogy a 192.168.11.18-at érjük el, amely az elsődleges MSEE interfész IP-címe. Az MSEE interfész jelenléte megerősíti, hogy a várt módon az aktuális útvonal az ExpressRoute-on keresztül halad.
Az ExpressRoute áramkör társviszonyának alaphelyzetbe állításáról beszámolva, a következő PowerShell-parancsokkal tiltsuk le az ExpressRoute áramkör elsődleges és másodlagos társviszonyt.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
A BGP konvergencia idejétől függ az átkapcsolási idő. A beállításban a feladatátvételi kapcsoló néhány másodpercet vesz igénybe (kevesebb, mint 10). A váltás után a traceroute ismétlése a következő elérési utat mutatja:
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.
A nyomkövetési eredmény megerősíti, hogy az S2S VPN-en keresztüli biztonsági mentési kapcsolat aktív, és szolgáltatás-folytonosságot biztosít, ha az elsődleges és a másodlagos ExpressRoute-kapcsolatok is sikertelenek. A feladatátvételi tesztelés elvégzéséhez engedélyezze újra az ExpressRoute-kapcsolatokat, és normalizálja a forgalmi folyamatot az alábbi parancskészlettel.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Annak ellenőrzéséhez, hogy a forgalom vissza van-e kapcsolva az ExpressRoute-ra, ismételje meg a traceroute parancsot, és ellenőrizze, hogy az ExpressRoute privát peering-en megy-e keresztül.
Következő lépések
Az ExpressRoute magas rendelkezésre állásra lett tervezve, a Microsoft-hálózaton belül egyetlen meghibásodási pont nélkül. Az ExpressRoute-kapcsolatcsoport továbbra is egyetlen földrajzi régióra és egy szolgáltatóra korlátozódik. Az S2S VPN jó vészhelyreállítási passzív biztonsági mentési megoldás lehet egy ExpressRoute-kapcsolatcsoport számára. Megbízható passzív biztonsági mentési kapcsolati megoldás esetén fontos a passzív konfiguráció rendszeres karbantartása és a kapcsolat rendszeres ellenőrzése. Fontos, hogy a VPN-konfiguráció ne legyen elavult, és rendszeres időközönként (mondjuk minden negyedévben) ismételje meg az ebben a cikkben ismertetett ellenőrzési és feladatátvételi tesztelési lépéseket a karbantartási időszak során.
A VPN Gateway-metrikákon alapuló figyelés és riasztások engedélyezéséhez tekintse meg a VPN Gateway-metrikák beállítási riasztásait.
Az ExpressRoute-hiba utáni BGP-konvergenciák felgyorsításához konfigurálja a BFD-t az ExpressRoute-on keresztül.