IP-adresplanning voor Azure virtuele netwerken

In dit artikel vindt u informatie over het plannen van privé- en openbare IP-adressen voor Azure implementaties. U leert hoe u adresruimte toewijst, overlappende bereiken vermijdt, het juiste openbare IP-type kiest en IPv6 dual-stack-ondersteuning evalueert.

Wat in dit artikel wordt behandeld

Dit artikel bevat informatie over strategieën voor privéadrestoewijzing, openbare IP-typen en SKU's, CIDR-planning om overlappende bereiken, overwegingen voor dubbele IPv6-stacks en IP-adresbeheer (IPAM) voor grootschalige omgevingen te voorkomen.

Wie heeft dit artikel nodig

Lees dit artikel als u:

  • Implementeert een virtueel netwerk (VNet) in Azure en moet bepalen welke IP-adresbereiken moeten worden gebruikt.
  • Verbindt Azure netwerken met on-premises omgevingen en moet adresconflicten voorkomen.
  • U moet kiezen tussen standaard openbare IP-adressen, openbare IP-voorvoegsels of uw eigen IP-bereiken (BYOIP) meenemen.
  • Wilt u weten wanneer IPv6 dual-stack geschikt is voor uw workloads.
  • Beheert een grote of groeiende omgeving en heeft een strategie nodig om IP-toewijzingen op schaal bij te houden.

Gericht op lift-and-shift: Kies privéadresbereiken die niet overlappen met uw on-premises netwerk, zodat VPN- of ExpressRoute-routering zonder adresvertaling werkt. Reserveer één groot landing-zoneblok met ruimte voor de workloads die u in de komende jaren migreert.

Focus moderniseren: Plan niet-overlappende adresruimte in uw primaire en back-upregio's, zodat actief-actieve workloads later kunnen peeren en subnetten op de juiste grootte kunnen reserveren voor App Service Environment en AKS.

Focus op meerdere clouds: Bouw een globaal adresplan dat niet in conflict komt met bestaande AWS VPC- of Google Cloud CIDR-bereiken. Dit is verplicht voordat u clouds verbindt via VPN of interconnect.

Azure services en functies

De volgende services en functies ondersteunen het plannen van IP-adressen in Azure:

Dienst of functie Wat het biedt Wanneer gebruikt u het?
RFC 1918 privéadresruimten Drie gereserveerde adresbereiken voor privégebruik: 10.0.0.0/8, 172.16.0.0/12, en 192.168.0.0/16. Azure VNets gebruiken deze adresbereiken voor interne communicatie. Altijd: voor elk VNet is ten minste één privéadresbereik van deze ruimten vereist.
RFC 6598 gedeelde adresruimte 100.64.0.0/10: behandeld als privéadresruimte in Azure. Oorspronkelijk ontworpen voor CGNAT-omgevingen (carrier-grade NAT). Wanneer uw organisatie al RFC 6598-bereiken on-premises gebruikt, of wanneer de RFC 1918-ruimte is uitgeput.
Standaard openbaar IP-adres Een statisch, zoneredundant openbaar IP-adres dat is toegewezen aan één resource. Standaard beveiligd met geblokkeerd inkomend verkeer. Wanneer een resource een uniek openbaar eindpunt nodig heeft, zoals een load balancer, VPN-gateway of openbare virtuele machine.
Openbaar IP-voorvoegsel Een gereserveerd aaneengesloten blok met openbare IP-adressen uit een specifieke Azure regio. Wanneer u voorspelbare IP-bereiken nodig hebt voor NAT Gateway, Virtual Machine Scale Sets of externe toevoegen aan een goedgekeurde lijst.
BYOIP /Aangepast IP-voorvoegsel Breng uw eigen openbare IP-bereiken onder in Azure. Maakt gebruik van een proces in drie fasen: het eigendom valideren, het voorvoegsel inrichten en het vervolgens in gebruik stellen. Wanneer u de bestaande IP-reputatie wilt behouden, externe goedgekeurde lijstvermeldingen wilt onderhouden of workloads wilt migreren zonder openbare IP-adressen te wijzigen.
AZURE VIRTUAL NETWORK MANAGER IPAM Een ingebouwde functie voor IP-adresbeheer in Azure Virtual Network Manager. Algemeen beschikbaar in de meeste regio's. Biedt gecentraliseerde zichtbaarheid en toewijzingstracering voor abonnementen. Bij het beheren van veel VNets over meerdere abonnementen heen en u behoefte hebt aan geautomatiseerd bijhouden van het adresgebruik. Zie Gecentraliseerd netwerkbeheer.

Hoe te kiezen

Gebruik de volgende beslissingstabellen om uw BESLISSINGEN over IP-planning te begeleiden.

Best practices voor IP-planning

Practice Waarom Example
Een grote bovenliggende CIDR (/16) toewijzen en onderverdelen Voorkomt uitputting van adressen naarmate de workloads groeien. Eenvoudiger om routes samen te vatten. Wijs 10.1.0.0/16 toe aan de productieomgeving en deel deze vervolgens op in /24-subnetten voor elke workloadlaag.
Laat in elk subnet ten minste 30% ruimte over Schaalservices zoals Virtual Machine Scale Sets, AKS en App Service Environments verbruiken tijdens het uitschalen snel IP-adressen. Een /24-subnet biedt 251 bruikbare IP-adressen. Als uw basisimplementatie 100 gebruikt, hebt u ruimte om te verdrievoudigen.
Aaneengesloten CIDR-blokken gebruiken voor elke omgeving Vereenvoudigt het samenvatten van routes en firewallregels. Eén samenvattingsroute vertegenwoordigt de hele omgeving. Productie: 10.1.0.0/16. Staging: 10.2.0.0/16. Ontwikkeling: 10.3.0.0/16.
Vermijd door het Azure-platform gereserveerde en verboden adresbereiken Het gebruik van gereserveerde bereiken veroorzaakt routeringsfouten en implementatiefouten. Wijs 169.254.0.0/16, 168.63.129.16/32, 224.0.0.0/4, 127.0.0.0/8 of 255.255.255.255/32 niet toe.
Documenttoewijzingen in Azure IPAM of een spreadsheet Voorkomt overlapping naarmate de omgeving groeit. Centraliseert de zichtbaarheid voor netwerkteams. Gebruik Azure Virtual Network Manager IPAM voor geautomatiseerde tracering of onderhoud een gedeeld spreadsheet voor kleinere omgevingen.

Diagram waarin wordt getoond hoe een VNet-adresruimte is onderverdeeld in subnetten voor workloadlagen en toegewezen platformservices zoals gateway, firewall en Bastion.

Typen openbare IP-adressen

Type Wat het is Wanneer gebruikt u het?
Standaard openbaar IP-adres Een afzonderlijk toegewezen statisch openbaar IP-adres. Standaard zoneredundant in regio's waarin beschikbaarheidszones zijn ingeschakeld. Standaard beveiligd: al het binnenkomende verkeer wordt geblokkeerd totdat een NSG- of load balancer-regel dit toestaat. Openbaar toegankelijke load balancers, VPN-gateways, Azure Bastion, toepassingsgateways of alle resources die een uniek openbaar eindpunt nodig hebben.
Openbaar IP-voorvoegsel Een gereserveerd aaneengesloten blok met openbare IP-adressen van een specifieke regio. Garandeert opeenvolgende adressen. NAT-gateway (vereist een voorvoegsel voor meerdere uitgaande IP-adressen), Virtual Machine Scale Sets, of wanneer externe systemen een voorspelbaar bereik van IP-adressen aan een toegestane lijst moeten toevoegen.
BYOIP /Aangepast IP-voorvoegsel Openbare IP-bereiken die eigendom zijn van de klant, zijn toegevoegd aan Azure via een proces in drie fasen: validatie, inrichting en inbedrijfstelling. Regionale prefixen worden in ongeveer 30 minuten ingericht; globale prefixen duren 3–4 uur. Ip-reputatie behouden tijdens cloudmigratie, externe goedgekeurde lijstvermeldingen onderhouden of voldoen aan wettelijke vereisten voor IP-eigendom. IP-adressen die zijn afgeleid van een aangepast IP-voorvoegsel kunnen ook Azure DDoS Protection gebruiken.

Note

Openbare IP-adressen van basic-SKU's zijn op 30 september 2025 buiten gebruik gesteld. Bestaande Basis-IP's blijven functioneren, maar worden niet ondersteund en hebben geen SLA. Voer een upgrade uit naar de Standard-SKU voor alle nieuwe implementaties.

IPv6-keuze

Scenario Recommendation Onderbouwing
Workload dient alleen IPv4-clients, geen wettelijke IPv6-vereiste Alleen IPv4 Eenvoudigste configuratie. Vermijd beheeroverhead van twee stacks. De meeste Azure-services ondersteunen systeemeigen IPv4.
Workload moet IPv6-clients ondersteunen, of de regelgeving vereist IPv6-ondersteuning Dual-stack (IPv4 + IPv6) Azure VNets ondersteunen subnetten met dubbele stack. IPv6 naast IPv4 implementeren op dezelfde resources.
Workload heeft IPv6 nodig, maar is afhankelijk van Azure Firewall, Virtual WAN of RouteServer Alleen IPv4 (met externe IPv6-beëindiging) Azure Firewall, Virtual WAN en routeserver bieden momenteel geen ondersteuning voor IPv6. Beëindig IPv6 op een extern load balancer- of edge-apparaat voordat verkeer deze services binnenkomt. VPN Gateway IPv6 is beschikbaar in de preview-versie.

IPv6 dual-stack in Azure

Azure ondersteunt IPv6-implementaties met dubbele stack in virtuele netwerken. Wanneer u dual-stack inschakelt, krijgt elk subnet zowel een IPv4-bereik als een IPv6/64-bereik. Resources ontvangen adressen van beide families en kunnen tegelijkertijd communiceren via beide protocollen.

IPv6 in Azure heeft specifieke groottevereisten. IPv6-subnetten moeten exact /64 zijn. Er wordt geen andere lengte van het voorvoegsel ondersteund. De IPv6-adresruimte die u aan een VNet toewijst, moet groot genoeg zijn voor /64 subnetten voor elk subnet dat IPv6-connectiviteit nodig heeft. Plan uw IPv6-adrestoewijzing naast uw IPv4-bereiken tijdens het eerste netwerkontwerp.

De volgende Azure-services ondersteunen IPv6-configuraties met dubbele stack:

Dienst IPv6-ondersteuning
Azure Virtueel Netwerk Dual-stack-subnetten met /64-IPv6-bereiken
Standaard Load Balancer Openbare en interne IPv6-frontends
VPN Gateway IPv6-tunneleindpunten (preview; vereist opt-in)
NAT-gateway Uitgaande IPv6-adresvertaling (alleen bij StandardV2-SKU; de Standard-SKU ondersteunt alleen IPv4)
Openbaar IP-adres (standaard-SKU) Openbare IPv6-adressen
Schaalgroepen voor Virtuele Machines IPv6-netwerkinterfaces
VNET-peering IPv6-verkeer tussen gekoppelde VNets
Netwerkbeveiligingsgroepen IPv6-regels voor filteren
DNS (Azure DNS) Ondersteuning voor AAAA-records

Sleutelservices die geen ondersteuning bieden voor IPv6: Azure Firewall (vereist een IPv4-subnet), Virtual WAN (alleen IPv4) en routeserver (alleen IPv4). VPN Gateway ondersteunt IPv6 in de dual-stack-modus, maar alleen als preview-functie (hiervoor is opt-in vereist). Als uw architectuur afhankelijk is van Azure Firewall, Virtual WAN of routeserver voor verkeersinspectie of routering, ontwerpt u uw netwerk zodat IPv6-verkeer wordt verwerkt voordat deze onderdelen worden bereikt.

Zie IPv6 voor Azure Virtual Network voor gedetailleerde IPv6-mogelijkheden, beperkingen en configuratiestappen.

Azure gereserveerde adressen

Azure reserveert vijf IP-adressen in elk subnet:

Gereserveerd adres Purpose
Eerste adres (.0) Netwerk-id
Tweede adres (.1) Standaardgateway
Derde adres (.2) Azure DNS-toewijzing
Vierde adres (.3) Azure DNS-toewijzing
Laatste adres (uitzending) uitzendadres

Houd rekening met deze vijf gereserveerde adressen in alle berekeningen voor de grootte van het subnet. Een /24-subnet biedt 256 adressen minus 5 gereserveerde adressen, waardoor 251 bruikbare host-IP's behouden blijven. Het kleinste ondersteunde IPv4-subnet is /29 (8 adressen min 5 gereserveerd = 3 bruikbaar). Het grootste ondersteunde IPv4-subnet is /2.

Tip

Voor openbare IP-adressen van de standaard-SKU worden kosten in rekening gebracht, ongeacht of deze zijn gekoppeld aan een resource. Als onderdeel van IP-hygiëne verwijdert u regelmatig openbare IP-adressen die u niet meer gebruikt en publiceert u openbare IP-voorvoegsels die u niet meer gebruikt. Niet-gekoppelde openbare IP-adressen zijn een frequente bron van vermijdbare kosten en een onnodige kwetsbaarheid voor aanvallen.

Ontwerpoverwegingen

Focus op het ontwerp van lift-and-shift-IP-planning

  • Reserveer één groot CIDR-blok (een /16 is gebruikelijk) voor de landingszone en deel deze voor elke gemigreerde toepassing onder, waardoor een buffer van ongeveer 20 procent voor groei behouden blijft.
  • Kies adresbereiken die niet overlappen met on-premises netwerken waarmee u via VPN Gateway of ExpressRoute verbinding maakt, zodat routering werkt zonder adresomzetting.
  • Houd rekening met de vijf door Azure gereserveerde adressen per subnet en met de toegewezen subnetten die platformservices vereisen, zoals GatewaySubnet (/27) en AzureFirewallSubnet (/26).
  • Waar netwerken nooit peering hebben, kunt u privé-IPv4-bereiken bewust opnieuw gebruiken om adresruimte te besparen.

Ontwerpfocus voor IP-planning moderniseren

  • Wijs niet-overlappende bereiken toe in uw primaire en back-upregio’s, zodat active-active-workloads later wereldwijde peering kunnen gebruiken zonder de adressering te hoeven wijzigen.
  • Reserveer een toegewezen subnetgrootte voor App Service Environment (/24 of /23 bijna op maximale schaal). Voor AKS met CNI-overlay moet u het subnet alleen voor de knooppunten aanpassen, omdat pods afkomstig zijn van een afzonderlijke overlay-CIDR, waardoor het knooppuntsubnet veel kleiner is dan een plat CNI-ontwerp vereist.
  • Reserveer een toegewezen subnet voor privé-eindpunten, zodat paaS-acceptatie uw adresplan niet versnippert.
  • Gebruik Azure Virtual Network Manager IP-adresbeheer om toewijzingen bij te houden en te automatiseren wanneer uw omgeving wordt geschaald.

Cloudoverschrijdende ontwerpfocus voor IP-planning

  • Stel eerst een globaal adresplan in: reserveer Azure CIDR-blokken die niet overlappen met bestaande AWS-VPN's of Google Cloud VPC-netwerken, die vereist zijn voor gerouteerde VPN of interconnect.
  • Documenteer de adresbereiken van elke verbonden cloud en vertakking, zodat u samengevatte routes kunt plannen via Azure Virtual WAN.
  • Reserveer adresruimte voor doorvoeronderdelen, zoals de Virtual WAN hub- en VPN-gatewaysubnetten, met ruimte om te schalen wanneer u cloudranden en vertakkingen toevoegt.
  • Wanneer overlappingen onvermijdelijk zijn, plan dan om de betreffende VPN-verbindingen te NAT’en of workloads tijdens de migratie van nieuwe adressen te voorzien in plaats van daarna.

Prerequisites

Voordat u uw IP-adrestoewijzing plant:

  • Ontwerp van virtueel netwerk: U hebt een bestaande of geplande VNet-structuur. Als u uw VNets nog niet hebt ontworpen, raadpleegt u eerst Azure virtuele netwerken en subnetten.
  • Lokaal IP-overzicht: Leg bestaande lokale adresbereiken vast, inclusief adresbereiken die worden gebruikt door vestigingen, datacenters of andere cloudproviders. Niet-overlappende adressen zijn vereist voor hybride connectiviteit.
  • Groeiprognoses: Schat hoeveel extra subnetten en hosts u nodig hebt in de komende 2-3 jaar. Het vooraf toewijzen van adresruimte is eenvoudiger dan het later uitbreiden van een VNet.

Beveiligingsoverwegingen

IP-planning heeft directe gevolgen voor de beveiliging. Volg deze procedures om het risico te verminderen:

  • Overlapping van adres voorkomen: Overlappende IP-bereiken tussen on-premises netwerken, Azure VNets en gekoppelde VNets veroorzaken routeringsfouten. Het verkeer kan bij de verkeerde bestemming terechtkomen of stilzwijgend worden verworpen. Controleer of elk adresbereik uniek is in uw hele netwerk.
  • Vermijd uitgesloten bereiken: Azure reserveert de volgende bereiken voor platformactiviteiten. Gebruik ze nooit als VNet-adresruimte:
    • 169.254.0.0/16 (link-local)
    • 168.63.129.16/32 (Azure interne DNS)
    • 224.0.0.0/4 (meervoudige uitzending)
    • 127.0.0.0/8 (loopback)
    • 255.255.255.255/32 (uitzending)
  • Document en controle: Houd een huidige record bij van alle IP-toewijzingen. Niet-gedocumenteerde reeksen leiden tot onbedoelde overlap wanneer nieuwe workloads worden uitgerold. Gebruik Azure Virtual Network Manager IPAM voor het automatisch bijhouden van naleving of onderhoud een gedeeld spreadsheet dat tijdens elke implementatie wordt gecontroleerd.
  • Openbare IP-adressen beveiligen: Koppel Azure DDoS Protection aan openbare IP-resources in productieomgevingen. BYOIP-bereiken kunnen ook worden beveiligd door DDoS Protection.

In deze artikelen worden onderwerpen behandeld die communiceren met de planning van IP-adressen:

Meer informatie

Volgende stappen 

Tip

Zelf verkennen? Ga terug naar de overzichtsnavigator om uw volgende artikel per mogelijkheid te vinden.

De volgende stap in uw lift-and-shift-traject:

Beveilig uw subnetten met netwerkbeveiligingsgroepen: spiegel uw bestaande firewallregels als NSG-regels om uw beveiligingspostuur in Azure te behouden.

Vervolgens in uw moderniseringstraject:

Beveilig uw subnetten met netwerkbeveiligingsgroepen: dwing strikte segmentatie af, zodat alleen load balancer-verkeer uw app-subnetten bereikt.

De volgende stap in uw cross-cloudtraject:

Beveilig uw subnetten met netwerkbeveiligingsgroepen: spiegel uw AWS-beveiligingsgroepen en Google Cloud-firewallregels als Azure NSG's.

  • Last updated on