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.
• 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

• 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.