A felhő megváltoztatja az infrastruktúra tervezésének módját, beleértve a tűzfalak kialakítását is, mivel a hálózat már nem fizikai vagy virtuális HELYI HÁLÓZATOKban van. A fizikai hálózat nem minden funkciója érhető el egy virtuális hálózatban (VNetben). Ez magában foglalja a nem fix IP-címek és a szórásos forgalom használatát, és ez hatással van a magas rendelkezésre állású architektúrák megvalósítására. A hálózati virtuális berendezésekhez (NVA) tartozó terheléselosztókat egy bizonyos módon lehet/kell implementálni, hogy egy virtuális hálózaton belül magas rendelkezésre állású architektúrát lehessen kialakítani. Ez az útmutató strukturált megközelítéssel szolgál a magas rendelkezésre állású tűzfalak (FW-k) tervezéséhez az Azure-ban, külső virtuális berendezések használatával.
Magas rendelkezésre állású NVA-k tervezési lehetőségei
A magas rendelkezésre állású architektúrák üzembe helyezésekor több lehetőség van a feladatátvétel biztosítására:
- Azure API által felügyelt útvonaltáblák: Ez a beállítás két útvonaltáblát használ, egy aktív, egy passzívat a virtuális hálózaton/alhálózaton futó összes szolgáltatás aktív átjáró IP-címének váltásához.
- Azure API által felügyelt lebegő IP-cím: Ez a beállítás egy másodlagos IP-címet használ az FW-ken, amely áthelyezhető egy aktív és egy készenléti FW között.
- Felügyelt Load Balancer: Ez a beállítás egy Azure Load Balancer használatával működik az alhálózat átjáró IP-címeként, majd továbbítja a forgalmat az aktív FW-nek. Előfordulhat, hogy az aktív–aktív forgalmat is továbbítja, hogy valós terheléselosztást biztosítson.
Az első két beállítás esetében az a probléma, hogy maga a feladatátvétel lassú. Az FW-nek meg kell adnia a feladatátvételt, amely lényegében az Azure-szolgáltatások "újrakonfigurálása" egy új üzembe helyezésen keresztül. Attól függően, hogy milyen gyorsan fejeződik be az üzembe helyezés, a forgalom néhány percig leáll. Emellett nem teszi lehetővé az aktív-aktív konfigurációt, ahol mindkét tűzfal egyszerre működik.
Ezért a harmadik lehetőség a legkedveltebb. Az állásidő minimálisra csökken, mivel a terheléselosztó szinte azonnal végrehajtja a feladatátvételt a készenléti állapotú tűzfalra (aktív–passzív), vagy csupán megszünteti a hibás tűzfal terhelését (aktív–aktív). A terheléselosztókat azonban nem használhatja "alapértelmezett átjáróként", mivel ezek hatással vannak a forgalomra, és a TCP-csomagoknak állapotalapúnak kell lenniük.
Kétlábú tűzfalak
Az alábbi képen a folyamat két FW-vel (FW-1 és FW-2) indul, külső terheléselosztó és háttérkiszolgáló (S1) használatával.
Ez az architektúra egy egyszerű beállítás, amely a bejövő forgalomhoz használatos. A csomag beérkezik a terheléselosztóra, amely kiválasztja a cél FW-t a konfigurációjából. Ezután a kiválasztott tűzfal elküldi a forgalmat a (webes) háttérkiszolgálóhoz. Ha az FW-1 SNAT engedélyezve van, az S1 kiszolgáló látni fogja az FW-1 belső IP-címéről érkező forgalmat, így a csomagra adott választ is elküldi az FW-1-nek. Ebben az esetben gyorsan megtörténhet az FW-2-re történő feladatátvétel. A kimenő forgalomhoz hozzáadhatunk egy másik terheléselosztót a belső oldalon. Amikor a kiszolgáló S1 elindítja a forgalmat, ugyanez az elv érvényes. A forgalom eléri a belső terheléselosztást (iLB), amely kiválaszt egy tűzfalat, amely ezután lefordítja a NAT-ot a külső megoldáshoz:
Háromlábú tűzfalak
Problémák merülnek fel, amikor egy másik felületet adunk hozzá a tűzfalhoz, és le kell tiltania a NAT-fordítást a belső zónák között. Ebben az esetben lásd a B és a C alhálózatot:
A belső zónák (B és C alhálózatok) közötti L3-útválasztás mindkét esetben NAT nélkül végez terheléselosztást. Ez a beállítás egyértelműbbé válik a forgalmi folyamatokat tekintve, beleértve a terheléselosztókat is egy másik nézetben. Az alábbi ábrán az látható, hogy a belső terheléselosztók (iLB) egy adott hálózati adapterhez vannak csatlakoztatva az FW-ken:
Az L3 forgalommal (NAT nélkül) az S2 az S1 IP-címet fogja látni forráscímként. Az S2 ezután elküldi a B alhálózat visszatérési forgalmát (amelyhez az S1-IP tartozik) a C alhálózat iLB-jének. Mivel a B alhálózat iLB-ja és a C alhálózat iLB-ja nem szinkronizálja a munkamenet-állapotokat, a terheléselosztási algoritmus forgalmától függően előfordulhat, hogy az FW-2-n végződik. Az FW-2 alapértelmezés szerint nem tud semmit a kezdeti (zöld) csomagról, ezért megszakad a kapcsolat.
Egyes tűzfalgyártók megpróbálják megőrizni a kapcsolat állapotát a tűzfalak között, de szinte azonnali szinkronizálásra lenne szükségük ahhoz, hogy naprakészek legyenek a kapcsolati állapotokban. Érdeklődjön a tűzfal gyártójánál, hogy javasolja-e ezt a beállítást.
Ezt a problémát annak kiküszöbölésével lehet leghatékonyabban kezelni. A fenti példában ez a megoldás a C alhálózat megszüntetését jelenti, amely a virtualizált virtuális hálózatok előnyeit nyújtja.
Alhálózati gazdagépek elkülönítése hálózati biztonsági csoportokkal
Ha két virtuális gép található egyetlen alhálózatban, olyan NSG alkalmazható, amely elkülöníti a kettő közötti forgalmat. Alapértelmezés szerint a virtuális hálózaton belüli forgalom teljes mértékben engedélyezett. Az NSG-n Az összes elutasítása szabály hozzáadásával az összes virtuális gép elkülöníthető egymástól.
A virtuális hálózatok ugyanazokat a háttérbeli (virtuális) útválasztókat használják
A virtuális hálózatok/alhálózatok egyetlen háttérbeli útválasztórendszert használnak az Azure-ból, ezért nem kell útválasztó IP-címét megadni minden alhálózathoz. Az útvonal célhelye bárhol lehet ugyanazon a virtuális hálózaton vagy azon kívül is.
A virtualizált hálózatok segítségével minden alhálózaton szabályozhatók az útvonalak. Ezek az útvonalak egy másik alhálózat ugyanazon IP-címére is mutathatnak. Az alábbi képen ez az iLB lenne a D alhálózatban, amely a két tűzfal terheléselosztását végzi. Ahogy az S1 elindítja a forgalmat (zöld), a terhelés kiegyensúlyozott lesz például az FW-1 felé. Az FW-1 ekkor csatlakozik az S2-hez (továbbra is zöld). Az S2 elküldi a válaszforgalmat az S1 IP-címére (mivel a NAT le van tiltva). Az útvonaltáblák miatt az S2 ugyanazt az iLB IP-címet használja, mint az átjáró. Az iLB megfelelhet a kezdeti munkamenet felé történő forgalomnak, ezért mindig visszairányítja ezt a forgalmat az FW-1-hez. Az FW-1 ezután elküldi az S1-nek, létrehozva egy szinkron forgalmi folyamatot.
Ahhoz, hogy ez a beállítás működjön, az FW-nek rendelkeznie kell egy útvonaltáblával (belsőleg), amely a B alhálózatot és a C alhálózatot az alapértelmezett GW alhálózatra irányítja. Ez az alhálózati GW az első logikailag elérhető IP-cím a virtuális hálózat alhálózati tartományában.
Fordítottproxy-szolgáltatásokra gyakorolt hatás
Fordított proxyszolgáltatás üzembe helyezésekor általában az FW mögött lenne. Ehelyett az FW-vel összhangban helyezheti el, és ténylegesen átirányíthatja a forgalmat az FW-n keresztül. Ennek a beállításnak az az előnye, hogy a fordított proxyszolgáltatás a csatlakozó ügyfél eredeti IP-címét látja :
Ehhez a konfigurációhoz az E alhálózat útvonaltábláinak a B és a C alhálózatot kell a belső terheléselosztón keresztül irányítaniuk. Egyes fordított proxyszolgáltatások beépített tűzfallal rendelkeznek, amelyek lehetővé teszik az FW együttes eltávolítását ebben a hálózati folyamatban. A beépített tűzfalak a fordított proxyról egyenesen a B/C alhálózati kiszolgálókra mutatnak.
Ebben az esetben szükség lesz az SNAT-ra a fordított proxyn is annak érdekében, hogy megakadályozható legyen a visszatérő forgalom áthaladása az A alhálózaton és FW-k általi elutasítása.
VPN/ER
Az Azure BGP-kompatibilis/magas rendelkezési állású VPN/ER-szolgáltatásokat biztosít Azure-beli virtuális hálózati átjárókon keresztül. A legtöbb fejlesztő ezeket a háttérbeli vagy nem internetes kapcsolatokhoz tartja fenn. Ez a beállítás azt jelenti, hogy az útválasztási táblának a kapcsolatok mögötti alhálózatokat is el kell fogadnia. Bár nincs nagy különbség a B/C alhálózati kapcsolat között, a visszatérési forgalom tervezésekor a kép kitöltése a következő:
Ebben az architektúrában például a B alhálózatból az X alhálózatba tartó, az FW-t elérő forgalmat az iLB-re küldené a rendszer, amely ezt követően valamelyik tűzfalhoz továbbítja azt. Az FW-n belüli belső útvonalválasztás a forgalmat visszaküldi a GW alhálózatra (az első elérhető IP-cím a D alhálózatban). A forgalmat nem kell közvetlenül az átjáróberendezésnek elküldenie, mivel a D alhálózat egy másik útvonalán az X alhálózat egy útvonala lesz, amely a virtuális hálózati átjáróra irányítja. A tényleges útválasztásról az Azure-hálózatkezelés gondoskodik.
Az X alhálózatból érkező visszatérési forgalom a D alhálózat iLB-jének lesz továbbítva. A GatewaySubnet egy egyéni útvonalsal is rendelkezik, amely a B-C alhálózatot az iLB-hez irányítja. A D alhálózat nem az iLB-n keresztül van. Ezt a rendszer normál virtuális hálózatok közötti útválasztásként kezeli.
Bár nem szerepel a rajzon, érdemes megfontolni, hogy a B/C/D/átjáró alhálózat szintén tartalmazza az A alhálózat iLB felé mutató útvonalát is. Ez a megoldás elkerüli a "normál" VNET-útválasztást az FW-k megkerüléséhez. Az A alhálózat csak egy újabb alhálózat a VNET-en az Azure hálózati verem szerint. Nem kezeli az A alhálózatot, bár DMZ/Internet/stb. néven kezeli.
Összegzés
Röviden, a helyszíni (fizikai/VLAN-alapú) hálózatok tűzfalait úgy kezeli, hogy a (virtuális vagy fizikai) illesztők száma nem ugyanannyi, mint az Azure-ban. Ha szükséges, ez továbbra is lehetséges (bizonyos mértékig), de jobb megoldások is elérhetők a feladatátvételi állásidő minimalizálásához: aktív–aktív implementációk és üres útválasztási táblázatok.
A teljes forgalom esetében a terheléselosztók átjárókként történő használatára vonatkozóan további információt a magas rendelkezésre állású portok áttekintésében talál.
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ő:
- Roelf Zomerman | Vezető felhőmegoldás-tervező
Következő lépések
További információ az összetevők technológiáiról:
Kapcsolódó erőforrások
Ismerkedjen meg a kapcsolódó architektúrákkal:
- Biztonságos hibrid hálózat megvalósítása
- Hibrid kapcsolat
- Helyszíni hálózat kiterjesztése VPN használatával
- Választás a virtuális hálózatok közötti társviszony-létesítés és a VPN-átjárók között
- Hibrid VPN-kapcsolat hibaelhárítása
- Küllős hálózati topológia az Azure-ban
- önálló kiszolgálók Csatlakozás az Azure Hálózati Adapter használatával