Ez a cikk a hálózati virtuális berendezések (NVA-k) azure-beli magas rendelkezésre állás érdekében történő üzembe helyezésének leggyakoribb lehetőségeit ismerteti. Az NVA-t általában a különböző biztonsági szinteken besorolt hálózati szegmensek közötti forgalom szabályozására használják, például egy de-militarizált zóna (DMZ) virtuális hálózat és a nyilvános internet között.
A különböző biztonsági zónák közötti forgalom vizsgálatához számos tervezési minta létezik, például:
- A virtuális gépekről az internetre irányuló kimenő forgalom vizsgálata és az adatok kiszivárgásának megakadályozása.
- Az internetről a virtuális gépekre irányuló bejövő forgalom vizsgálata és a támadások megakadályozása.
- Az Azure-beli virtuális gépek közötti forgalom szűréséhez megakadályozza a sérült rendszerek oldalirányú áthelyezését.
- A helyszíni rendszerek és az Azure-beli virtuális gépek közötti forgalom szűrése, ha azokat különböző biztonsági szinteknek tekintik. (Ha például az Azure üzemelteti a DMZ-t, és a belső alkalmazásokat a helyszínen üzemelteti.)
Számos példa van az NVA-kra, például a hálózati tűzfalakra, a 4. rétegbeli fordított proxykra, az IPsec VPN-végpontokra, a webalkalmazási tűzfal funkcióval rendelkező webalapú fordított proxykra, az internetes proxykra, amelyek korlátozzák, hogy mely internetes oldalak érhetők el az Azure-ból, a 7. rétegbeli terheléselosztókból és még sok más. Ezek mindegyike beilleszthető egy Azure-tervbe a cikkben ismertetett mintákkal. Még az Azure-beli belső hálózati virtuális berendezések, például az Azure Firewall és a Azure-alkalmazás Gateway is a jelen cikk későbbi részében ismertetett terveket használják. Ezeknek a lehetőségeknek a megértése mind a tervezés, mind a hálózati problémák elhárítása szempontjából kritikus fontosságú.
Az első megválaszolandó kérdés az, hogy miért van szükség a hálózati virtuális berendezések magas rendelkezésre állására. Ennek az az oka, hogy ezek az eszközök szabályozzák a hálózati szegmensek közötti kommunikációt. Ha nem érhetők el, a hálózati forgalom nem tud áramlani, és az alkalmazások leállnak. Az ütemezett és nem ütemezett kimaradások esetenként leálltathatják az NVA-példányokat (mint az Azure bármely más virtuális gépét vagy bármely más felhőt). A példányok akkor is le lesznek bontva, ha ezek az NVA-k prémium szintű felügyelt lemezekkel vannak konfigurálva, hogy egypéldányos SLA-t biztosítsanak az Azure-ban. Ezért a magas rendelkezésre állású alkalmazásokhoz legalább egy második NVA szükséges, amely biztosítja a kapcsolatot.
Előfeltételek: Ez a cikk az Azure-hálózatkezelés, az Azure Load Balancers és a virtuális hálózati forgalom útválasztásának (UDR) alapszintű ismeretét feltételezi.
Amikor a hálózati virtuális berendezés Azure-beli virtuális hálózatban való üzembe helyezésének legjobb lehetőségét választja, a legfontosabb szempont az, hogy az NVA-gyártó ellenőrizte-e és ellenőrizte-e az adott kialakítást. A szállítónak meg kell adnia a szükséges NVA-konfigurációt is, amely az NVA Azure-ba való integrálásához szükséges. Ha az NVA szállítója különböző alternatívákat kínál az NVA támogatott tervezési lehetőségeiként, ezek a tényezők befolyásolhatják a döntést:
- Konvergenciára vonatkozó idő: mennyi ideig tart az egyes tervekben a forgalom irányítása egy sikertelen NVA-példánytól?
- Topológia támogatása: milyen NVA-konfigurációkat támogatnak az egyes tervezési lehetőségek? Aktív/aktív, aktív/készenléti, kibővített NVA-fürtök n+1 redundanciával?
- Forgalomszimmetria: egy adott kialakítás kényszeríti az NVA-t a forráshálózati címfordítás (SNAT) végrehajtására a csomagokon az aszimmetrikus útválasztás elkerülése érdekében? Vagy a forgalom szimmetriát más eszközök is kényszerítik?
A dokumentum következő szakaszai az NVA-k központi és küllős hálózatba való integrálásához használt leggyakoribb architektúrákat ismertetik.
Feljegyzés
Ez a cikk a Küllős kialakításokra összpontosít. A Virtual WAN nincs lefedve, mivel a Virtual WAN sokkal előíróbb az NVA-k üzembe helyezésének módjával kapcsolatban, attól függően, hogy egy adott NVA támogatott-e a Virtual WAN-központokban. További információ: Hálózati virtuális berendezések a Virtual WAN hubon .
HA-architektúrák áttekintése
A következő architektúrák bemutatják a magas rendelkezésre állású NVA-khoz szükséges erőforrásokat és konfigurációkat:
| Megoldás | Juttatások | Megfontolások |
|---|---|---|
| Azure Load Balancer | Támogatja az aktív/aktív, az aktív/készenléti és a kibővített NVA-kat. Nagyon jó konvergenciára való idő | Az NVA-nak portot kell biztosítania az állapotadat-mintavételekhez, különösen az aktív/készenléti üzemelő példányokhoz. Az internetre irányuló vagy onnan érkező folyamatok szimmetrikus SNAT-t igényelnek |
| Azure Route Server | Az NVA-nak támogatnia kell a BGP-t. Támogatja az aktív/aktív, az aktív/készenléti és a kibővített NVA-kat. | A forgalom szimmetriája SNAT-t igényel |
| Átjáró terheléselosztója | A forgalom szimmetriája SNAT nélkül garantált. Az NVA-k megoszthatók a bérlők között. Nagyon jó konvergenciát. Támogatja az aktív/aktív, az aktív/készenléti és a kibővített NVA-kat. | Támogatja az internetre irányuló vagy onnan érkező folyamatokat, kelet-nyugati folyamatok nélkül |
| PIP/UDR módosítása | Az NVA nem igényel különleges funkciót. Szimmetrikus forgalmat garantál | Csak aktív/passzív kialakításokhoz. 1–2 perces magas konvergenciás idő |
A Load Balancer tervezése
Ez a kialakítás két Azure Load Balancerrel teszi elérhetővé az NVA-kból álló fürtöt a hálózat többi részén:
- A belső Load Balancer használatával átirányíthatja a belső forgalmat az Azure-ból és a helyszíni forgalomból az NVA-kba. Ez a belső terheléselosztó haport-szabályokkal van konfigurálva, így minden TCP/UDP-port az NVA-példányokra lesz átirányítva.
- A nyilvános Load Balancer elérhetővé teszi az NVA-kat az interneten. Mivel a HA-portok bejövő forgalomhoz tartoznak, minden egyes TCP/UDP-portot egy dedikált terheléselosztási szabályban kell megnyitni.
Az alábbi ábra az internetről egy küllős virtuális hálózaton lévő alkalmazáskiszolgálóra irányuló ugrások sorrendjét ismerteti:
Töltse le az architektúra Visio-fájlját.
A küllőkről a nyilvános internetre irányuló forgalom NVA-n keresztüli küldésének mechanizmusa egy felhasználó által 0.0.0.0/0 meghatározott útvonal a belső Load Balancer IP-címének következő ugrásával.
Az Azure és a nyilvános internet közötti forgalom esetében a forgalom minden iránya egy másik Azure Load Balancert (a bejövő csomagot a nyilvános ALB-n keresztül, a kimenő csomagot pedig a belső ALB-n keresztül) keresztezi. Ennek következtében, ha a forgalom szimmetriája szükséges, a forráshálózati címfordítást (SNAT) az NVA-példányoknak kell elvégeznie a visszatérési forgalom vonzása és a forgalom aszimmetriája elkerülése érdekében.
Ez a kialakítás az Azure és a helyszíni hálózatok közötti forgalom vizsgálatára is használható:
A küllők közötti forgalom NVA-n keresztüli küldésének mechanizmusa pontosan ugyanaz, ezért nincs további diagram. A fenti példadiagramokban, mivel a küllő1 nem ismeri a küllő2 tartományát, az UDR a 0.0.0.0/0 küllő2 felé küldött forgalmat küldi el az NVA belső Azure Load Balancerjének.
A helyszíni hálózatok és az Azure vagy az Azure-beli virtuális gépek közötti forgalom szimmetriát a belső Azure Load Balancer garantálja: amikor egy forgalom mindkét iránya ugyanazon az Azure Load Balanceren halad át, ugyanazt az NVA-példányt választja ki.
Az Azure Load Balancer nagyon jó konvergenciával rendelkezik az egyes NVA-leállások esetén. Mivel az állapotminták 5 másodpercenként küldhetők el, és 3 sikertelen mintavétel szükséges egy háttérpéldány szolgáltatáson kívüli deklarálásához, általában 10–15 másodpercet vesz igénybe, amíg az Azure Load Balancer egy másik NVA-példány felé konvergálja a forgalmat.
Ez a beállítás támogatja az aktív/aktív és az aktív/készenléti konfigurációkat is. Az aktív/készenléti konfigurációk esetében azonban az NVA-példányoknak olyan TCP/UDP-portot vagy HTTP-végpontot kell biztosítaniuk, amely nem válaszol a Load Balancer állapottesztjeire, kivéve, ha a példány aktív szerepkörrel rendelkezik.
L7 terheléselosztók használata
Ennek a kialakításnak egy konkrét esete az Azure nyilvános Load Balancer cseréje egy 7. rétegbeli terheléselosztóra, például a Azure-alkalmazás-átjáróra (amely önmagában NVA-nak tekinthető). Ebben az esetben az NVA-k csak egy belső Load Balancert igényelnek előttük, mivel az Application Gatewayről érkező forgalom a VNeten belülről származik, és a forgalmi aszimmetria nem okoz problémát.
Az NVA-nak bejövő forgalmat kell vennie a 7. rétegbeli terheléselosztó által nem támogatott protokollok bejövő forgalmához, valamint potenciálisan az összes kimenő forgalomhoz. Az Azure Firewall NVA-ként és Azure-alkalmazás Gateway 7. rétegbeli webes fordított proxyként való használatakor a konfigurációval kapcsolatos további részletekért lásd a tűzfalat és az Application Gatewayt a virtuális hálózatokhoz.
Azure Route Server
Az Azure Route Server egy olyan szolgáltatás, amely lehetővé teszi, hogy az NVA a Border Gateway Protocolon (BGP) keresztül kommunikáljon az Azure SDN-vel. Nem csak az NVA-k fogják megtudni, hogy mely IP-előtagok léteznek az Azure-beli virtuális hálózatokban, de képesek lesznek útvonalakat injektálni az Azure-beli virtuális gépek hatékony útvonaltábláiba.
A fenti ábrán az egyes NVA-példányok a BGP-n keresztül társviszonyba kerülnek az Azure Route Serverrel. A küllős alhálózatokban nincs szükség útvonaltáblára, mivel az Azure Route Server programozza az NVA-k által meghirdetett útvonalakat. Ha két vagy több útvonal van beprogramozva az Azure-beli virtuális gépeken, akkor az Equal Cost MultiPathing (ECMP) használatával választják ki az NVA-példányok egyikét minden forgalomhoz. Ennek következtében az SNAT kötelező ebben a kialakításban, ha a forgalom szimmetriája követelmény.
Ez a beszúrási módszer támogatja az aktív/aktív (az összes NVA ugyanazt az útvonalat hirdeti az Azure Route Serverhez), valamint az aktív/készenléti (az egyik NVA a másiknál rövidebb AS útvonallal meghirdeti az útvonalakat). Az Azure Route Server legfeljebb 8 BGP-szomszédos elemet támogat. Ezért ha aktív NVA-kból álló kibővített fürtöt használ, ez a kialakítás legfeljebb 8 NVA-példányt támogat.
A konvergenciára vonatkozó idő ebben a beállításban meglehetősen gyors, és a BGP szomszédos megőrzési és visszatartási idő időzítői befolyásolják. Bár az Azure Route Server alapértelmezett megőrzési és holdtime időzítőkkel rendelkezik (60 másodperc, illetve 180 másodperc), az NVA-k alacsonyabb időzítőket egyeztethetnek a BGP szomszédos létesítményében. Ezeknek az időzítőknek a túl alacsony beállítása BGP-instabilitáshoz vezethet.
Ez a kialakítás az Azure-beli útválasztással interakcióba lépő NVA-k leggyakoribb lehetősége, például a VPN-leállítási NVA-knak, amelyeknek meg kell tanulniuk az Azure-beli virtuális hálózatokban konfigurált előtagokat, vagy bizonyos útvonalakat kell meghirdetni az ExpressRoute-beli privát társviszony-létesítéseken keresztül.
Gateway Load Balancer
Az Azure Gateway Load Balancer egy új módszer az NVA-k adatelérési útvonalba való beszúrására anélkül, hogy a forgalmat felhasználó által meghatározott útvonalakkal kellene irányítani. Azon virtuális gépek esetében, amelyek számítási feladataikat egy Azure Load Balancer vagy egy nyilvános IP-cím segítségével teszik elérhetővé, a bejövő és kimenő forgalom transzparens módon átirányítható egy másik virtuális hálózaton található NVA-fürtre. Az alábbi ábra azt az útvonalat ismerteti, amelyet a csomagok követnek a nyilvános internetről érkező bejövő forgalomhoz, ha a számítási feladatok egy Azure Load Balanceren keresztül teszik elérhetővé az alkalmazást:
Ennek az NVA-injektálási módszernek az egyik fő előnye, hogy a forráshálózati címfordítás (SNAT) nem szükséges a forgalom szimmetriája biztosításához. A tervezési lehetőség másik előnye, hogy ugyanezekkel az NVA-kkal vizsgálhatók a különböző virtuális hálózatokra irányuló vagy onnan érkező forgalom, így az NVA szempontjából több-bérlőssé válik. Nincs szükség virtuális hálózatok közötti társviszonyra az NVA virtuális hálózat és a számítási feladat virtuális hálózata(i) között, és nincs szükség felhasználó által meghatározott útvonalakra a számítási feladat virtuális hálózatában, ami jelentősen leegyszerűsíti a konfigurációt.
Az átjáró load Balancer szolgáltatásinjektálása használható az Azure nyilvános Load Balancert elérő bejövő folyamatokhoz (és azok visszatérési forgalmához), valamint az Azure-ból származó kimenő folyamatokhoz. Az Azure-beli virtuális gépek közötti kelet-nyugati forgalom nem tudja kihasználni az átjáró terheléselosztóját az NVA-injektáláshoz.
Az NVA-fürtben az Azure Load Balancer állapotellenőrzési mintavételei az egyes NVA-példányok hibáinak észlelésére szolgálnak, ami nagyon gyors konvergenciát (10–15 másodpercet) tesz lehetővé.
PIP-UDR módosítása
A terv mögött az áll, hogy az NVA-redundancia nélkül szükséges beállítást kell beállítani, és módosítani kell, ha az NVA leállást szenvedne. Az alábbi ábra azt mutatja be, hogyan van társítva egy Azure-beli nyilvános IP-cím az aktív NVA-hoz (NVA1), és a küllők felhasználó által definiált útvonalai a következő ugrásként (10.0.0.37) az aktív NVA IP-címével rendelkeznek.
Ha az aktív NVA elérhetetlenné válik, a készenléti NVA meghívja az Azure API-t, hogy újraképezhesse a nyilvános IP-címet és a küllős, felhasználó által definiált útvonalakat (vagy helyezze át a privát IP-címet is). Ezek az API-hívások eltarthatnak néhány percig, hogy hatékonyak legyenek, ezért ez a kialakítás a dokumentum összes lehetőségének legrosszabb konvergenciáját kínálja.
A kialakítás egy másik korlátozása, hogy csak az aktív/készenléti konfigurációk támogatottak, ami skálázhatósági problémákhoz vezethet: ha növelnie kell az NVA-k által támogatott sávszélességet, az egyetlen lehetőség ezzel a kialakítással mindkét példány felskálázása.
Ennek a kialakításnak az egyik előnye, hogy nincs szükség forráshálózati címfordításra (SNAT) a forgalom szimmetriája érdekében, mivel egy adott időpontban csak egy NVA aktív.
Közreműködők
Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.
Fő szerzők:
- Keith Mayer | Fő felhőmegoldás-tervező
- Telmo Sampaio | Vezető szolgáltatásmérnök
A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.
Következő lépések
- Megtudhatja, hogyan implementálhat biztonságos hibrid hálózatot az Azure Firewall használatával.
- Szegélyhálózatok – felhőadaptálási keretrendszer
- Cloud DMZ – felhőadaptálási keretrendszer