Zabránění vyčerpání IPv4 v Azure

Tento článek popisuje, jak minimalizovat spotřebu privátního adresního prostoru při vytváření rozsáhlých sítí v Azure. Pokud nejsou vytvořené správné zásady přidělování, budete možná muset minimalizovat spotřebu adresního prostoru a dojde k přidělení privátních IP adres virtuálním sítím Azure. Tento článek představuje dvě metody pro správnou správu IP adres v Azure.

Podrobnosti scénáře

Podnikové sítě obvykle používají adresní prostory, které jsou v privátních rozsahech adres IPv4 definované v DOKUMENTU RFC 1918. Rozsahy adres jsou 10.0.0.0/8, 172.16.0.0/12 a 192.168.0.0/16. V místních prostředích poskytují tyto rozsahy dostatek IP adres, aby splňovaly požadavky i největších sítí. V důsledku toho řada organizací vyvíjí postupy správy adres, které upřednostňují jednoduché konfigurace směrování a agilní procesy pro přidělování IP adres. Efektivní použití adresního prostoru není prioritou.

V cloudu jsou rozsáhlé hybridní sítě snadno sestavitelné a některé běžné architektonické vzory, jako jsou mikroslužby nebo kontejnerizace, můžou vést ke zvýšení spotřeby IP adres. Proto je důležité tyto postupy správy adres upravit. V cloudovém prostředí zachází s privátními adresami IPv4 jako s omezeným prostředkem.

Rozsahy IP adres virtuální sítě Azure

Ve virtuálních sítích Azure doporučujeme použít bloky adres definované dokumentem RFC 1918. Tyto bloky adres jsou určené pro privátní sítě pro obecné účely a nesměrovatelné na veřejném internetu.

Můžete použít jiné rozsahy, ale než tyto rozsahy použijete ve virtuální síti, přečtěte si dokumentaci IANA (Internet Assigned Numbers Authority) a seznamte se s možnými důsledky pro vaše prostředí. Můžete použít následující rozsahy:

• Sdílený adresní prostor definovaný dokumentem RFC 6598 pro překlad síťových adres na úrovni operátora (NAT), který se v Azure Virtual Network považuje za privátní adresní prostor. Blok adresy je 100.64.0.0/10.
• Veřejné internetové směrovatelné IP adresy, které vaše organizace nevlastní. Tento postup se nedoporučuje, protože prostředky ve virtuální síti nemají přístup ke koncovým bodům internetu, které jsou vystavené přes veřejné IP adresy.
• Bloky adres pro zvláštní účely definované IANA, například 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24 a 233.252.0.0/24.

Ve virtuálních sítích Azure nemůžete použít následující rozsahy IP adres:

• 224.0.0.0/4 (vícesměrové vysílání)
• 255.255.255.255/32 (Vysílání)
• 127.0.0.0/8 (zpětné smyčky)
• 169.254.0.0/16 (link-local)
• 168.63.129.16/32 (interní DNS)

Zarovnání cílové zóny Azure

Doporučení v tomto článku jsou určená pro scénáře založené na architektuře cílové zóny Azure. V pokynech se předpokládá, že:

• Každá oblast má hvězdicovou topologii.
• Hvězdicové sítě, které jsou v různých oblastech, jsou vzájemně propojené prostřednictvím globálního partnerského vztahu virtuálních sítí nebo připojení ke stejnému okruhu nebo okruhům Azure ExpressRoute.
• Hvězdicové sítě jsou připojené k místním lokalitám prostřednictvím kombinace okruhů ExpressRoute a sítí VPN typu site-to-site.

Následující diagram znázorňuje ukázkovou architekturu. Doporučení platí stejně pro sítě, které jsou postavené na službě Azure Virtual WAN, která má v každé oblasti také hvězdicové sítě.

Stáhněte si soubor PowerPointu této architektury.

Ve scénáři založeném na architektuře cílové zóny Azure se aplikace nasazují ve vlastní cílové zóně. Každá cílová zóna obsahuje paprskovou virtuální síť, která je v partnerském vztahu k regionálnímu centru. Paprskové virtuální sítě jsou nedílnou součástí podnikové sítě a přiřazují směrovatelné adresy IPv4. Tyto adresy jsou jedinečné v celé podnikové síti. Všechny komponenty architektury nasazené ve službě Azure Virtual Network tedy využívají adresy IPv4 v adresního prostoru podnikové sítě, i když koncové body, které musí být dosažitelné z celé podnikové sítě, jenom několik komponent. Těmito komponentami architektury můžou být virtuální počítače, síťová zařízení třetích stran nebo síťové virtuální zařízení (NVA) nebo služby paaS (platforma jako služba) vložené do virtuální sítě.

Ve zbývající části tohoto článku odkazuje front-endová komponenta na komponentu aplikace, která je dostupná z celé podnikové sítě nebo mimo cílovou zónu komponenty. Back-endová komponenta odkazuje na komponentu aplikace, která nezpřístupňuje koncové body v podnikové síti a musí být dostupná jenom z vlastní cílové zóny. Například webová aplikace, která zveřejňuje koncový bod, je front-endová komponenta a databáze, která nezpřístupňuje koncový bod, je back-endová komponenta.

Následující části popisují dvě metody minimalizace spotřeby privátního adresního prostoru při vytváření rozsáhlých sítí v Azure.

Metoda 1: Nesměrovatelné virtuální sítě paprskové cílové zóny

RFC 1918 zablokuje IP adresu mimo 32bitový adresní prostor IPv4 a zpřístupňuje je nesměrovatelným na veřejném internetu, takže je můžete znovu použít v několika privátních sítích pro interní komunikaci. Tato metoda je založena na stejném principu, který se vztahuje na privátní adresní prostor. Jeden nebo více rozsahů adres se vyryje z celého privátního adresního prostoru používaného vaší organizací a deklaruje nesměrovatelné v rámci podnikové sítě vaší organizace. Rozsahy adres se znovu používají ve více cílových zónách. V důsledku toho každá cílová zóna:

• Je přiřazen směrovatelný adresní prostor, který je tvořen jedním nebo více rozsahy adres. Vaše organizace centrálně spravuje rozsahy adres a jedinečně je přiřazuje cílové zóně pro komunikaci s podnikovou sítí. Adresy v směrovatelném prostoru se přiřazují ke komponentám front-endu.
• Může použít nesměrovatelný adresní prostor, což jsou rozsahy adres, které vaše organizace deklaruje nesměrovatelné v podnikové síti. Tyto rezervované rozsahy můžete použít pro interní komunikaci ve všech cílových zónách. Adresy v nesměrovatelném prostoru se přiřazují k back-endovým komponentám.

V hvězdicové síti Azure, která je spravovaná zákazníkem nebo založená na službě Virtual WAN, nemůžou mít dvě nebo více paprskových virtuálních sítí překrývající se adresní prostory IP adres. Nesměrovatelné bloky adres nelze přiřadit paprsku cílové zóny. Partnerský vztah virtuálních sítí není přenositelný, takže virtuální síť paprskové cílové zóny může vytvořit partnerský vztah s virtuální sítí druhé úrovně s nesměrovatelným adresním prostorem. Následující diagram znázorňuje topologii duální virtuální sítě pro cílové zóny.

Stáhněte si soubor PowerPointu této architektury.

Každá cílová zóna aplikace obsahuje dvě partnerské virtuální sítě. Jedna virtuální síť má směrovatelné IP adresy a hostitele front-endových komponent. Druhá virtuální síť má nesměrovatelné IP adresy a hostuje back-endové komponenty. Směrovatelné partnerské vztahy cílové zóny s regionálním centrem. Nesměrovatelné paprskové paprsky cílové zóny s paprsky směrovatelné cílové zóny. Partnerský vztah virtuálních sítí není přenositelný, takže nesměrovatelné předpony nejsou viditelné pro oblastní centrum ani zbytek podnikové sítě. Směrovatelné virtuální sítě nemůžou používat nesměrovatelné rozsahy adres. Některé organizace mají fragmentovaný adresní prostor, který je už přiřazený k směrovatelným sítím. Může být obtížné identifikovat nepoužívané velké bloky adres a deklarovat je nesměrovatelné. V takovém případě zvažte nepoužívané adresy, které nejsou zahrnuty do adresního prostoru RFC 1918. Předchozí diagram obsahuje příklad adres NAT na úrovni operátora, jako je RFC 6598, v nesměrovatelných virtuálních sítích.

Migrace cílové zóny jedné virtuální sítě

Partnerský vztah virtuálních sítí poskytuje úplné připojení vrstvy 3 mezi dvěma partnerskými virtuálními sítěmi. Komponenty aplikací nasazené v tradičních cílových zónách virtuální sítě, které vzájemně komunikují přes IP adresu, se dají volně přesouvat mezi směrovatelnými a nesměrovatelnými paprskovými virtuálními sítěmi v cílové zóně. Tato část popisuje dva typické vzory migrace.

Následující aplikace jsou vystavené prostřednictvím kontrolerů doručování aplikací vrstvy 7:

Stáhněte si soubor PowerPointu této architektury.

Aplikace vystavené prostřednictvím kontrolerů doručování aplikací vrstvy 7 je možné přesunout do nesměrovatelného paprsku. Kontroler doručování aplikací je jediná front-endová komponenta, která se musí nacházet v paprsku směrovatelné cílové zóny.

Následující aplikace jsou vystavené prostřednictvím nástroje pro vyrovnávání zatížení Azure:

Stáhněte si soubor PowerPointu této architektury.

Pokud aplikace zpřístupňuje své koncové body prostřednictvím nástroje pro vyrovnávání zatížení Azure, výpočetní instance, které jsou součástí back-endového fondu nástroje pro vyrovnávání zatížení, musí zůstat ve stejné virtuální síti. Nástroje pro vyrovnávání zatížení Azure podporují pouze back-endové instance ve své vlastní virtuální síti.

Odchozí závislosti

Back-endové komponenty aplikace nemusí být dostupné ani přijímat příchozí připojení z podnikové sítě, ale často mají odchozí závislosti. Back-endové komponenty se můžou muset připojit ke koncovým bodům, které jsou mimo jejich cílové zóny v instancích, jako je překlad DNS, řadiče domény služby Doména služby Active Directory Services, přístup ke koncovým bodům aplikace, které jsou vystavené jinými cílovými zónami, nebo přístup k protokolování nebo záložním zařízením.

Když služby inicialují připojení v nesměrovatelných paprskových virtuálních sítích, musíte pro připojení za směrovatelnou IP adresou implementovat zdrojový překlad adres (SNAT). Pokud chcete implementovat SNAT, nasaďte zařízení podporující překlad adres (NAT) do směrovatelné virtuální sítě. Každá cílová zóna spouští vlastní vyhrazené síťové virtuální zařízení PROT. Existují dvě možnosti implementace SNAT v cílové zóně: Azure Firewall nebo síťové virtuální zařízení třetích stran. V obou případech musí být všechny podsítě v nesměrovatelném paprsku přidružené k vlastní směrovací tabulce. Jak je znázorněno v následujícím diagramu, směrovací tabulka předává provoz do cílů mimo cílovou zónu do zařízení SNAT. Azure NAT Gateway nepodporuje SNAT pro provoz směřující do privátního adresního prostoru IP adres, jako je například prostor RFC 1918.

Stáhněte si soubor PowerPointu této architektury.

Implementace SNAT přes Azure Firewall

Azure Firewall:

• Poskytuje vysokou dostupnost.
• Poskytuje nativní škálovatelnost a tři různé skladové položky. SNAT není úloha náročná na zdroje, proto nejprve zvažte základní skladovou položku. Pro cílové zóny, které vyžadují velké objemy odchozího provozu z nesměrovatelného adresního prostoru, použijte standardní skladovou položku.
• Provádí SNAT pro provoz za privátními IP adresami kterékoli z jejích instancí. Každá instance může používat všechny neprivilegované porty.

Následující diagram znázorňuje rozložení cílové zóny pro implementaci SNAT v hvězdicové síťové topologii pomocí služby Azure Firewall.

Stáhněte si soubor PowerPointu této architektury.

Všechny podsítě v nesměrovatelném paprsku musíte přidružit k vlastní směrovací tabulce, aby se provoz odesílal do cílů mimo cílovou zónu do služby Azure Firewall.

Následující diagram znázorňuje rozložení cílové zóny pro implementaci SNAT v hvězdicové síti založené na službě Virtual WAN pomocí služby Azure Firewall.

Stáhněte si soubor PowerPointu této architektury.

Všechny podsítě v nesměrovatelném paprsku nebo paprsky, které nejsou připojené ke službě Virtual WAN, musíte přidružit vlastní směrovací tabulku pro odesílání provozu do cílů mimo cílovou zónu do služby Azure Firewall.

Pokud chcete zajistit prostředky v nesměrovatelném paprskovém přístupu k směrovatelným IP adresám mimo jejich cílovou zónu, musíte nasadit bránu Azure Firewall s možností Provést SNAT nastavenou na Hodnotu Always v směrovatelném paprsku cílové zóny. Pokyny ke konfiguraci služby Azure Firewall pro implementaci SNAT na všech přijatých připojeních najdete ve veřejné dokumentaci. Následující snímek obrazovky ukazuje požadovanou konfiguraci pro použití služby Azure Firewall jako zařízení NAT pro připojení iniciovaná prostředky v nesměrovatelných virtuálních sítích.

Implementace SNAT prostřednictvím síťových virtuálních zařízení třetích stran

Síťová virtuální zařízení třetích stran s funkcemi překladu adres (NAT) jsou k dispozici na Azure Marketplace. Čím se vyznačují:

• Podrobná kontrola nad horizontálním navýšením kapacity a horizontálním navýšením kapacity
• Podrobná kontrola fondu NAT.
• Vlastní zásady překladu adres (NAT), jako je použití různých adres NAT v závislosti na vlastnostech příchozího připojení, jako je zdrojová nebo cílová IP adresa.

Zvažte následující doporučení:

• Pro zajištění vysoké dostupnosti nasaďte clustery s alespoň dvěma síťovými virtuálními zařízeními. Pomocí nástroje pro vyrovnávání zatížení Azure distribuujte příchozí připojení z nesměrovatelné virtuální sítě paprskového paprsku do síťových virtuálních zařízení. Vyžaduje se pravidlo vyrovnávání zatížení portů s vysokou dostupností, protože cluster implementuje SNAT na všech připojeních, která opustí cílovou zónu. Azure Standard Load Balancer podporuje pravidla vyrovnávání zatížení portů s vysokou dostupností.
• Stack Azure SDN podporuje síťová virtuální zařízení s jednou paží a duálními rameny. Jednoruční síťová virtuální zařízení jsou upřednostňovaná, protože snižují spotřebu adresního prostoru ve virtuálních sítích směrovatelných paprsků.

Následující diagram znázorňuje rozložení cílové zóny pro implementaci SNAT v hvězdicové síťové topologii pomocí síťových virtuálních zařízení třetích stran.

Stáhněte si soubor PowerPointu této architektury.

Následující diagram znázorňuje rozložení cílové zóny pro implementaci SNAT v hvězdicové síťové topologii založené na službě Virtual WAN pomocí síťových virtuálních zařízení třetích stran.

Stáhněte si soubor PowerPointu této architektury.

Pro obě rozložení síťového virtuálního zařízení třetích stran musíte nasadit několik instancí za nástrojem pro vyrovnávání zatížení Azure, aby byla zajištěna vysoká dostupnost. Vyžaduje se skladová položka Azure Load Balanceru Úrovně Standard.

Metoda 2: Služby Azure Private Link

Private Link poskytuje přístup k aplikacím nasazeným ve virtuální síti, která není připojená k vaší virtuální síti. Ve virtuální síti na straně serveru nebo v aplikaci se služba Private Link nasadí a přidružuje ke koncovému bodu aplikace, který je vystavený na front-endové IP adrese interního nástroje pro vyrovnávání zatížení skladové položky Azure standard. Ve virtuální síti na straně klienta se nasadí a přidružuje prostředek privátního koncového bodu ke službě Private Link. Privátní koncový bod zveřejňuje koncový bod aplikace ve vašich virtuálních sítích. Private Link poskytuje tunelování a logiku PŘEKLADU adres pro směrování provozu mezi stranou klienta a serverovou stranou. Další informace najdete v tématu Co je Azure Private Link?

Private Link nevyžaduje připojení vrstvy 3 mezi virtuální sítí na straně klienta a virtuální sítí na straně serveru. Dvě virtuální sítě můžou mít překrývající se adresní prostory IP adres. Private Link umožňuje nasazení aplikací ve vyhrazených izolovaných virtuálních sítích, které používají stejný nesměrovatelný adresní prostor. Aplikace jsou zpřístupněny jako služby Private Link v podnikové síti, které používají směrovatelný adresní prostor. V kontextu architektury cílové zóny Azure má výsledná topologie cílové zóny následující:

• Izolovaná virtuální síť, která je hostitelem celé aplikace a služby Private Link, která je přidružená ke koncovým bodům aplikace. Tým aplikace definuje adresní prostor virtuální sítě.
• Paprsková virtuální síť s směrovatelným adresní prostorem, který je hostitelem privátního koncového bodu přidruženého ke službě Private Link. Paprsková virtuální síť je přímo v partnerském vztahu s regionálním centrem.

Následující diagram znázorňuje topologii cílové zóny s povolenou službou Private Link.

Stáhněte si soubor PowerPointu této architektury.

Použití služby Private Link pro odchozí závislosti

Při nasazování aplikací v izolovaných paprskových virtuálních sítích použijte službu Private Link pro odchozí závislosti. Definujte privátní koncové body v izolované paprskové virtuální síti a přidružte je ke službě Private Link ve směrovatelných virtuálních sítích. Následující diagram znázorňuje koncepční přístup.

Stáhněte si soubor PowerPointu této architektury.

V reálných rozsáhlých implementacích nemusí metoda Private Link platit:

• Pokud mají aplikace nasazené v izolované virtuální síti více odchozích závislostí. Když pro každou odchozí závislost nasadíte službu Private Link a privátní koncový bod, zvýší se složitost a potřeby správy.
• Pokud odchozí závislost zahrnuje koncové body v směrovatelné síti, které nemůžou být součástí back-endového fondu Azure Load Balanceru, private Link se nedá použít.

Pokud chcete tyto dvě omezení překonat, nasaďte řešení proxy/NAT v směrovatelném paprsku a zpřístupnili ho z izolované virtuální sítě pomocí služby Private Link.

Stáhněte si soubor PowerPointu této architektury.

Pomocí jednoho privátního koncového bodu nebo služby Private Link můžete zveřejnit řešení proxy/NAT nasazené v směrovatelné síti. Pravidla překladu portů a překladu adres jsou definována v síťových virtuálních zařízeních. Tato pravidla umožňují použití jednoho privátního koncového bodu v izolované virtuální síti pro přístup k více závislostem v směrovatelné síti.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

• Federico Guerrini | Technický zájemce společnosti EMEA
• Khush Kaviraj | Architekt cloudového řešení
• Jack Tracey | Vedoucí architekt cloudových řešení

Další přispěvatelé:

• Jodi Martis | Technický spisovatel

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Nasazení služby Azure Firewall ve virtuální síti
• Konfigurace SNAT ve službě Azure Firewall
• Podporované IP adresy ve službě Azure Virtual Network
• Azure Private Link
• Azure Load Balancer
• Partnerský vztah virtuální sítě

Související prostředky

• Návrh architektury sítě
• Přístupy architektury pro sítě ve víceklientských řešeních
• Hvězdicová síťová topologie