Azure virtuella nätverk och undernät

Azure virtuella nätverk (VNet) och undernät är de grundläggande byggstenarna i varje Azure nätverk. Den här artikeln beskriver hur virtuella nätverk tillhandahåller isolering, hur undernät organiserar resurser och hur du storleksanpassar och strukturerar nätverket för produktionsarbetsbelastningar.

Vad den här artikeln beskriver

Den här artikeln beskriver gränser för VNet-isolering, storleksändring av undernät och reserverade adresser, dedikerade plattformsundernät för tjänster som Azure Firewall och Application Gateway, VNet-peering och vanliga mönster för nätverkslayout.

Vem behöver den här artikeln

Läs den här artikeln om du:

  • Distribuerar din första arbetsbelastning till Azure och behöver förstå hur nätverk fungerar innan du skapar resurser.
  • Planerar en miljö med flera arbetsbelastningar och måste bestämma hur många virtuella nätverk och undernät som ska skapas.
  • Migrerar lokala arbetsbelastningar till Azure och behöver förstå hur Azure nätverk skiljer sig från fysiska nätverk.
  • Du måste storleksanpassa undernät korrekt för Azure plattformstjänster som Azure Firewall, VPN Gateway eller Azure Kubernetes Service (AKS).
  • Vill du veta när du ska separera arbetsbelastningar i olika virtuella nätverk jämfört med att behålla dem i samma virtuella nätverk.

Fokus för lift-and-shift: Spegla segmenteringen av ditt lokala undernät i Azure. Mappa befintliga VLAN och säkerhetszoner till undernät, håll adressutrymmen i linje med intervall som ditt team redan använder och storleksanpassa undernät generöst så att du inte behöver åtgärda dem igen under migreringen.

Modernisera fokus: Utforma undernät kring plattformstjänster och automatisering. Anpassa storleken på undernät för AKS, privata ändpunkter och dedikerade plattformstjänster, och planera för att Azure Virtual Network Manager ska kunna tillämpa enhetlig konfiguration i många virtuella nätverk (VNet).

Fokus mellan moln: Planera icke-överlappande adressutrymme i Azure, AWS och Google Cloud innan du skapar ett virtuellt nätverk. Reservera CIDR-intervall som inte kolliderar med befintliga VPC:er så att du kan ansluta moln via peering eller VPN utan NAT.

Azure tjänster och funktioner

Följande tjänster och funktioner utgör grunden för virtuella nätverk i Azure:

Tjänst eller funktion Vad det ger När du ska använda detta
Azure Virtual Network (VNet) Ett isolerat, privat nätverk i Azure. Alla Azure nätverk börjar här. Resurser i samma virtuella nätverk kan kommunicera som standard. resurser i olika virtuella nätverk kan inte kommunicera om du inte uttryckligen ansluter dem. Alltid: varje arbetsbelastning som behöver nätverksanslutning kräver ett virtuellt nätverk.
Subnet En partition av VNet-adressutrymmet. Undernät är den nivå där nätverkssäkerhetsgrupper (NSG) och routningstabeller associeras. Alltid: Organisera arbetsbelastningskomponenter i undernät efter funktion eller säkerhetsgräns.
VNet-peering Låg latens, privat anslutning mellan två virtuella nätverk i samma region eller mellan regioner. Trafiken ligger kvar på Microsoft stamnät. Peering är inte transitivt. varje peering är en direktlänk. När resurser i separata virtuella nätverk behöver kommunicera. Mer information om peering mellan regioner finns i Anslutningar mellan regioner.
Undernätspeering (förhandsversion) Peering mellan specifika undernät i stället för hela virtuella nätverk. Ger detaljerad kontroll över vilka undernät som deltar i peering-relationer. När du behöver detaljerad peering-kontroll mellan specifika undernät i olika virtuella nätverk. Se avsnittet begränsningar .
Routningstabell/Användardefinierade vägar (UDR) Åsidosätt standardsystemvägar i Azure för att styra var trafiken skickas. Tillämpas på undernätsnivå. När du behöver tvinga trafik genom en brandvägg eller en virtuell nätverksenhet (NVA). Krävs för hub-and-spoke-styrning av utgående trafik. Se design för Azure Firewall och nav-och-ekrar-topologi.
Azure Virtual Network Manager (AVNM) Skapa, hantera och tillämpa nätverkskonfigurationer centralt för VNets över prenumerationer. När du hanterar många virtuella nätverk i flera prenumerationer. Se Centraliserad nätverkshantering.

Diagram som visar VNet med arbetsbelastningsundernät för webb-, app- och datanivåer tillsammans med dedikerade plattformsundernät för gateway, brandvägg och Bastion

Så här väljer du

Vad är ett virtuellt nätverk?

Ett virtuellt nätverk (VNet) är ett programvarudefinierat, isolerat nätverk i Azure. Se det som ditt privata nätverk i Azure. Till skillnad från ett fysiskt nätverk som använder kablar, växlar och routrar är ett virtuellt nätverk helt programvarudefinierat. Du skapar det, tilldelar det ett adressutrymme och distribuerar resurser till det.

Viktiga egenskaper:

  • Regionsspecifikt: Ett virtuellt nätverk finns i en enda Azure-region. Alla resurser i det virtuella nätverket måste finnas i samma region. Ett virtuellt nätverk omfattar tillgänglighetszoner inom den regionen.
  • Isolering som standard: Resurser i ett virtuellt nätverk kan inte kommunicera med resurser i ett annat virtuellt nätverk om du inte uttryckligen skapar en anslutning (peering eller VPN).
  • Intern standardanslutning: Resurser i samma virtuella nätverk kan som standard kommunicera med varandra via systemvägar som Azure tillhandahåller.

Vad är ett undernät?

Ett undernät är ett intervall med IP-adresser i ditt virtuella nätverk. Med undernät kan du:

  • Segmentera nätverket efter arbetsbelastningskomponent (till exempel webbnivå, programnivå, datanivå).
  • Tillämpa säkerhetsregler: NSG:er ansluter på undernätsnivå för att filtrera trafik.
  • Kontrollroutning: routningstabeller bifogas på undernätsnivå för att dirigera trafik.

Azure reserverar fem IP-adresser i varje undernät: de fyra första adresserna och den sista adressen. I ett /24-undernät (256 adresser) kan till exempel endast 251 användas. Räkna in den här reservationen i storleksberäkningarna.

Exempel: Program med tre nivåer

Ett typiskt webbprogram med tre nivåer använder tre undernät för att avgränsa problem och tillämpa distinkta säkerhetsregler:

Subnet CIDR-intervall Purpose Exempelresurser
web-subnet 10.0.1.0/24 Klientwebbservrar som accepterar inkommande HTTP/HTTPS-trafik från Internet eller Application Gateway Azure App Service Environment, Virtual Machine Scale Sets som kör NGINX
app-subnet 10.0.2.0/24 Programlogik på mellannivå. Accepterar endast trafik från webbundernätet. Azure Functions (VNet-integrerad), virtuella datorer som kör affärslogik
data-subnet 10.0.3.0/24 Datalager. Accepterar endast trafik från appens undernät. Ingen direkt internetåtkomst. Azure SQL Managed Instance, privata slutpunkter för Azure SQL Database eller Cosmos DB

Med den här layouten kan du använda en NSG för varje undernät som endast begränsar trafiken till vad den nivån behöver. Webbundernätet tillåter inkommande HTTPS (port 443). Appens undernät tillåter endast inkommande trafik från webbundernätets IP-intervall. Dataundernätet tillåter endast inkommande trafik från appens undernäts IP-intervall.

För ett AKS-baserat moderniseringsmönster kan du använda ett aks-nodes undernät, till exempel 10.0.4.0/24 för klusternodpoolerna när du distribuerar Azure CNI-överlägg. I den modellen använder endast noderna VNet IP-adresser från undernätet. Poddar använder ett separat överläggs-CIDR, vilket gör att du kan hålla nodundernätet mindre än en platt AKS-design.

Vanliga mönster

Följande undernätslayouter omfattar de vanligaste distributionsscenarierna för Azure:

Mönster Subnets När det bör användas
Enkel webbapp web + data Program med två nivåer med en klientdel och databas. Minimal komplexitet.
Företag med tre nivåer web + app + data + management Traditionella företagsarbetslaster med separata nivåer och en jump box eller ett Bastion-undernät för administrativ åtkomst.
AKS med delade tjänster aks-nodes + aks-ingress + appgw + shared Kubernetes-arbetsbelastningar med ett dedikerat undernät för en ingresskontrollant och Application Gateway för WAF.
Utgående hub-and-spoke-trafik AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management Det virtuella hubbnätverket i en topologi med nav och eker. Delade tjänster som ekrar virtuella nätverk dirigerar trafik genom. Mer information finns i Topologin Hub-and-spoke.
Dataarbetsbelastning compute + data + private-endpoints + management Arbetslaster för analys- och dataplattformar där privata slutpunkter för lagring och databaser behöver ett eget undernät för tydligare IP-planering.

Hur många virtuella nätverk och undernät?

Den vägledande principen är enkel: använd ett virtuellt nätverk per program och ett undernät per komponent (nivå). Den här standardinställningen håller varje arbetsbelastning isolerad, gör trafiken mellan nivåerna enkel att styra med nätverkssäkerhetsgrupper och lämnar utrymme att växa. Justera därifrån baserat på delade tjänster, isoleringskrav och skalning.

Använd den här beslutstabellen för att fastställa din strategi för virtuella nätverk och undernät:

Din situation Rekommenderat tillvägagångssätt
Enskild arbetsbelastning, enskilt team, inga delade tjänster behövs Ett virtuellt nätverk med undernät per programkomponent (webb, programlogik, data). Se Topologi med en arbetsbelastning.
Flera oberoende arbetslaster som delar en gateway eller brandvägg hubb-VNet för delade tjänster + ett spoke-VNet per arbetslast. Mer information finns i Topologin Hub-and-spoke.
Strikt isolering mellan arbetsbelastningar (sprängradie, efterlevnadskrav) Ett virtuellt nätverk per arbetsbelastning utan peering mellan dem.
Mycket stor miljö med många prenumerationer och regioner Azure Virtual WAN med automatiserad hubbhantering. Se topologin för Virtual WAN.

Referens för dedikerad storlek på undernät

Många Azure plattformstjänster kräver ett eget dedikerat undernät med ett specifikt namn och en minsta storlek. Följande diagram visar namngivningskraven och minimistorlekarna för dedikerade plattformsundernät:

Diagram som visar minsta undernätsstorlekar för fem dedikerade plattformsundernät, inklusive gateway, brandvägg, Bastion och Route Server

Använd den här tabellen när du planerar adressutrymmet:

Azure-tjänst Minsta storlek på undernät Nödvändigt undernätsnamn Noteringar
Azure Firewall /26 (59 användbara IP-adresser) AzureFirewallSubnet Krävs för alla brandväggs-SKU:er. Se Azure Firewall design.
VPN-gateway /27 (27 användbara IP-adresser) GatewaySubnet Microsoft rekommenderar /27 eller större för skalning av utrymme.
Azure Bastion /26 (59 användbara IP-adresser) AzureBastionSubnet Minst /26 för alla distributioner som skapats efter november 2021.
Application Gateway v2 /24 rekommenderas (251 användbara IP-adresser) Inget obligatoriskt namn Vi rekommenderar starkt /24 för att stödja automatisk skalning. Miniminivån beräknas enligt en formel (instanser + 5 reserverade + 1 privat IP-adress för klientdelen).
Tjänstemiljö för appar /24 (produktion), /23 (maximal skala) Inget obligatoriskt namn Skalning förbrukar IP-adresser från undernätet. Använd /23 om du planerar att skala nära maxgränsen på 200 instanser.
Azure Route Server /26 (59 användbara IP-adresser) RouteServerSubnet Krävs för BGP-vägutbyte med NVA:er.
Privat lösning för Azure DNS /28 minimum per slutpunktsundernät Dedikerade inkommande och utgående undernät Kräver separata undernät för inkommande och utgående slutpunkter. Det går inte att dela med andra resurser.
AKS (Azure Kubernetes Service) Formelbaserad (CNI-beroende) Inget obligatoriskt namn Se vägledningen för dimensionering av AKS.

Note

Privata slutpunkter använder IP-adresser från befintliga undernät. De kräver inte ett dedikerat undernät. Räkna in den här IP-förbrukningen i storleksändringen för undernätet. Detaljerad IP-planering finns i IP-adressplanering.

AKS-undernätsstorlek

AKS-undernätsstorlek beror på ditt CNI-plugin-val (Container Networking Interface). Det finns ingen enskild minsta storlek:

  • Azure CNI Overlay: Undernätet behöver bara rymma noder eftersom poddar använder ett separat privat CIDR-block (klasslös dirigering mellan domäner). Ett betydligt mindre undernät är acceptabelt jämfört med platta nätverk.
  • Azure CNI (platt nätverk): Undernätet måste rymma båda noderna OCH poddarna. Formel: (nodes + surge) × (max_pods + 1). En /21 eller större är vanlig för kluster med 50 eller fler noder.
  • Kubenet: Endast noder använder IP-adresser för VNet-undernät. Poddar hämtar klusterinterna IP-adresser.

För formler för storleksberäkning för varje CNI-alternativ, se Planera IP-adressering för ditt AKS-kluster.

Begränsningar för peering för undernät

Undernätspeering ansluter specifika undernät mellan VNet i stället för hela adressutrymmen. Den här metoden ger detaljerad kontroll över vilka undernät som deltar i peering-relationer.

Important

Peering för undernät är för närvarande i förhandsversion och har följande begränsningar:

  • Kräver att prenumerationen läggs till i en lista över godkända (inte anmälan via självbetjäning)
  • ENDAST CLI, ARM-mall, Terraform eller PowerShell (inget portalstöd)
  • Intel-baserade V5-SKU:er (eller AMD Genoa/Cobalt 100-baserade SKU:er) krävs för produktionsanvändning för att undvika en känd bugg på äldre generationens SKU:er: se Konfigurera undernätspeering för aktuella maskinvarukrav
  • Högst 200 undernät per sida per peering-länk
  • Maximalt 1 000 totala undernät för alla peeringlänkar per VNet
  • Undernät måste tillhöra unika, icke-överlappande adressutrymmen

Aktuella begränsningar och registrering finns i Konfigurera peering för undernät.

Note

Azure Virtual Network Manager (AVNM) kan inte skilja undernätspeering från VNet-peering. Om du använder AVNM för att hantera peeringkonfigurationer bör du vara medveten om att peeringrelationer på undernätsnivå visas som standard VNet-peering i AVNM.

Designöverväganden

Designfokus för lift-and-shift-VNet och undernät

  • Återskapa din lokala segmentering: mappa varje VLAN eller säkerhetszon till ett undernät så att befintliga brandväggsgränser och driftägarskap överförs med minimal omdesign.
  • Storlek på undernät med utrymme. Omadressering efter en migrering orsakar störningar, så tilldela större CIDR-intervall än vad det nuvarande antalet värdar kräver för att hantera tillväxt och Azures fem reserverade adresser per undernät.
  • Håll Azure adressutrymmen i linje med lokala intervall där det är möjligt för att förenkla routningen och undvika överlappning när du ansluter via VPN Gateway eller ExpressRoute.
  • Standardvärdet är ett virtuellt nätverk per migrerat program med ett undernät per nivå. Den här designen speglar typiska lokala layouter på tre nivåer och håller flytten förutsägbar.

Modernisera designfokus för VNet och undernät

  • Utforma undernät kring plattformstjänster först: dedikerade undernät för Azure Firewall, Application Gateway och Bastion, plus korrekt storlek på undernät för AKS baserat på ditt CNI-val.
  • Använd Azure CNI Overlay för AKS för att hålla nodsubnäten små, eftersom poddar använder adresser från ett separat CIDR-intervall för överläggsnätet i stället för från VNet-adressutrymmet.
  • Reservera ett dedikerat undernät för privata slutpunkter så att IP-förbrukningen förblir förutsägbar när du använder fler Azure PaaS-tjänster.
  • Börja använda Azure Virtual Network Manager tidigt för att tillämpa nätverksgrupper samt anslutnings- och säkerhetskonfigurationer konsekvent när antalet virtuella nätverk (VNet) ökar över flera prenumerationer.

Designfokus för virtuellt nätverk och undernät mellan moln

  • Upprätta en global adressplan innan du skapar ett virtuellt nätverk. Reservera icke-överlappande CIDR-block för Azure som inte kolliderar med befintliga virtuella AWS-datorer eller Google Cloud VPC-nätverk. Den här reservationen är obligatorisk för dirigerad VPN eller sammankoppling.
  • Mappa varje moln nätverk primitiver till Azure: ett AWS VPC- eller Google Cloud VPC-nätverk motsvarar ett Azure VNet, och säkerhetsgrupper motsvarar NSG:er.
  • Reservera undernätsutrymme för anslutningskomponenter mellan moln, till exempel en GatewaySubnet för VPN Gateway eller hubben som används av Azure Virtual WAN, så överföringsinfrastrukturen har utrymme att skala.
  • Standardisera namngivning och taggning av undernät mellan moln så att driftteamen kan korrelera motsvarande nivåer när de felsöker trafik med flera moln.

Förutsättningar

Innan du utformar layouten för det virtuella nätverket och undernätet kontrollerar du att du har:

  • Azure prenumeration: En aktiv Azure prenumeration med behörighet att skapa nätverksresurser (rollen Nätverksdeltagare eller högre).
  • Resursgrupp: En resursgrupp i målregionen som ska innehålla VNet-resurser.
  • Regionbeslut: Välj din primära Azure region baserat på närhet till användare, efterlevnadskrav och tjänsttillgänglighet.
  • Adressutrymmesplan: Bestäm ett IP-adressintervall (CIDR-block) som inte överlappar dina lokala nätverk eller andra virtuella nätverk som du tänker peer-koppla. Se IP-adressplanering för vägledning.

Säkerhetsfrågor

Virtuella nätverk och undernät är ditt första lager av nätverkssegmentering. Tillämpa följande säkerhetsmetoder:

  • Nätverkssäkerhetsgrupper (NSG:er): Associera NSG:er med varje undernät för att filtrera inkommande och utgående trafik. Definiera tillåtna regler som är specifika för varje undernäts roll och neka allt annat som standard. Detaljerad vägledning finns i Nätverkssäkerhetsgrupper och programsäkerhetsgrupper.
  • Tvingad tunneltrafik med UDR:er: Om dina efterlevnadskrav kräver att all Internetbunden trafik passerar genom en lokal inspektionsenhet eller en molnbrandvägg använder du routningstabeller med användardefinierade vägar för att åsidosätta standardroutning på Internet. Se Utgående anslutning och utgående trafik.
  • Isolering av undernät: Placera resurser med olika förtroendenivåer i separata undernät. Du kan till exempel behålla databaser i ett undernät som endast tillåter inkommande trafik från undernätet på programnivå. Den här separationen begränsar lateral förflyttning om en angripare komprometterar en komponent.
  • Dedikerade undernät för plattformstjänster: Många Azure plattformstjänster (Azure Firewall, Application Gateway, Bastion) distribueras till dedikerade undernät. Den här isoleringen säkerställer att plattformstjänstens routning och säkerhetsregler inte stör dina arbetsbelastningsundernät.

NSG- och undernätsinteraktion

När du associerar en NSG med ett undernät gäller NSG-reglerna för alla resurser i det undernätet. Förstå dessa interaktionsbeteenden:

  • Kumulativ utvärdering: Om en virtuell dators nätverkskort också har en NSG utvärderar Azure både nätverkssäkerhetsgruppen på undernätsnivå och nätverkssäkerhetsgruppen på NIC-nivå. För inkommande trafik utvärderar Azure först undernätets NSG och sedan nätverkskortets NSG. För utgående trafik utvärderar Azure först NSG:n för nätverksgränssnittet och sedan NSG:n för undernätet.
  • Standard neka: Azure innehåller standardregler som tillåter intra-VNet-trafik och utgående Internetåtkomst. När du har lagt till anpassade neka-regler kontrollerar du att legitim trafik (till exempel Azure Load Balancer hälsoavsökningar från IP-adressen 168.63.129.16) inte oavsiktligt blockeras.
  • Tjänsttaggar och ASG:er: Använd tjänsttaggar (till exempel AzureLoadBalancer, Internet, VirtualNetwork) och programsäkerhetsgrupper (ASG:er) i NSG-regler i stället för råa IP-adresser. Den här metoden förenklar regelhanteringen och anpassas automatiskt när Azure IP-intervall ändras.
  • Flödesloggar för synlighet: Aktivera NSG-flödesloggar på varje NSG på undernätsnivå för att samla in godkänd och nekad trafik. Flödesloggar hjälper dig att kontrollera att säkerhetsreglerna fungerar som de ska och att tillhandahålla bevis för efterlevnadsgranskningar. Se NSG-flödesloggar för installationsinstruktioner.

De här artiklarna i designguiden för Azure nätverk beskriver relaterade ämnen:

Learn more

Mer information om Azure virtuella nätverk finns i följande resurser:

Nästa steg

Tip

Utforska på egen hand? Gå tillbaka till översiktsnavigatorn för att hitta nästa artikel efter funktion.

Nästa steg i din lift-and-shift-resa:

Planera ditt IP-adressutrymme: Allokera en /16 CIDR-pool som undviker överlappning med dina lokala adressintervall.

Nästa steg i moderniseringsresan:

Planera ditt IP-adressutrymme: Tilldela IP-pooler för två regioner med intervall som inte överlappar varandra för aktiv-aktiv-peering.

Nästa steg i din molnöverskridande resa:

Planera ditt IP-adressutrymme: Utforma icke-överlappande adresser över Azure, Amazon Web Services (AWS) och Google Cloud.

  • Last updated on