A Virtual WAN útválasztásának részletes bemutatása
Az Azure Virtual WAN egy olyan hálózati megoldás, amely lehetővé teszi a kifinomult hálózati topológiák egyszerű létrehozását: magában foglalja az Azure-régiók közötti útválasztást az Azure-beli virtuális hálózatok és a helyszíni helyek között pont–hely VPN, helyek közötti VPN , ExpressRoute és integrált SDWAN berendezések révén, beleértve a forgalom védelmét is. A legtöbb forgatókönyvben nem szükséges, hogy mélyreható ismeretekkel rendelkezzen a Virtual WAN belső útválasztásának működéséről, de bizonyos helyzetekben hasznos lehet a Virtual WAN útválasztási fogalmainak megismerése.
Ez a dokumentum a Virtual WAN-mintaforgatókönyveket ismerteti, amelyek bemutatják, hogy a szervezetek milyen viselkedést tapasztalhatnak a virtuális hálózatok és az ágak összetett hálózatokban való összekapcsolásakor. A cikkben bemutatott forgatókönyvek egyáltalán nem tervezési javaslatok, csupán minta topológiák, amelyek bizonyos Virtual WAN-funkciók bemutatására szolgálnak.
1. forgatókönyv: topológia alapértelmezett útválasztási beállítással
A cikk első forgatókönyve egy topológiát elemez két Virtual WAN-központtal, az ExpressRoute-tal, a VPN-lel és az SDWAN-kapcsolattal. Mindegyik központban vannak közvetlenül csatlakoztatott virtuális hálózatok (11- és 21-s virtuális hálózatok), és közvetetten egy NVA-n keresztül (121-, 122-, 221- és 222-s virtuális hálózatok). A VNet 12 az 1. központtal BGP-vel cseréli le az útválasztási információkat (lásd : BGP társviszony-létesítés egy virtuális központtal), a 22-es virtuális hálózat pedig statikus útvonalakat konfigurált, így a két lehetőség közötti különbségek megjeleníthetők.
Mindegyik központban a VPN és az SDWAN készülékek kettős célt szolgálnak: az egyik oldalon saját előtagokat hirdetnek (10.4.1.0/24 az 1. központban a VPN-en, 10.5.3.0/24 a 2. központban pedig az SDWAN-n keresztül), a másik oldalon pedig ugyanazokat az előtagokat hirdetik, mint az ExpressRoute-kapcsolatcsoportok ugyanabban a régióban (10.4.2.0/24 az 1. központban és 10.5.2.0/24 a 2. központban). Ez a különbség a Virtual WAN hub útválasztási beállításainak működését mutatja be.
Minden virtuális hálózat- és ágkapcsolat társítva van, és az alapértelmezett útvonaltáblába van propagálás. Bár a központok védettek (minden központban üzembe helyeznek egy Azure Firewall-t), ezek nincsenek konfigurálva a magán- vagy internetes forgalom védelmére. Ez azt eredményezné, hogy minden kapcsolat propagálása az None útvonaltáblára történik, ami eltávolítja az összes nem statikus útvonalat az Default útvonaltáblából, és nem felelne meg a cikk céljának, mivel a portál hatékony útvonalpanelje szinte üres lenne (kivéve a statikus útvonalakat, amelyek forgalmat küldenek az Azure Firewallnak).
Fontos
Az előző ábrán két biztonságos virtuális központ látható, ezt a topológiát az Útválasztási szándék támogatja. További információ: A Virtual WAN Hub útválasztási szándékának és útválasztási szabályzatainak konfigurálása.
A virtual WAN-központok egymás között cserélnek információkat, így a régiók közötti kommunikáció engedélyezve van. A Virtual WAN útvonaltábláiban megvizsgálhatja az érvényes útvonalakat: az alábbi képen például az 1. központ érvényes útvonalai láthatók:
Ezeket a hatékony útvonalakat a Virtual WAN ezután az ágakra hirdeti, és a virtuális központokhoz csatlakoztatott virtuális hálózatokba irányítja őket, szükségtelenvé téve a felhasználó által meghatározott útvonalak használatát. A virtuális központ érvényes útvonalainak vizsgálatakor a "Következő ugrás típusa" és az "Origin" mező jelzi, hogy honnan érkeznek az útvonalak. A "Virtuális hálózat Csatlakozás ion" következő ugrástípusa például azt jelzi, hogy az előtag egy, a Virtual WAN-hoz közvetlenül csatlakozó virtuális hálózatban van definiálva (az előző képernyőkép 11-es és 12-es virtuális hálózatai)
A VNet 12 NVA-jában a 10.1.20.0/22-es útvonalat injektálja a BGP-n keresztül, ahogy azt a Következő ugrás típusa "HubBgp Csatlakozás ion" is jelzi (lásd: BGP-társviszony-létesítés virtuális központtal). Ez az összefoglaló útvonal a 121-es (10.1.21.0/24-es) és a 122-es VNet (10.1.22.0/24) közvetett küllőket is tartalmazza. A távoli központ virtuális hálózatai és ágai a következő ugrással hub2láthatók, és az AS útvonalon látható, hogy az autonóm rendszerszám 65520 két alkalommal elő lett előállítva ezekre az interhub-útvonalakra.
A 2. központban található egy integrált SDWAN hálózati virtuális berendezés. Az integráció támogatott NVA-kkal kapcsolatos további információkért látogasson el a Virtual WAN-központ NVA-król szóló szakaszára. Vegye figyelembe, hogy az SDWAN ághoz 10.5.3.0/24 vezető útvonal következő ugrása a VPN_S2S_Gatewaykövetkező. Ez a következő ugrás típusa jelezheti, hogy ma vagy egy Azure-beli virtuális hálózati átjáróról vagy a központba integrált NVA-kból érkező útvonalakról érkeznek.
A 2. központban a 221-es (10.2.21.0/24)-es és a 222-es VNet (10.2.22.0/24) közvetett küllőkhöz 10.2.20.0/22 vezető útvonal statikus útvonalként van telepítve a forrás defaultRouteTableáltal jelzett módon. Ha az 1. központ érvényes útvonalait ellenőrzi, az útvonal nem található. Ennek az az oka, hogy a statikus útvonalakat nem a BGP propagálja, hanem minden központban konfigurálni kell. Ezért az 1. központban statikus útvonalra van szükség az 1. központban található virtuális hálózatok és ágak közötti kapcsolat biztosításához a 2. központ közvetett küllőivel (221-es és 222-es virtuális hálózatok):
A statikus útvonal hozzáadása után az 1. központ az 10.2.20.0/22 útvonalat is tartalmazza:
2. forgatókönyv: Globális elérés és központ útválasztási beállításai
Még akkor is, ha az 1. központ ismeri a 210.5.2.0/24. () kapcsolatcsoport ExpressRoute-előtagját, a 2. központ pedig az 1. kapcsolatcsoport ExpressRoute-előtagját (10.4.2.0/24), a távoli régiók ExpressRoute-útvonalait a rendszer nem hirdeti vissza a helyszíni ExpressRoute-kapcsolatokra. Következésképpen az ExpressRoute Global Reach szükséges ahhoz, hogy az ExpressRoute-helyek kommunikáljanak egymással:
Fontos
Az előző ábrán két biztonságos virtuális központ látható, ezt a topológiát az Útválasztási szándék támogatja. További információ: A Virtual WAN Hub útválasztási szándékának és útválasztási szabályzatainak konfigurálása.
A Virtual Hub útválasztási beállításában leírtak szerint a Virtual WAN alapértelmezés szerint az ExpressRoute-ból érkező útvonalakat részesíti előnyben. Mivel az útvonalakat az 1. központtól az 1. ExpressRoute-kapcsolatcsoportig, az 1. ExpressRoute-kapcsolatcsoporttól a 2. kapcsolatcsoportig, valamint az ExpressRoute 2. kapcsolatcsoporttól a 2. központig hirdetik (és fordítva), a virtuális központok ezt az útvonalat részesítik előnyben a közvetlenebb központkapcsolattal szemben. Az 1. központ érvényes útvonalai a következőt mutatják:
Ahogy az útvonalakon látható, az ExpressRoute Global Reach többször is előveszi az ExpressRoute autonóm rendszerszámát (12076), mielőtt visszaküldené az útvonalakat az Azure-ba, hogy ezek az útvonalak kevésbé előnyösek legyenek. A Virtual WAN alapértelmezett útválasztási elsőbbsége azonban figyelmen kívül hagyja az AS elérési út hosszát az útválasztási döntés meghozatalakor.
A 2. központ érvényes útvonalai hasonlóak lesznek:
Az útválasztási beállítások VPN-re vagy AS-Path-ra módosíthatók a Virtual Hub útválasztási beállításában leírtak szerint. Beállíthatja például a VPN-t a képen látható módon:
A VPN központi útválasztási beállításával az 1. központ érvényes útvonalai a következőképpen néznek ki:
Az előző képen látható, hogy az útvonalnak 10.4.2.0/24 most van egy következő ugrásaVPN_S2S_Gateway, míg az ExpressRoute alapértelmezett útválasztási beállításával.ExpressRouteGateway A 2. központban azonban a következő 10.5.2.0/24 ugrással ExpressRoutetovábbra is megjelenik az útvonal, mert ebben az esetben az alternatív útvonal nem VPN-átjáróból, hanem a központba integrált NVA-ból származik:
A központok közötti forgalom azonban továbbra is az ExpressRoute-on keresztül érkező útvonalakat részesíti előnyben. A virtuális központok közötti hatékonyabb közvetlen kapcsolat használatához az útvonalbeállítás "AS Path" értékre állítható mindkét hubon:
Az 1. központ távoli küllőinek és ágainak útvonalai Remote Hub a következő ugrást fogják elérni a kívánt módon:
Láthatja, hogy a 2. központ (192.168.2.0/23) IP-előtagja továbbra is elérhetőnek tűnik a Global Reach hivatkozáson keresztül, de ez nem befolyásolhatja a forgalmat, mivel a 2. központban lévő eszközökre irányuló forgalomnak nem szabad lennie. Ez az útvonal azonban problémát jelenthet, ha mindkét központban SDWAN-alagutakat létesítenek egymás között.
Vegye figyelembe azonban, hogy most 10.4.2.0/24 már előnyben részesítik a VPN Gatewayt. Ez akkor fordulhat elő, ha a VPN-en keresztül meghirdetett útvonalak rövidebb AS elérési útokkal rendelkeznek, mint az ExpressRoute-on meghirdetett útvonalak. Miután konfigurálta a helyszíni VPN-eszközt, hogy az autonóm rendszerszámát (65501) előre a VPN-útvonalakra használja, hogy a kevésbé előnyösebb legyen, az 1. központ most az ExpressRoute-ot választja a következő ugráshoz 10.4.2.0/24:
A 2. hub egy hasonló táblát jelenít meg az érvényes útvonalakhoz, ahol a másik központban lévő virtuális hálózatok és ágak mostantól következő ugrásként jelennek meg Remote Hub :
3. forgatókönyv: Az ExpressRoute-kapcsolatcsoportok keresztcsatlakoztatása mindkét központhoz
Ahhoz, hogy közvetlen kapcsolatokat lehessen létesíteni az Azure-régiók és az ExpressRoute-on keresztül csatlakoztatott helyszíni helyek között, gyakran kívánatos egyetlen ExpressRoute-kapcsolatcsoportot összekapcsolni egy topológiában található több Virtual WAN-központtal, amelyeket néha "csokornyakkendőnek" nevezünk, ahogy az alábbi topológia is mutatja:
Fontos
Az előző ábrán két biztonságos virtuális központ látható, ezt a topológiát az Útválasztási szándék támogatja. További információ: A Virtual WAN Hub útválasztási szándékának és útválasztási szabályzatainak konfigurálása.
A Virtual WAN azt mutatja, hogy mindkét kapcsolatcsoport mindkét központhoz csatlakozik:
Az ExpressRoute alapértelmezett útválasztási beállítására visszatérve az 1. központ távoli ágaihoz és virtuális hálózataihoz vezető útvonalak ismét ExpressRoute-ot fognak megjeleníteni következő ugrásként. Bár ezúttal nem a Global Reach az oka, hanem az, hogy az ExpressRoute-kapcsolatcsoportok visszapattannak az egyik központból a másikba érkező útvonalhirdetésekre. Az 1. hub érvényes útvonalai például az ExpressRoute hub-útválasztási beállításával a következők:
Ha a hub útválasztási beállítását ismét AS Path-ra módosítja, az 1. és a 2. központ közötti közvetlen kapcsolat használatával visszaadja a központközi útvonalakat az optimális útvonalra:
Következő lépések
További információ a Virtual WAN-ról:
- A Virtual WAN – gyakori kérdések