Alapértelmezett útvonalinjektálás küllős virtuális hálózatokban

Az Azure egyik leggyakoribb architektúrája a küllős kialakítás, ahol a küllős virtuális hálózaton (VNet) üzembe helyezett számítási feladatok a központi virtuális hálózaton található megosztott hálózati eszközökön keresztül küldik a forgalmat. A felhasználó által megadott útvonalakat (UDR) általában úgy kell konfigurálni a küllős virtuális hálózatokban, hogy a forgalmat a központ biztonsági eszközei felé irányítsák. Ehhez a kialakításhoz azonban a rendszergazdáknak több küllőn keresztül kell kezelniük ezeket az útvonalakat.

Az Azure Route Server egy központosított pontot kínál, ahol a hálózati virtuális berendezések (NVA-k) meghirdethetik a küllős virtuális hálózatokba injektált útvonalakat. Így a rendszergazdáknak nem kell útválasztási táblákat létrehozniuk és frissíteniük a küllős virtuális hálózatokban.

Topológia

Az alábbi ábra egy egyszerű küllős és egy központi virtuális hálózattal és két küllős virtuális hálózattal rendelkező küllős kialakítást ábrázol. A központban üzembe helyeztek egy hálózati virtuális berendezést és egy útvonalkiszolgálót. Az Útválasztási kiszolgáló nélkül a felhasználó által megadott útvonalakat minden küllőben konfigurálni kell. Ezek az UDR-ek általában a 0.0.0.0/0 alapértelmezett útvonalát tartalmazzák, amely a küllő virtuális hálózatokról az NVA-n keresztül küldi el az összes forgalmat. Ez a forgatókönyv például a forgalom biztonsági okokból történő vizsgálatára használható.

Ha az útvonalkiszolgáló a központi virtuális hálózaton van, nincs szükség felhasználó által meghatározott útvonalak használatára. Az NVA meghirdeti a hálózati előtagokat az útválasztási kiszolgálónak, amely injektálja őket, így azok megjelennek a központi virtuális hálózatban üzembe helyezett virtuális gépek vagy küllős virtuális hálózatok hatékony útvonalaiban, amelyek a központi virtuális hálózattal társviszonyban vannak a távoli virtuális hálózat átjárójának vagy útvonalkiszolgálójának használata beállítással.

Csatlakozás helyszíni környezetben az NVA-n keresztül

Ha az NVA használatával IPsec VPN-eken vagy SD-WAN-technológiákon keresztül biztosít kapcsolatot a helyszíni hálózathoz, ugyanaz a mechanizmus használható a küllőkről az NVA felé történő forgalom vonzására. Emellett az NVA dinamikusan megtanulhatja az Azure-előtagokat az Azure Route Serverből, és dinamikus útválasztási protokollal hirdetheti őket a helyszíni felé. Az alábbi diagram a következő beállítást ismerteti:

Magánforgalom vizsgálata az NVA-n keresztül

Az előző szakaszok a hálózati virtuális berendezés (NVA) által vizsgált forgalmat ábrázolják az NVA-ból az útvonalkiszolgálóra irányuló alapértelmezett útvonal injektálásával 0.0.0.0/0 . Ha azonban csak küllős és küllős helyszíni forgalmat szeretne megvizsgálni az NVA-n keresztül, vegye figyelembe, hogy az Azure Route Server nem hirdet olyan útvonalat, amely megegyezik vagy hosszabb előtaggal, mint az NVA-tól tanult virtuális hálózati címtér. Más szóval az Azure Route Server nem injektálja ezeket az előtagokat a virtuális hálózatba, és nem lesznek beprogramozva a központi vagy küllős virtuális hálózatok virtuális gépeinek hálózati adapterein.

Az Azure Route Server azonban nagyobb alhálózatot fog meghirdetni, mint az NVA-tól tanult virtuális hálózat címtere. Az NVA-ból meghirdetheti a virtuális hálózatban található adatok szupernetét. Ha például a virtuális hálózat az RFC 1918 címteret 10.0.0.0/16használja, az NVA meghirdetheti 10.0.0.0/8 az Azure Route Servert, és ezeket az előtagokat a rendszer a küllős virtuális hálózatokba injektálja. Erre a virtuális hálózat viselkedésre hivatkozik a About BGP és a VPN Gateway.

Fontos

Ha olyan forgatókönyve van, amelyben az Azonos hosszúságú előtagokat az ExpressRoute-ból és az NVA-ból hirdetik, az Azure előnyben részesíti és beprogramozza az ExpressRoute-ból tanult útvonalakat. További információért tekintse át a következő szakaszt.

Csatlakozás helyszíni virtuális hálózati átjárókon keresztül

Ha egy VPN vagy egy ExpressRoute-átjáró ugyanabban a virtuális hálózaton található, mint az Útválasztási kiszolgáló és az NVA, hogy kapcsolatot biztosítson a helyszíni hálózatokhoz, az átjárók által tanult útvonalak a küllős virtuális hálózatokon is be lesznek programozva. Ezek az útvonalak felülbírálják az útvonalkiszolgáló által injektált alapértelmezett útvonalat (0.0.0.0/0), mivel pontosabbak (hosszabb hálózati maszkok). Az alábbi ábra az előző kialakítást mutatja be, ahol egy ExpressRoute-átjárót adtak hozzá.

A küllős virtuális hálózatok alhálózatai nem konfigurálhatók úgy, hogy csak az Azure Route Serverről tanulják meg az útvonalakat. Ha egy alhálózathoz társított útvonaltáblában letiltja az "Átjáróútvonalak propagálása" elemet, azzal megakadályozhatja, hogy mindkét útvonaltípus (a virtuális hálózati átjáró útvonalai és az Azure Route Server útvonalai) az adott alhálózat hálózati adaptereibe legyen injektálva.

Alapértelmezés szerint az Útvonalkiszolgáló az NVA-tól az ExpressRoute-ig tanult összes előtagot is meghirdeti. Ez nem feltétlenül szükséges, például az ExpressRoute vagy maga az útvonalkiszolgáló útvonalkorlátai miatt. Ebben az esetben az NVA bejelentheti az útvonalkiszolgáló felé vezető útvonalakat, beleértve a BGP-közösséget no-advertise is (értékkel 65535:65282). Amikor az Útválasztási kiszolgáló ezzel a BGP-közösséggel fogad útvonalakat, azokat az alhálózatokra injektálja, de más BGP-társnak (például ExpressRoute-nak, VPN-átjáróknak vagy más NVA-knak) nem fogja meghirdetni őket.

SDWAN együttélés az ExpressRoute-tal és az Azure Firewall-tal

Az előző kialakítás különleges esete, hogy az ügyfelek az Azure Firewallt szúrják be a forgalomba a helyszíni hálózatok felé irányuló összes forgalom vizsgálatához, akár az ExpressRoute-on, akár az SD-WAN/VPN-berendezéseken keresztül. Ebben az esetben az összes küllős alhálózat rendelkezik olyan útvonaltáblákkal, amelyek megakadályozzák, hogy a küllők bármilyen útvonalat tanulnak az ExpressRoute-ból vagy az útvonalkiszolgálóról, és az Azure Firewall alapértelmezett útvonalai (0.0.0.0/0) a következő ugrásként, ahogyan az alábbi ábrán látható:

Az Azure Firewall alhálózata az ExpressRoute-ból és a VPN/SDWAN NVA-ból érkező útvonalakat is megismeri, és eldönti, hogy az egyik vagy a másik irányba küldi-e a forgalmat. Az előző szakaszban leírtak szerint, ha az NVA-berendezés több mint 200 útvonalat hirdet az útvonalkiszolgálónak, akkor a BGP-közösséggel no-advertisemegjelölt BGP-útvonalakat kell elküldenie. Így az SDWAN előtagok nem lesznek visszaszúrva a helyszínre az Express-Route-on keresztül.

Forgalom szimmetria

Ha több NVA-példányt használnak aktív/aktív forgatókönyvben a jobb rugalmasság vagy skálázhatóság érdekében, akkor a forgalom szimmetriájának követelménye, ha az NVA-knak meg kell tartaniuk a kapcsolatok állapotát. Ez például a következő generációs tűzfalak esete.

• Az Azure-beli virtuális gépekről a nyilvános internetre való kapcsolódáshoz az NVA a forráshálózati címfordítást (SNAT) használja, hogy a kimenő forgalom az NVA nyilvános IP-címéről legyen forrás, ezáltal a forgalom szimmetriája.
• Az internetről a virtuális gépeken futó számítási feladatok felé irányuló bejövő forgalom esetén a célhálózati címfordításon (DNAT) kívül az NVA-knak a forráshálózati címfordítást (SNAT) kell elvégeznie, hogy a virtuális gépekről érkező visszatérési forgalom ugyanazon az NVA-példányon legyen, amely az első csomagot feldolgozta.
• Az Azure-ból Az Azure-ba irányuló kapcsolatok esetében, mivel a forrás virtuális gép a céltól függetlenül fogja meghozni az útválasztási döntést, az SNAT-ra ma szükség van a forgalomszimmetria eléréséhez.

Több NVA-példány is üzembe helyezhető aktív/passzív beállításban, például ha az egyik rosszabb útvonalakat hirdet (hosszabb AS elérési úttal), mint a másik. Ebben az esetben az Azure Route Server csak az előnyben részesített útvonalat fogja injektálni a virtuális hálózatok virtuális gépeibe, és a kevésbé előnyben részesített útvonalat csak akkor használja a rendszer, ha az elsődleges NVA-példány leállítja a BGP-n való hirdetést.

Különböző útvonalkiszolgálók a virtuális hálózati átjárókhoz és a virtuális hálózatokhoz vezető útvonalak meghirdetéséhez

Ahogy az előző szakaszokban is látható, az Azure Route Server kettős szerepkörrel rendelkezik:

• Megtanulja és meghirdeti a virtuális hálózati átjárók (VPN és ExpressRoute) útvonalait
• A tanult útvonalakat a virtuális hálózatán és a közvetlenül társviszonyban lévő virtuális hálózatokon konfigurálja

Ez a kettős funkció gyakran érdekes, de időnként hátrányos lehet bizonyos követelményekre. Ha például az útválasztási kiszolgáló egy 0.0.0.0/0-s útvonalat hirdető NVA-val és egy helyszíni ExpressRoute-átjárót hirdető előtaggal rendelkező virtuális hálózatban van üzembe helyezve, az összes útvonalat (az NVA 0.0.0.0/0-s és a helyszíni előtagjait) konfigurálja a virtuális hálózaton lévő virtuális gépeken és a közvetlenül társviszonyban lévő virtuális hálózatokon. Ennek következtében, mivel a helyszíni előtagok pontosabbak lesznek, mint 0.0.0.0/0, a helyszíni és az Azure közötti forgalom megkerüli az NVA-t. Ha ez nem kívánatos, a cikk előző szakaszai bemutatták, hogyan tilthatja le a BGP-propagálást a virtuálisgép-alhálózatokban, és konfigurálhatja az UDR-eket.

Van azonban egy alternatív, dinamikusabb megközelítés. Különböző Azure Route-kiszolgálókat is használhat különböző funkciókhoz: az egyik a virtuális hálózati átjárókkal való interakcióért, a másik a virtuális hálózati útválasztásért felelős. Az alábbi ábra egy lehetséges tervet mutat be ehhez:

A hub 1. útvonalkiszolgálója az SDWAN előtagjainak az ExpressRoute-ba történő injektálására szolgál. Mivel a küllős virtuális hálózatok társviszonyban vannak a központi virtuális hálózattal a távoli virtuális hálózat átjárójának vagy útvonalkiszolgálójának használata (a küllős virtuális hálózatok közötti társviszony-létesítésben) és a virtuális hálózat átjárójának vagy útvonalkiszolgálójának használata (átjárótovábbítás a központi virtuális hálózatok közötti társviszony-létesítésben), a küllős virtuális hálózatok nem tanulják meg ezeket az útvonalakat (sem az SDWAN előtagokat, sem az ExpressRoute-előtagokat).

Az útvonalak küllős virtuális hálózatokra való propagálásához az NVA a 2. útvonalkiszolgálót használja, amelyet egy új kiegészítő virtuális hálózatban helyez üzembe. Az NVA csak egyetlen 0.0.0.0/0 útvonalat propagálja a 2. útvonalkiszolgálóra. Mivel a küllős virtuális hálózatok társviszonyban vannak ezzel a kiegészítő virtuális hálózattal a távoli virtuális hálózat átjárójának vagy útvonalkiszolgálójának használatával (a küllős virtuális hálózatok közötti társviszony-létesítésben), és ennek a virtuális hálózatnak az átjáróját vagy útvonalkiszolgálóját használja (átjárótovábbítás a központi virtuális hálózatok közötti társviszony-létesítésben), az 0.0.0.0/0 útvonalat a küllők összes virtuális gépe megtanulja.

Az útvonal következő ugrása az 0.0.0.0/0 NVA, így a küllős virtuális hálózatokat továbbra is társviszonyba kell helyezni a központi virtuális hálózattal. Egy másik fontos szempont, hogy a központi virtuális hálózatot ahhoz a virtuális hálózathoz kell társviszonyba helyezni, ahol a Route Server 2 telepítve van, ellenkező esetben nem fogja tudni létrehozni a BGP-t.

Ha az ExpressRoute-ból a küllő virtuális hálózatokra irányuló forgalmat egy NVA-tűzfalba kell küldeni ellenőrzés céljából, a GatewaySubnet útvonaltáblája továbbra is szükséges, ellenkező esetben az ExpressRoute virtuális hálózati átjáró csomagokat küld a virtuális gépeknek a virtuális hálózatok közötti társviszony-létesítésből tanult útvonalak használatával. Az útvonaltáblában szereplő útvonalaknak meg kell egyeznie a küllős előtagokkal, a következő ugrás pedig az NVA tűzfal IP-címe (vagy a tűzfal NVA-k előtti terheléselosztója, redundancia esetén). Az NVA tűzfal lehet ugyanaz, mint a fenti ábrán látható SDWAN NVA, vagy lehet egy másik eszköz, például az Azure Firewall, mivel az SDWAN NVA a következő ugrással más IP-címekre mutatva hirdethet útvonalakat. Az alábbi ábra az Azure Firewall hozzáadásával mutatja be ezt a kialakítást:

Feljegyzés

A privát végpontokra irányuló helyszíni forgalom esetén ez a forgalom megkerüli az NVA tűzfalat vagy az Azure Firewallt a központban. Ez azonban aszimmetrikus útválasztást eredményez (ami a helyszíni és a privát végpontok közötti kapcsolat megszakadásához vezethet), mivel a privát végpontok továbbítják a helyszíni forgalmat a tűzfalra. Az útválasztási szimmetria biztosítása érdekében engedélyezze az Útválasztási tábla hálózati szabályzatait azon alhálózatok privát végpontjaihoz , ahol a privát végpontok üzembe vannak helyezve.

Ez a kialakítás lehetővé teszi az útvonalak automatikus injektálását küllős virtuális hálózatokon anélkül, hogy az ExpressRoute-ból, VPN-ből vagy SDWAN-környezetből tanult egyéb útvonalak interferencia nélkül injektálják az útvonalakat, valamint a tűzfal NVA-k hozzáadását a forgalomvizsgálathoz.

Kapcsolódó tartalom

• További információ az Azure Route Server ExpressRoute- és Azure VPN-támogatásáról.
• Megtudhatja, hogyan konfigurálhatja a társviszonyt az Azure Route Server és a hálózati virtuális berendezés között.