Virtuální sítě a podsítě Azure

Azure virtuální sítě a podsítě jsou základní stavební bloky každé Azure sítě. Tento článek vysvětluje, jak virtuální sítě poskytují izolaci, jak podsítě organizují prostředky a jak navrhnout velikost a strukturu vaší sítě pro produkční úlohy.

Co tento článek popisuje

Tento článek se zabývá hranicemi izolace virtuální sítě, určením velikosti podsítě a rezervovanými adresami, vyhrazenými podsítěmi platformy pro služby, jako jsou Azure Firewall a Application Gateway, partnerské vztahy virtuálních sítí a běžné vzory rozložení sítě.

Kdo potřebuje tento článek

Přečtěte si tento článek, pokud:

• Nasazujete svou první úlohu do Azure a potřebujete porozumět tomu, jak fungují sítě, než vytvoříte prostředky.
• Plánujete prostředí s více úlohami a potřebujete rozhodnout, kolik virtuálních sítí a podsítí se má vytvořit.
• Migrují místní úlohy do Azure a potřebují pochopit, jak se Azure sítě liší od fyzických sítí.
• U služeb platformy Azure, jako jsou Azure Firewall, VPN Gateway nebo Azure Kubernetes Service (AKS), je potřeba správně formátovat podsítě.
• Chcete pochopit, kdy úlohy oddělit do různých virtuálních sítí a kdy je ponechat ve stejné virtuální síti.

Přesun fokusu metodou "lift and shift": Zrcadlení segmentace místní podsítě v Azure Namapujte stávající sítě VLAN a bezpečnostní zóny na podsítě, zachovejte soulad adresních prostorů s rozsahy, které váš tým již používá, a navrhněte podsítě s dostatečnou rezervou, abyste během migrace nemuseli měnit adresaci.

Modernizace fokusu: Navrhujte podsítě kolem služeb platformy a automatizace. Vhodně dimenzujte podsítě pro AKS, privátní koncové body a vyhrazené platformní služby a naplánujte využití služby Azure Virtual Network Manager k použití konzistentní konfigurace ve více virtuálních sítích.

Zaměření na více cloudů: Před vytvořením jakékoli virtuální sítě naplánujte nepřekrývající se adresní prostor napříč Azure, AWS a Google Cloud. Vyhraďte rozsahy CIDR, které se nepřekrývají se stávajícími VPC, abyste mohli propojit cloudy pomocí peeringu nebo přes VPN bez NAT.

Azure služby a funkce

Následující služby a funkce tvoří základ virtuálních sítí v Azure:

Služba nebo funkce	Co poskytuje	Kdy ji použít
Azure Virtual Network (VNet)	Izolovaná privátní síť v Azure. Tady začínají všechny Azure sítě. Prostředky ve stejné virtuální síti můžou ve výchozím nastavení komunikovat; prostředky v různých virtuálních sítích nemůžou komunikovat, pokud je explicitně nepřipojíte.	Vždy: každá úloha, která vyžaduje síťové připojení, vyžaduje virtuální síť.
Subnet	Část adresního prostoru VNet. Podsítě jsou rozsahem pro přidružení skupiny zabezpečení sítě (NSG) a tabulky směrování.	Vždy: uspořádejte komponenty úloh do podsítí podle funkce nebo hranice zabezpečení.
Propojení virtuálních sítí	Nízká latence, privátní připojení mezi dvěma virtuálními sítěmi ve stejné oblasti nebo napříč oblastmi. Provoz zůstává na páteřní síti Microsoft. Peering není tranzitivní; každý peering je přímé propojení.	Když prostředky v samostatných virtuálních sítích potřebují komunikovat. Informace o partnerském vztahu mezi oblastmi najdete v tématu Připojení mezi oblastmi.
Partnerské propojení podsítí (Preview)	Propojení mezi konkrétními podsítěmi namísto mezi celými virtuálními sítěmi. Umožňuje detailní řízení toho, které podsítě se účastní peeringových propojení.	Když potřebujete podrobné řízení peeringu mezi konkrétními podsítěmi v různých sítích VNet. Viz část omezení .
Směrovací tabulka / Trasy definované uživatelem (UDRS)	Přepište výchozí systémové trasy v Azure, abyste mohli řídit, kam se provoz odesílá. Používá se na úrovni podsítě.	Když potřebujete směrovat provoz přes firewall nebo síťové virtuální zařízení (NVA). Vyžaduje se pro řízení odchozí komunikace v topologii hub-and-spoke. Podívejte se na návrh Azure Firewallu a topologii typu paprsek–rozbočovač.
Azure Virtual Network Manager (AVNM)	Centrálně vytvářejte, spravujte a používejte síťové konfigurace pro sítě VNet napříč předplatnými.	Při správě mnoha virtuálních sítí napříč několika předplatnými. Viz Centralizovaná správa sítě.

Jak zvolit

Co je virtuální síť?

Virtuální síť je softwarově definovaná izolovaná síť v Azure. Představte si ji jako vaši privátní síť v Azure. Na rozdíl od fyzické sítě, která používá kabely, přepínače a směrovače, je virtuální síť zcela softwarově definovaná. Vytvoříte ho, přiřadíte ho adresní prostor a nasadíte do něj prostředky.

Klíčové charakteristiky:

• Omezeno na oblast: Virtuální síť existuje v jedné oblasti Azure. Všechny prostředky v této virtuální síti musí být ve stejné oblasti. Virtuální síť zahrnuje zóny dostupnosti v rámci této oblasti.
• Izolace ve výchozím nastavení: Prostředky v jedné virtuální síti nemůžou komunikovat s prostředky v jiné virtuální síti, pokud explicitně nevytváříte připojení (partnerský vztah nebo SÍŤ VPN).
• Výchozí interní připojení: Prostředky ve stejné virtuální síti můžou ve výchozím nastavení komunikovat prostřednictvím systémových tras, které Azure poskytují.

Co je podsíť?

Podsíť je rozsah IP adres ve vaší virtuální síti. Podsítě umožňují:

• Segmentujte síť podle komponent úloh (například webová vrstva, aplikační vrstva, datová vrstva).
• Použití pravidel zabezpečení: NSG se připojují na úrovni podsítě a filtrují provoz.
• Směrování řízení: Směrovací tabulky se připojují na úrovni podsítě pro směrování provozu.

Azure si v každé podsíti vyhrazuje pět IP adres: první čtyři adresy a poslední adresu. Například v podsíti /24 (256 adres) je možné použít pouze 251. Tuto rezervu zohledněte při výpočtech velikosti.

Příklad: Třívrstvé aplikace

Typická třívrstvé webová aplikace používá tři podsítě k oddělení obav a použití odlišných pravidel zabezpečení:

Subnet	Rozsah CIDR	Purpose	Ukázkové zdroje
web-subnet	10.0.1.0/24	Front-endové webové servery, které přijímají příchozí provoz HTTP/HTTPS z internetu nebo služby Application Gateway	Azure App Service Environment, Virtual Machine Scale Sets se systémem NGINX
app-subnet	10.0.2.0/24	Aplikační logika střední vrstvy Přijímá provoz pouze z webové podsítě.	Azure Functions (integrovaná virtuální síť), virtuální počítače s obchodní logikou
data-subnet	10.0.3.0/24	Úložiště dat. Přijímá provoz pouze z podsítě aplikace. Žádný přímý přístup k internetu.	Azure SQL Managed Instance, privátní koncové body pro Azure SQL Database nebo Cosmos DB

Toto uspořádání umožňuje přiřadit ke každé podsíti skupinu zabezpečení sítě (NSG), která omezuje provoz pouze na to, co daná vrstva potřebuje. Webová podsíť umožňuje příchozí HTTPS (port 443). Podsíť aplikace umožňuje příchozí provoz jenom z rozsahu IP adres webové podsítě. Podsíť dat umožňuje příchozí provoz pouze z rozsahu IP adres podsítě aplikace.

Pro modernizační vzor založený na AKS můžete při nasazení Azure CNI Overlay použít pro fondy uzlů clusteru podsíť aks-nodes, například 10.0.4.0/24. V tomto modelu spotřebovávají IP adresy virtuální sítě z podsítě pouze uzly. Pody používají samostatný překryvný rozsah CIDR, což umožňuje zachovat menší podsíť uzlu než u plochého návrhu sítě AKS.

Obvyklé scénáře

Následující rozložení podsítě pokrývají nejběžnější scénáře nasazení Azure:

Vzor	Podsítí	Kdy ho použít
Jednoduchá webová aplikace	web + data	Dvouvrstvé aplikace s front-endem a databází. Minimální složitost.
Tříúrovňový podnik	web + app + data + management	Tradiční podnikové pracovní zátěže s oddělenými vrstvami a propojovacím serverem nebo podsítí Bastion pro správu.
AKS se sdílenými službami	aks-nodes + aks-ingress + appgw + shared	Úlohy Kubernetes s vyhrazenou podsítí kontroleru příchozího přenosu dat a službou Application Gateway pro WAF
Odchozí komunikace v architektuře paprsků a uzlu	AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management	Hub VNet v topologii hub-and-spoke. Sdílené služby, přes které se směruje provoz z paprskových virtuálních sítí. Viz topologie typu uzel a paprsky.
Datové úlohy	compute + data + private-endpoints + management	Úlohy analýzy a datové platformy, kde privátní koncové body pro úložiště a databáze potřebují vlastní podsíť pro přehlednost plánování IP adres.

Kolik virtuálních sítí a podsítí?

Hlavní princip je jednoduchý: použijte jednu virtuální síť na aplikaci a jednu podsíť na komponentu (vrstvu). Tato výchozí hodnota udržuje každou úlohu izolovanou, usnadňuje řízení provozu mezi vrstvami pomocí skupin zabezpečení sítě a ponechá prostor pro růst. Dále ji upravte podle sdílených služeb, požadavků na izolaci a požadovaného rozsahu.

Pomocí této rozhodovací tabulky můžete určit strategii virtuální sítě a podsítě:

Vaše situace	Doporučený přístup
Jedna úloha, jeden tým, žádné sdílené služby nejsou potřeba.	Jedna virtuální síť s podsítěmi na komponentu aplikace (webová, aplikační logika, data). Viz topologie s jednou úlohou.
Několik nezávislých úloh, které sdílejí bránu nebo firewall	Centrální VNet pro sdílené služby + jedna podřízená VNet pro každou úlohu. Viz topologie typu uzel a paprsky.
Striktní izolace mezi úlohami (poloměr výbuchu, požadavky na dodržování předpisů)	Jedna VNet pro každou úlohu bez peeringu mezi nimi.
Velmi rozsáhlé prostředí s mnoha předplatnými a oblastmi	Azure Virtual WAN s automatizovanou správou centra. Viz Virtual WAN topologie.

Referenční informace o velikosti vyhrazené podsítě

Řada služeb platformy Azure vyžaduje vlastní vyhrazenou podsíť s konkrétním názvem a minimální velikostí. Následující diagram znázorňuje požadavky na pojmenování a minimální velikosti pro vyhrazené podsítě platformy:

Tuto tabulku použijte při plánování adresního prostoru:

Služba Azure	Minimální velikost podsítě	Požadovaný název podsítě	Notes
Azure Firewall	/26 (59 použitelných IP adres)	AzureFirewallSubnet	Vyžaduje se pro všechny SKU brány firewall. Viz návrh Azure Firewall.
Brána VPN	/27 (27 použitelných IP adres)	GatewaySubnet	Microsoft doporučuje /27 nebo větší kvůli rezervě pro škálování.
Azure Bastion	/26 (59 použitelných IP adres)	AzureBastionSubnet	Minimálně /26 pro všechna nasazení vytvořená po listopadu 2021.
Application Gateway v2	/24 doporučeno (251 použitelných IP adres)	Bez požadovaného názvu	Vřele doporučujeme /24 pro podporu automatického škálování. Minimum se vypočítává podle vzorce (instance + 5 rezervovaných + 1 privátní IP adresa front-endu).
App Service Environment	/24 (produkční), /23 (maximální škálování)	Bez požadovaného názvu	Škálování využívá IP adresy z podsítě. Pokud plánujete škálovat na maximum 200 instancí, použijte /23.
Azure Route Server	/26 (59 použitelných IP adres)	RouteServerSubnet	Vyžaduje se pro výměnu tras protokolu BGP se síťovými virtuálními zařízeními.
Azure DNS Private Resolver	/28 minimálně na podsíť koncového bodu	Vyhrazené příchozí a odchozí podsítě	Vyžaduje samostatné podsítě pro příchozí a odchozí koncové body. Nejde sdílet s jinými zdroji.
AKS (Azure Kubernetes Service)	Založené na vzorcích (závislé na CNI)	Bez požadovaného názvu	Prohlédni si pokyny k určení velikosti AKS.

Note

Privátní koncové body využívají IP adresy z existujících podsítí. Nevyžadují vyhrazenou podsíť. Zohledněte tuto spotřebu IP adres při určování velikosti podsítě. Podrobné plánování IP adres najdete v tématu Plánování IP adres.

Určení velikosti podsítě AKS

Nastavení velikosti podsítě AKS závisí na vaší volbě modulu plug-in Container Networking Interface (CNI). Neexistuje žádná minimální velikost:

• Azure CNI Overlay: Podsíť musí pojmout pouze uzly, protože pody používají samostatný privátní blok CIDR (Classless Inter-Domain Routing). Ve srovnání s plochou sítí je přijatelná výrazně menší podsíť.
• Azure CNI (plochá síť): Podsíť musí pojmout jak uzly, tak pody. Vzorec: (nodes + surge) × (max_pods + 1). Pro clustery s 50 nebo více uzly je společný /21 nebo větší.
• Kubenet: IP adresy z podsítě VNet spotřebovávají pouze uzly. Pody získají interní IP adresy clusteru.

Vzorce pro určení velikosti pro jednotlivé možnosti CNI najdete v tématu Plánování přidělování IP adres pro cluster AKS.

Omezení partnerského propojení podsítí

Partnerské propojení podsítí propojuje konkrétní podsítě mezi virtuálními sítěmi namísto celých adresních prostorů. Tento přístup poskytuje detailní kontrolu nad tím, které podsítě se zapojí do peeringových propojení.

Important

Partnerské propojení podsítí je v současnosti ve verzi Preview a má následující omezení:

• Vyžaduje přidání předplatného do schváleného seznamu (ne samoobslužné registrace).
• Pouze CLI, šablona ARM, Terraform nebo PowerShell (bez podpory portálu)
• Pro produkční použití jsou vyžadována SKU V5 založená na Intelu (nebo SKU založená na AMD Genoa/Cobalt 100), aby se předešlo známé chybě u SKU starší generace: aktuální hardwarové požadavky naleznete v části Konfigurace partnerského propojení podsítí.
• Maximálně 200 podsítí na každé straně peeringového propojení
• Maximálně 1 000 podsítí celkem ve všech peeringových propojeních na jednu virtuální síť
• Podsítě musí patřit do jedinečných, nepřekrývajících se adresních prostorů.

Aktuální omezení a informace o registraci najdete v článku Konfigurace partnerského vztahu podsítí.

Note

Azure Virtual Network Manager (AVNM) nedokáže odlišit partnerský vztah podsítě od partnerského vztahu virtuálních sítí. Pokud ke správě konfigurací partnerského vztahu používáte AVNM, mějte na paměti, že vztahy peeringu na úrovni podsítě se v AVNM zobrazují jako standardní partnerský vztah virtuálních sítí.

Aspekty návrhu

Zaměření návrhu virtuální sítě a podsítě metodou "lift-and-shift"

• Znovu vytvořte svou lokální segmentaci: namapujte každou síť VLAN nebo bezpečnostní zónu na podsíť, aby se stávající hranice firewallu a provozní odpovědnost zachovaly i při minimálních úpravách návrhu.
• Velikost podsítí s hlavní místností Přeadresování po migraci narušuje provoz, proto přidělte větší rozsahy CIDR, než vyžaduje váš aktuální počet hostitelů, aby pokryly budoucí růst a pět adres, které Azure rezervuje pro každou podsíť.
• Udržujte adresní prostory Azure v souladu s rozsahy v místním prostředí, pokud je to možné, aby se zjednodušilo směrování a zabránilo překrývání při připojení prostřednictvím VPN Gateway nebo ExpressRoute.
• Ve výchozím nastavení použijte jednu síť VNet pro každou migrovanou aplikaci a jednu podsíť pro každou vrstvu. Tento návrh zrcadlí typická třívrstvá místní rozložení a zajišťuje předvídatelný přesun.

Zaměření na modernizaci návrhu sítě VNet a podsítí

• Nejprve navrhněte podsítě kolem služeb platformy: vyhrazené podsítě pro Azure Firewall, Application Gateway a Bastion a také správné velikosti podsítí pro AKS na základě vaší volby CNI.
• Použijte Azure CNI Overlay pro AKS, aby podsítě uzlů zůstaly malé, protože pody se přidělují ze samostatného překryvného rozsahu CIDR, nikoli z adresního prostoru virtuální sítě (VNet).
• Vyhraďte si vyhrazenou podsíť pro privátní koncové body, aby spotřeba IP adres zůstala předvídatelná, když přijímáte více Azure služeb PaaS.
• Pokud chcete konzistentně používat skupiny sítě, možnosti připojení a konfigurace zabezpečení konzistentně při růstu počtu virtuálních sítí napříč předplatnými, využijte Azure Virtual Network Manager brzy.

Zaměření na návrh VNet a podsítí ve více cloudových prostředích

• Před vytvořením jakékoli virtuální sítě vytvořte globální plán adres. Zarezervujte pro Azure nepřekrývající se bloky CIDR, které se nepřekrývají se stávajícími sítěmi AWS VPC ani Google Cloud VPC. Tato rezervace je povinná pro směrovanou síť VPN nebo propojení.
• Namapujte síťové prvky jednotlivých cloudů na prostředky Azure: síť AWS VPC nebo síť Google Cloud VPC odpovídá virtuální síti Azure (VNet) a skupiny zabezpečení odpovídají skupinám zabezpečení sítě (NSG).
• Vyhraďte adresní prostor podsítě pro komponenty propojení mezi cloudy, například GatewaySubnet pro VPN Gateway nebo rozbočovač používaný službou Azure Virtual WAN, aby měla tranzitní infrastruktura prostor pro škálování.
• Standardizujte pojmenování a označování podsítě napříč cloudy, aby provozní týmy mohly korelovat ekvivalentní úrovně při řešení potíží s vícecloudovým provozem.

Předpoklady

Před návrhem rozložení virtuální sítě a podsítě se ujistěte, že máte:

• Azure předplatné: Aktivní Azure předplatné s oprávněními k vytváření síťových prostředků (role Přispěvatel sítě nebo vyšší).
• Skupina prostředků: Skupina prostředků ve vaší cílové oblasti, která bude obsahovat prostředky virtuální sítě.
• Rozhodnutí o oblasti: Zvolte primární Azure oblast na základě blízkosti uživatelů, požadavků na dodržování předpisů a dostupnosti služeb.
• Plán adresního prostoru: Zvolte rozsah adres IP (blok CIDR), který se nepřekrývá se sítěmi v místním prostředí ani s jinými virtuálními sítěmi, které chcete propojit partnerským vztahem. Pokyny najdete v tématu Plánování IP adres .

Bezpečnostní aspekty

Virtuální sítě a podsítě jsou vaší první vrstvou segmentace sítě. Použijte následující postupy zabezpečení:

• Skupiny zabezpečení sítě (NSG): Přidružení skupin zabezpečení sítě ke každé podsíti k filtrování příchozího a odchozího provozu. Definujte pravidla specifická pro každou roli podsítě a ve výchozím nastavení odepřete všechno ostatní. Podrobné pokyny najdete v tématu Skupiny zabezpečení sítě a skupiny zabezpečení aplikací.
• Vynucené tunelování pomocí UDR: Pokud vaše požadavky na shodu s předpisy vyžadují, aby veškerý provoz směřující do internetu procházel přes místní inspekční zařízení nebo cloudový firewall, použijte směrovací tabulky s trasami definovanými uživatelem k přepsání výchozího směrování do internetu. Viz Odchozí připojení a egresová připojení.
• Izolace podsítě: Umístěte prostředky s různými úrovněmi důvěryhodnosti do samostatných podsítí. Dbejte například na databáze v podsíti, která povoluje pouze příchozí provoz z podsítě aplikační vrstvy. Toto oddělení omezuje laterální pohyb, pokud útočník ohrožuje jednu komponentu.
• Vyhrazené podsítě pro služby platformy: Mnoho služeb platformy Azure (Azure Firewall, Application Gateway, Bastion) se nasazuje do vyhrazených podsítí. Tato izolace zajišťuje, že směrování služeb platformy a pravidla zabezpečení nenaruší vaše podsítě úloh.

Interakce mezi NSG a podsítí

Když přidružíte skupinu zabezpečení sítě k podsíti, pravidla NSG se vztahují na všechny prostředky v této podsíti. Pochopte následující způsoby interakce:

• Kumulativní vyhodnocení: Pokud má síťová karta virtuálního počítače také skupinu zabezpečení sítě, Azure vyhodnotí skupinu zabezpečení sítě na úrovni podsítě i skupinu zabezpečení sítě na úrovni síťové karty. Pro příchozí provoz Azure nejprve vyhodnotí NSG podsítě a potom NSG síťové karty NIC. Pro odchozí provoz Azure nejprve vyhodnotí NSG síťového rozhraní a potom NSG podsítě.
• Ve výchozím nastavení zakázáno: Azure zahrnuje výchozí pravidla, která povolují provoz v rámci virtuální sítě (VNet) a odchozí přístup k internetu. Po přidání vlastních pravidel blokování ověřte, že legitimní provoz (například sondy stavu služby Azure Load Balancer z IP adresy 168.63.129.16) není neúmyslně blokován.
• Značky služeb a skupiny ASG: V pravidlech NSG používejte místo holých IP adres značky služeb (například AzureLoadBalancer, Internet, VirtualNetwork) a skupiny zabezpečení aplikací (ASG). Tento přístup zjednodušuje správu pravidel a automaticky se přizpůsobuje, protože se mění rozsahy IP adres Azure.
• Protokoly toků pro zajištění viditelnosti: Povolte protokoly toků NSG u každé skupiny zabezpečení sítě na úrovni podsítě, abyste zachytili povolený i odepřený provoz. Protokoly toku pomáhají ověřit, že pravidla zabezpečení fungují podle očekávání, a poskytují důkazy pro audity dodržování předpisů. Pokyny k nastavení najdete v protokolech toku NSG .

Související články

Tyto články v průvodci návrhem sítí Azure se týkají souvisejících témat:

• Plánování IP adres: Navrhněte adresní prostor, vyhněte se překrývání a plánování růstu.
• Skupiny zabezpečení sítě a skupiny zabezpečení aplikací: Definujte pravidla filtrování provozu na úrovni podsítě a síťové karty.
• Topologie s jednou úlohou: Návrh jednoduché sítě pro jednu úlohu bez sdílených služeb
• Topologie paprsek–rozbočovač: Připojte více VNetů úloh prostřednictvím centra sdílených služeb.
• Topologie virtuální sítě WAN: Spravujte připojení ve velkém rozsahu pomocí automatizovaného směrování přes rozbočovač.
• Propojení mezi oblastmi: Propojte virtuální sítě napříč oblastmi Azure pomocí globálního partnerského propojení nebo služby Virtual WAN.
• Centralizovaná správa sítě: Správa konfigurací virtuálních sítí napříč předplatnými pomocí Azure Virtual Network Manager

Další informace

Další informace o Azure virtuálních sítích najdete v následujících zdrojích informací:

• Co je Azure Virtual Network?
• Nejčastější dotazy ke službě Azure Virtual Network
• Plánování podsítě virtuální sítě
• Propojení virtuálních sítí
• Konfigurovat partnerské propojení podsítí (verze Preview)
• Plánování přidělování IP adres pro clustery AKS

Další kroky

Tip

Prozkoumáváte to sami? Vraťte se do navigátoru přehledu a vyhledejte další článek podle možností.

V dalším kroku na cestě metodou "lift and shift":

Naplánujte adresní prostor IP adres: Vyhraďte fond CIDR /16, který se nepřekrývá s rozsahy adres ve vašem místním prostředí.

Další na cestě k modernizaci:

Naplánujte adresní prostor IP adres: Přidělte dvouregionální fondy IP adres s nepřekrývajícími se rozsahy pro peering v režimu aktivní-aktivní.

Dále na vaší cestě mezi cloudy:

Naplánujte si adresní prostor IP adres: Navrhněte nepřekrývající se adresování napříč Azure, Amazon Web Services (AWS) a Google Cloudem.