AZ IP-címzés megtervezése
Fontos, hogy szervezete az Azure-ban ip-címzést tervez. A tervezés biztosítja, hogy az IP-címtér ne legyen átfedésben a helyszíni helyek és az Azure-régiók között.
Kialakítási szempontok:
A helyszíni és az Azure-régiók között átfedésben lévő IP-címterek jelentős versengési kihívásokat okoznak.
Az Azure VPN Gateway a hálózati címfordítási (NAT) képességen keresztül képes átfedésben lévő, egymást átfedő IP-címterekkel rendelkező helyszíni helyeket csatlakoztatni. Ez a funkció általánosan elérhető az Azure Virtual WAN-ban és az önálló Azure VPN Gatewayben.
A virtuális hálózat létrehozása után címteret adhat hozzá. Ehhez a folyamathoz nincs szükség leállásra, ha a virtuális hálózat már csatlakozik egy másik virtuális hálózathoz virtuális hálózati társviszony-létesítésen keresztül. Ehelyett minden távoli társviszony-létesítésnek újraszinkronizálási műveletet kell végrehajtania a hálózati terület módosítása után.
Az Azure öt IP-címet foglal le minden alhálózaton belül. Vegye figyelembe ezeket a címeket a virtuális hálózatok és az alhálózatok méretezése során.
Egyes Azure-szolgáltatások dedikált alhálózatokat igényelnek. Ezek a szolgáltatások közé tartozik az Azure Firewall és az Azure VPN Gateway.
Alhálózatokat delegálhat bizonyos szolgáltatásokhoz, hogy létrehozhasson egy szolgáltatáspéldányt az alhálózaton belül.
Tervezési javaslatok:
Előre tervezze meg a nem átfedésben lévő IP-címtereket az Azure-régiókban és a helyszíni helyeken.
Használjon IP-címeket a privát internet címfoglalásából, más néven RFC 1918-címekből.
Ne használja a következő címtartományokat:
224.0.0.0/4
(csoportos küldés)255.255.255.255/32
(közvetítés)127.0.0.0/8
(visszacsatolás)169.254.0.0/16
(link-local)168.63.129.16/32
(belső DNS)
A privát IP-címek korlátozott rendelkezésre állásával rendelkező környezetek esetében fontolja meg az IPv6 használatát. A virtuális hálózatok lehetnek csak IPv4-es vagy kettős veremŰ IPv4+IPv6.
Ne hozzon létre olyan nagy virtuális hálózatokat, mint a
/16
. Biztosítja, hogy az IP-címtér ne vessz el. A legkisebb támogatott IPv4-alhálózat az/29
, és a legnagyobb az/2
osztály nélküli tartományközi útválasztás (CIDR) alhálózat-definíciók használatakor. Az IPv6-alhálózatoknak pontosan/64
méretben kell lenniük.Ne hozzon létre virtuális hálózatokat a szükséges címtér előzetes megtervezése nélkül.
Ne használjon nyilvános IP-címeket virtuális hálózatokhoz, különösen akkor, ha a nyilvános IP-címek nem tartoznak a szervezethez.
Vegye figyelembe a használni kívánt szolgáltatásokat, vannak fenntartott IP-címekkel (IP-címekkel) rendelkező szolgáltatások, például AKS CNI hálózatkezeléssel
Az IPv4 kimerülésének megakadályozása érdekében használjon nemroutable landing zone küllős virtuális hálózatokat és Azure Private Link szolgáltatást .
IPv6-szempontok
Egyre több szervezet alkalmazza az IPv6-ot a környezetükben. Ezt a bevezetést a nyilvános IPv4-helykihasználtság, a privát IPv4-szűkösség, különösen a nagy méretű hálózatokon belül, valamint a csak IPv6-ügyfelekhez való kapcsolódás szükségessége vezérli. Az IPv6 bevezetésének nincs univerzális megközelítése. Az IPv6 tervezésekor és meglévő Azure-hálózatokban való implementálása során azonban követhet ajánlott eljárásokat.
Az Azure-hoz készült Microsoft felhőadaptálási keretrendszer segít megérteni azokat a szempontokat, amelyek figyelembe veendők a felhőben lévő rendszerek létrehozásakor. A fenntartható rendszerek tervezésének ajánlott architekturális eljárásairól az Azure kezdőzónájának tervezési alapelveit ismertető cikkben olvashat. A felhőarchitektúrával kapcsolatos részletes javaslatokért és ajánlott eljárásokért, beleértve a referenciaarchitektúrák üzembe helyezését, a diagramokat és az útmutatókat, tekintse meg az Architektúraközpont IPv6-hoz készült útmutatóját.
Kialakítási szempontok:
Az IPv6 bevezetésének fázisa. Üzleti igényeinek megfelelően szükség esetén implementálhatja az IPv6-ot. Ne feledje, hogy az IPv4 és az IPv6 mindaddig létezhet, amíg szükséges.
Azokban az esetekben, amikor az alkalmazások szolgáltatásként nyújtott infrastruktúrára (IaaS) támaszkodnak, amelyek teljes IPv6-támogatással rendelkeznek, például virtuális gépek (VM-ek), az IPv4 és az IPv6 natív teljes körű használata lehetséges. Ez a konfiguráció elkerüli a fordítási bonyodalmakat, és a legtöbb információt biztosítja a kiszolgálónak és az alkalmazásnak.
IPv6-címmel helyezhet üzembe alapszintű termékváltozattal rendelkező, internetkapcsolattal rendelkező Azure-terheléselosztókat. Ez a konfiguráció natív, végpontok közötti IPv6-kapcsolatot tesz lehetővé a nyilvános internet és az Azure-beli virtuális gépek között a terheléselosztón keresztül. Ez a megközelítés a virtuális gépek és az IPv6-kompatibilis ügyfelek közötti natív, végpontok közötti kimenő kapcsolatokat is megkönnyíti a nyilvános interneten. Vegye figyelembe, hogy ehhez a megközelítéshez minden eszközre szükség van az IPv6-forgalom kezeléséhez.
A natív végpontok közötti megközelítés a leghasznosabb a közvetlen kiszolgálók közötti vagy az ügyfelek közötti kommunikációhoz. Ez nem hasznos a legtöbb webszolgáltatás és alkalmazás esetében, amelyeket általában tűzfalak, webalkalmazási tűzfalak vagy fordított proxyk védenek.
Előfordulhat, hogy egyes összetett üzemelő példányok és alkalmazások, amelyek külső szolgáltatások, szolgáltatásként nyújtott platform (PaaS) szolgáltatások és háttérmegoldások kombinációját használják, nem támogatják a natív IPv6-ot. Ezekben az esetekben NAT/NAT64 vagy IPv6 proxymegoldás használatával kell engedélyeznie az IPv6 és az IPv4 közötti kommunikációt.
Ha az alkalmazásarchitektúra összetettsége vagy más tényezők, például a betanítási költségek jelentősnek minősülnek, érdemes lehet továbbra is iPv4-alapú infrastruktúrát használni a háttérrendszeren, és üzembe helyezni egy külső hálózati virtuális berendezést (NVA) kétveremes IPv4/IPv6-átjárót a szolgáltatásnyújtáshoz.
Az NVA-t használó tipikus üzemelő példányok a következőképpen nézhetnek ki:
Tervezési javaslatok:
Íme egy közelebbi pillantás egy tipikus architektúra megjelenésére:
Helyezze üzembe az NVA-t rugalmas vezénylésű virtuálisgép-méretezési csoportokban (VMSS Flex) a rugalmasság érdekében, és tegye elérhetővé az interneten az Azure Load-Balanceren keresztül, amely nyilvános IP-címmel rendelkezik.
Az NVA-k elfogadják az IPv4- és IPv6-forgalmat, és lefordítják csak IPv4-forgalommá, hogy elérhessék az alkalmazást az alkalmazás alhálózatán. A megközelítés csökkenti az alkalmazás csapatának összetettségét, és csökkenti a támadási felületet.
Az Azure Front Door üzembe helyezése globális útválasztást biztosít a webes forgalom számára.
Az Azure Front Door funkciói közé tartozik az IPv6-ügyfélkérések proxyzása és a csak IPv4-alapú háttérrendszer felé irányuló forgalom, az itt látható módon:
Ezek a fő különbségek az NVA és az Azure Front Door megközelítése között:
- Az NVA-k ügyfél által felügyeltek, az OSI-modell 4. rétegében működnek, és az alkalmazással megegyező Azure-beli virtuális hálózaton, privát és nyilvános felületen telepíthetők.
- Az Azure Front Door egy globális Azure PaaS-szolgáltatás, amely a 7. rétegben (HTTP/HTTPS) működik. Az alkalmazás háttérrendszere egy internetre néző szolgáltatás, amely zárolható, hogy csak az Azure Front Doorból érkező forgalmat fogadja el.
Összetett környezetekben mindkettő kombinációját használhatja. Az NVA-kat egy regionális üzembe helyezésen belül használják. Az Azure Front Door segítségével a forgalmat egy vagy több regionális üzembe helyezéshez irányíthatja különböző Azure-régiókban vagy más internetes helyeken. A legjobb megoldás meghatározásához javasoljuk, hogy tekintse át az Azure Front Door képességeit és a termék dokumentációját.
IPv6 virtuális hálózati CIDR-blokkok:
- Egyetlen IPv6 osztály nélküli tartományközi útválasztási (CIDR) blokkot társíthat, ha új virtuális hálózatot hoz létre egy meglévő Azure-beli üzembe helyezésben az előfizetésében. Az IPv6-alhálózat méretének /64-nek kell lennie. Ennek a méretnek a használata biztosítja a jövőbeli kompatibilitást, ha úgy dönt, hogy engedélyezi az alhálózat helyszíni hálózathoz való átirányítását. Egyes útválasztók csak /64 IPv6-útvonalakat fogadnak el.
- Ha már rendelkezik olyan virtuális hálózattal, amely csak az IPv4-et támogatja, és az alhálózaton lévő erőforrások csak IPv4 használatára vannak konfigurálva, engedélyezheti az IPv6-támogatást a virtuális hálózathoz és az erőforrásokhoz. A virtuális hálózat képes kettős verem módban működni, így az erőforrások IPv4, IPv6 vagy mindkettőn keresztül kommunikálhatnak. Az IPv4 és az IPv6 kommunikáció független egymástól.
- A virtuális hálózat és alhálózatok IPv4-támogatását nem tilthatja le. Az IPv4 az Azure-beli virtuális hálózatok alapértelmezett IP-címzési rendszere.
- IPv6 CIDR-blokk társítása a virtuális hálózathoz és alhálózathoz vagy BYOIP IPv6-hez. A CIDR-jelölés egy IP-cím és annak hálózati maszkjának ábrázolása. A címek formátuma a következő:
- Az egyes IPv4-címek 32 bitesek, négy, legfeljebb három tizedesjegyből álló csoporttal. Például:
10.0.1.0
. - Az IPv4 CIDR-blokkok négy, legfeljebb három tizedesjegyből álló csoportot alkotnak, 0 és 255 között, pontokkal elválasztva, majd egy perjelet és egy 0 és 32 közötti számot követnek. Például:
10.0.0.0/16
. - Az egyes IPv6-címek 128 bitesek. Nyolc négy hexadecimális számjegyből álló csoporttal rendelkezik. Például:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
. - Az IPv6 CIDR-blokkok négy, legfeljebb négy hexadecimális számjegyből álló csoportot alkotnak, kettőspontokkal elválasztva, majd kettősponttal, majd egy perjellel és egy 1 és 128 közötti számmal. Például:
2001:db8:1234:1a00::/64
.
- Az egyes IPv4-címek 32 bitesek, négy, legfeljebb három tizedesjegyből álló csoporttal. Például:
- Frissítse az útvonaltáblákat az IPv6-forgalom átirányításához. Nyilvános forgalom esetén hozzon létre egy útvonalat, amely az alhálózatról a VPN Gatewayre vagy egy Azure ExpressRoute-átjáróra irányítja az összes IPv6-forgalmat.
- Frissítse a biztonsági csoport szabályait, hogy az IPv6-címekre vonatkozó szabályokat is tartalmazzon. Ezzel lehetővé teszi, hogy az IPv6-forgalom átfolyjon a példányokra és onnan. Ha az alhálózat felé és onnan érkező forgalom szabályozására hálózati biztonsági csoportszabályok vonatkoznak, az IPv6-forgalomra vonatkozó szabályokat kell tartalmaznia.
- Ha a példány típusa nem támogatja az IPv6-ot, használjon kettős vermet, vagy helyezzen üzembe egy NVA-t a korábban leírtak szerint, amely IPv4-ről IPv6-ra fordít.
IP-címkezelés (IPAM) eszközök
Az IPAM-eszközökkel segíthet az IP-címek tervezésében az Azure-ban, mivel központosított felügyeletet és láthatóságot biztosít, így megelőzheti az IP-címterek közötti átfedéseket és ütközéseket. Ez a szakasz végigvezeti az IPAM-eszközök bevezetésének alapvető szempontjain és javaslatain.
Kialakítási szempontok:
A követelményektől és a szervezet méretétől függően számos IPAM-eszköz érhető el. A lehetőségek az alapszintű Excel-alapú leltártól a nyílt forráskódú, közösségi alapú megoldásig vagy a speciális funkciókkal és támogatással rendelkező átfogó vállalati termékekig terjednek.
A megvalósítandó IPAM-eszköz kiértékelésekor vegye figyelembe ezeket a tényezőket:
- A szervezet által igényelt minimális funkciók
- Teljes bekerülési költség (TCO), beleértve a licencelést és a folyamatos karbantartást
- Naplók, naplózás és szerepköralapú hozzáférés-vezérlők
- Hitelesítés és engedélyezés a Microsoft Entra-azonosítón keresztül
- API-val elérhető
- Integráció más hálózatkezelési eszközökkel és rendszerekkel
- Aktív közösségi támogatás vagy a szoftverszolgáltató által nyújtott támogatás szintje
Fontolja meg egy nyílt forráskódú IPAM-eszköz, például az Azure IPAM kiértékelését. Az Azure IPAM egy azure-platformra épülő egyszerűsített megoldás. Automatikusan felderíti az IP-címek kihasználtságát az Azure-bérlőn belül, és lehetővé teszi, hogy mindezt egy központi felhasználói felületen vagy egy RESTful API-val kezelje.
Fontolja meg a szervezetek működési modelljét és az IPAM-eszköz tulajdonjogát. Az IPAM-eszköz implementálásának célja, hogy egyszerűsítse az új IP-címterek kérésének folyamatát az alkalmazáscsapatok számára függőségek és szűk keresztmetszetek nélkül.
Az IPAM-eszköz funkcióinak fontos része az IP-címtartomány-használat leltározása és logikai rendszerezése.
Tervezési javaslatok:
A nem átfedésben lévő IP-címterek megőrzésének folyamatának támogatnia kell a különböző méretek kérését az egyes alkalmazás kezdőzónáinak igényei alapján.
- Alkalmazhat például pólóméretezést, hogy megkönnyítse az alkalmazáscsapatok számára az igényeik leírását:
- Kicsi –
/24
256 IP-cím - Közepes –
/22
1024 IP-cím - Nagy –
/20
4096 IP-cím
- Kicsi –
- Alkalmazhat például pólóméretezést, hogy megkönnyítse az alkalmazáscsapatok számára az igényeik leírását:
Az IPAM-eszköznek rendelkeznie kell egy API-val a nem átfedésben lévő IP-címterek megőrzéséhez az infrastruktúra mint kód (IaC) megközelítés támogatásához. Ez a funkció elengedhetetlen az IPAM előfizetéses értékesítés folyamatba való zökkenőmentes integrálásához is, ezáltal csökkentve a hibák kockázatát és a manuális beavatkozás szükségességét.
- IaC-megközelítésre példa a Bicep az üzembehelyezési szkript funkciójával vagy a Terraform-adatforrásokkal, amelyek dinamikusan lekérik az adatokat az IPAM API-ból.
Hozzon létre egy szisztematikus elrendezést az IP-címterekhez az Azure-régiók és számítási feladatok archetípusainak megfelelően strukturálva, biztosítva a tiszta és nyomon követhető hálózati leltárt.
A számítási feladatok leszerelési folyamatának magában kell foglalnia a már nem használt IP-címterek eltávolítását, amelyeket később a közelgő új számítási feladatokhoz lehet felhasználni, elősegítve a hatékony erőforrás-kihasználtságot.
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: