IP-Adressplanung für Azure virtuelle Netzwerke

Dieser Artikel befasst sich mit der Planung privater und öffentlicher IP-Adressen für Azure Bereitstellungen. Sie erfahren, wie Sie Adressraum zuordnen, überlappende Bereiche vermeiden, den richtigen öffentlichen IP-Typ auswählen und die IPv6 Dual-Stack-Unterstützung auswerten.

Inhalt dieses Artikels

In diesem Artikel werden Strategien für die private Adresszuweisung, öffentliche IP-Typen und SKUs, die CIDR-Planung zur Vermeidung überlappender Bereiche, Überlegungen zu Dual-Stack mit IPv6 sowie IP Address Manager (IPAM) für Umgebungen im großen Maßstab behandelt.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn Sie:

  • Stellen Sie ein virtuelles Netzwerk (VNet) in Azure bereit und müssen entscheiden, welche IP-Adressbereiche verwendet werden sollen.
  • Verbinden Azure-Netzwerke mit lokalen Umgebungen und müssen Adresskonflikte vermeiden.
  • Es muss zwischen Standard-öffentlichen IPs, öffentlichen IP-Präfixen oder eigenen IP-Bereichen (BYOIP) gewählt werden.
  • Möchten Sie verstehen, wann IPv6 Dual-Stack für Ihre Workloads geeignet ist.
  • Verwalten Sie eine große oder wachsende Umgebung und benötigen eine Strategie, um IP-Zuordnungen im Großen und Ganzen nachzuverfolgen.

Heben und Verschieben des Fokus: Wählen Sie private Bereiche aus, die sich nicht mit Ihrem lokalen Netzwerk überschneiden, sodass VPN- oder ExpressRoute-Routing ohne Übersetzung funktioniert. Reservieren Sie einen großen Block für die Zielzone mit ausreichend Platz für die Workloads, die Sie über die nächsten Jahre migrieren werden.

Modernisieren Sie den Fokus: Planen Sie nicht überlappenden Adressraum in Ihren primären und Sicherungsregionen, damit aktive Workloads später peeren können, und reservieren Sie Subnetze mit korrekter Größe für App Service-Umgebung und AKS.

Cloud-übergreifender Fokus: Erstellen Sie einen globalen Adressplan, der sich nicht mit vorhandenen AWS-VPC- oder Google-Cloud-CIDR-Bereichen überschneidet, was zwingend erforderlich ist, bevor Sie Clouds über VPN oder Interconnect verbinden.

Azure Dienste und Features

Die folgenden Dienste und Features unterstützen die IP-Adressplanung in Azure:

Dienst oder Feature Was es bietet Wann wird es verwendet?
RFC 1918 private Adressbereiche Drei reservierte Bereiche für private Verwendung: 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16. Azure VNets verwenden diese Bereiche für die interne Kommunikation. Immer: Jedes VNet erfordert mindestens einen privaten Adressbereich aus diesen Räumen.
gemeinsam genutzter Adressraum gemäß RFC 6598 100.64.0.0/10: In Azure als privater Adressraum behandelt. Ursprünglich für NAT-Umgebungen (Carrier-Grade NAT, CGNAT) konzipiert. Wenn Ihre Organisation bereits RFC 6598-Bereiche lokal verwendet oder RFC 1918-Speicherplatz erschöpft ist.
Öffentliche Standard-IP Eine statische, zonenredundante öffentliche IP-Adresse, die einer einzelnen Ressource zugewiesen ist. Standardmäßig sicher mit geschlossenem eingehendem Datenverkehr. Wenn eine Ressource einen eindeutigen öffentlichen Endpunkt benötigt, z. B. einen Lastenausgleich, ein VPN-Gateway oder einen virtuellen computer mit öffentlichem Zugriff.
Öffentliches IP-Präfix Ein reservierter zusammenhängender Block öffentlicher IP-Adressen aus einer bestimmten Azure Region. Wenn Sie vorhersehbare IP-Bereiche für NAT Gateway, Virtual Machine Scale Sets oder externes Hinzufügen zu einer genehmigten Liste benötigen.
BYOIP/ Benutzerdefiniertes IP-Präfix Integrieren Sie Ihre eigenen öffentlichen IP-Bereiche in Azure. Es wird ein dreistufiger Prozess verwendet: Besitz validieren, das Präfix bereitstellen und es dann zur Verwendung freigeben. Wenn Sie die vorhandene IP-Reputation beibehalten, Einträge in externen Genehmigungslisten beibehalten oder Workloads migrieren müssen, ohne öffentliche IPs zu ändern.
Azure Virtual Network Manager IPAM Ein integriertes IP-Adressverwaltungsfeature in Azure Virtual Network Manager. Allgemein verfügbar in den meisten Regionen. Bietet zentrale Transparenz und Nachverfolgung der Zuweisung über Abonnements hinweg. Beim Verwalten vieler VNets über mehrere Abonnements hinweg benötigen Sie eine automatisierte Nachverfolgung der Adressnutzung. Siehe zentrale Netzwerkverwaltung.

Wie man auswählt

Verwenden Sie die folgenden Entscheidungstabellen, um Ihre IP-Planungsentscheidungen zu leiten.

Bewährte Methoden für die IP-Planung

Praxis Warum? Example
Weisen Sie einen großen übergeordneten CIDR-Block (/16) zu und unterteilen Sie ihn Verhindert die Erschöpfung des Adressraums bei zunehmenden Workloads. Einfachere Zusammenfassung von Routen. Weisen Sie der Produktionsumgebung 10.1.0.0/16 zu, und erstellen Sie dann /24 Subnetze für jede Workloadebene.
Lassen Sie in jedem Subnetz mindestens 30 % Reserve. Skalierungsdienste wie Virtual Machine Scale Sets, AKS und App Service-Umgebungen verbrauchen bei horizontaler Skalierung schnell IP-Adressen. Ein /24-Subnetz bietet 251 verwendbare IPs. Wenn Ihre Baseline-Bereitstellung bei 100 liegt, haben Sie Spielraum für eine Verdreifachung.
Verwenden zusammenhängender CIDR-Blöcke für jede Umgebung Vereinfacht die Routenzusammenfassung und Firewallregeln. Eine einzelne Sammelroute stellt die gesamte Umgebung dar. Produktion: 10.1.0.0/16. Staging: 10.2.0.0/16. Entwicklung: 10.3.0.0/16.
Azure-plattformreservierte und unzulässige Bereiche vermeiden Die Verwendung reservierter Bereiche verursacht Routingfehler und Bereitstellungsfehler. Weisen Sie nicht 169.254.0.0/16, 168.63.129.16/32, 224.0.0.0/4, 127.0.0.0.0/8 oder 255.255.255.255.255/32 zu.
Zuweisungen in Azure IPAM oder in einer Kalkulationstabelle dokumentieren Verhindert Überlappungen, wenn die Umgebung wächst. Zentralisiert die Transparenz für Netzwerkteams. Verwenden Sie Azure Virtual Network Manager IPAM zum automatisierten Nachverfolgen oder Verwalten einer freigegebenen Kalkulationstabelle für kleinere Umgebungen.

Diagramm, das zeigt, wie ein VNet-Adressraum für Workloadebenen und dedizierte Plattformdienste wie Gateway, Firewall und Bastion in Subnetze unterteilt wird.

Öffentliche IP-Adresstypen

Typ Was es ist Wann wird es verwendet?
Öffentliche Standard-IP Eine einzeln zugewiesene statische öffentliche IP. Standardmäßig zonenredundant in Regionen mit Verfügbarkeitszonen. Standardmäßig sicher: Der gesamte eingehende Datenverkehr wird blockiert, bis eine NSG- oder Load Balancer-Regel ihn zulässt. Öffentlich zugängliche Lastenausgleichsgeräte, VPN-Gateways, Azure Bastion, Anwendungsgateways oder ressourcen, die einen eindeutigen öffentlichen Endpunkt benötigen.
Öffentliches IP-Präfix Ein reservierter zusammenhängender Block öffentlicher IPs aus einer bestimmten Region. Garantiert sequenzielle Adressen. NAT-Gateway (erfordert Präfix für mehrere ausgehende IPs), Virtual Machine Scale Sets oder wenn externe Systeme einer genehmigten Liste einen vorhersehbaren Bereich von IPs hinzufügen müssen.
BYOIP/ Benutzerdefiniertes IP-Präfix Kundeneigene öffentliche IP-Bereiche werden über einen dreistufigen Prozess in Azure integriert: Validierung, Bereitstellung und Inbetriebnahme. Regionale Präfixe werden in etwa 30 Minuten in Betrieb genommen; globale Präfixe benötigen 3–4 Stunden. Schutz der IP-Zuverlässigkeit während der Cloudmigration, Aufrechterhaltung externer genehmigter Listeneinträge oder Erfüllung gesetzlicher Anforderungen für DEN IP-Besitz. IPs, die von einem benutzerdefinierten IP-Präfix abgeleitet sind, können auch Azure DDoS-Schutz verwenden.

Note

Öffentliche IP-Adressen der Basic-SKU wurden am 30. September 2025 eingestellt. Vorhandene Standard-IPs funktionieren weiterhin, werden aber nicht unterstützt und weisen keine SLA auf. Upgrade auf Standard-SKU für alle neuen Bereitstellungen.

IPv6-Entscheidung

Scenario Recommendation Begründung
Workload dient nur IPv4-Clients, keine behördliche IPv6-Anforderung Nur IPv4 Einfachste Konfiguration. Verhindert den Mehraufwand für die Dual-Stack-Verwaltung. Die meisten Azure Dienste unterstützen IPv4 nativ.
Workload muss IPv6-Clients bereitstellen, oder Vorschriften erfordern IPv6-Unterstützung Dualer Stapel (IPv4 + IPv6) Azure VNets unterstützen Subnetze mit dualen Stapeln. Stellen Sie IPv6 zusammen mit IPv4 auf denselben Ressourcen bereit.
Die Workload benötigt IPv6, ist jedoch auf Azure Firewall, Virtual WAN oder Route Server angewiesen. Nur IPv4 (mit externer IPv6-Beendigung) Azure Firewall, Virtual WAN und Route Server unterstützen derzeit IPv6 nicht. Terminieren Sie IPv6 an einem externen Load Balancer oder Edge-Gerät, bevor der Datenverkehr diese Dienste erreicht. VPN Gateway IPv6 ist in der Vorschau verfügbar.

IPv6-Dual-Stack in Azure

Azure unterstützt IPv6 Dual-Stack-Bereitstellungen in virtuellen Netzwerken. Wenn Sie Dual-Stack aktivieren, erhält jedes Subnetz sowohl einen IPv4-Bereich als auch einen IPv6-/64-Bereich. Ressourcen empfangen Adressen von beiden Familien und können über beide Protokolle gleichzeitig kommunizieren.

IPv6 in Azure weist spezifische Größenanforderungen auf. IPv6-Subnetze müssen genau /64 sein. Es wird keine andere Präfixlänge unterstützt. Der IPv6-Adressraum, den Sie einem VNet zuweisen, muss groß genug sein, um /64 Subnetze für jedes Subnetz aufzunehmen, das IPv6-Konnektivität benötigt. Planen Sie ihre IPv6-Adresszuweisung zusammen mit Ihren IPv4-Bereichen während des anfänglichen Netzwerkentwurfs.

Die folgenden Azure-Dienste unterstützen IPv6-Konfigurationen mit dualen Stapeln:

Service IPv6-Unterstützung
Virtuelles Azure-Netzwerk Dual-Stack-Subnetze mit /64 IPv6-Bereichen
Standard-Lastenausgleich Öffentliche und interne IPv6-Frontends
VPN Gateway IPv6-Tunnelendpunkte (Vorschau; erfordert Opt-In)
NAT Gateway IPv6-Translation für ausgehenden Datenverkehr (nur StandardV2-SKU; Standard-SKU unterstützt nur IPv4)
Öffentliche IP-Adresse (Standard-SKU) Öffentliche IPv6-Adressen
Skalierungssätze für virtuelle Maschinen IPv6-Netzwerkschnittstellen
VNet-Peering IPv6-Datenverkehr über mittels VNet-Peering verbundene VNets
Netzwerksicherheitsgruppen IPv6-Regeln zum Filtern
DNS (Azure DNS) Unterstützung für AAAA-Datensätze

Wichtige Dienste, die IPv6 nicht unterstützen: Azure Firewall (erfordert ein nur IPv4-Subnetz), Virtual WAN (nur IPv4) und Route Server (nur IPv4). VPN Gateway unterstützt IPv6 im Dual-Stack-Modus, aber nur als Vorschaufeature (erfordert Opt-In). Wenn Ihre Architektur von Azure Firewall, Virtual WAN oder Route Server für die Datenverkehrsüberprüfung oder das Routing abhängt, entwerfen Sie Ihr Netzwerk so, dass IPv6-Datenverkehr behandelt wird, bevor Sie diese Komponenten erreichen.

Ausführliche IPv6-Funktionen, Einschränkungen und Konfigurationsschritte finden Sie unter IPv6 für Azure Virtual Network.

Für Azure reservierte Adressen

Azure reserviert fünf IP-Adressen in jedem Subnetz:

Reservierte Adresse Purpose
Erste Adresse (.0) Netzwerkbezeichner
Zweite Adresse (.1) Standardgateway
Dritte Adresse (.2) Azure DNS-Zuordnung
Vierte Adresse (.3) Azure DNS-Zuordnung
Letzte Adresse (Übertragung) Übertragungsadresse

Berücksichtigen Sie diese fünf reservierten Adressen in alle Subnetzgrößenberechnungen. Ein /24-Subnetz umfasst insgesamt 256 Adressen, abzüglich 5 reservierter Adressen, sodass 251 nutzbare Host-IP-Adressen verbleiben. Das kleinste unterstützte IPv4-Subnetz ist /29 (8 Adressen minus 5 reserviert = 3 verwendbar). Das größte unterstützte IPv4-Subnetz ist /2.

Tip

Für öffentliche IP-Adressen der Standard-SKU fallen Gebühren an, unabhängig davon, ob sie einer Ressource zugeordnet sind. Löschen Sie im Rahmen der IP-Hygiene regelmäßig öffentliche IP-Adressen, die Sie nicht mehr verwenden, und geben Sie öffentliche IP-Präfixe frei, die Sie überwischen. Nicht zugewiesene öffentliche IP-Adressen sind eine häufige Ursache für vermeidbare Kosten und eine unnötige Angriffsfläche.

Überlegungen zum Entwurf

Designfokus der Lift-and-Shift-IP-Planung

  • Reservieren Sie für die Landing Zone einen einzelnen großen CIDR-Block (ein /16 ist üblich) und unterteilen Sie ihn für jede migrierte Anwendung, wobei Sie einen Puffer von etwa 20 % für künftiges Wachstum lassen.
  • Wählen Sie Bereiche aus, die sich nicht mit lokalen Netzwerken überschneiden, die Sie über VPN Gateway oder ExpressRoute verbinden, sodass routing ohne Adressübersetzung funktioniert.
  • Berücksichtigen Sie die fünf von Azure pro Subnetz reservierten Adressen sowie die dedizierten Subnetze, die Plattformdienste erfordern, wie GatewaySubnet (/27) und AzureFirewallSubnet (/26).
  • Wo Netzwerke niemals eine Peering-Verbindung eingehen, können Sie private IPv4-Bereiche gezielt wiederverwenden, um den Adressraum zu schonen.

Modernisieren des Designfokus für die IP-Planung

  • Weisen Sie nicht überlappende Bereiche in Ihren primären und Sicherungsregionen zu, damit aktive Workloads später globales Peering ohne erneute Adressierung verwenden können.
  • Reservieren Sie ein dediziertes Subnetz für App Service-Umgebung mit der Größe /24 oder /23 bei nahezu maximaler Skalierung. Bei AKS mit CNI-Overlay dimensionieren Sie das Subnetz nur für die Knoten, da Pods Adressen aus einem separaten Overlay-CIDR-Block beziehen, wodurch das Knotensubnetz deutlich kleiner ausfällt, als es bei einem flachen CNI-Design erforderlich wäre.
  • Reservieren Sie ein dediziertes Subnetz für private Endpunkte, damit die PaaS-Einführung Ihren Adressplan nicht fragmentiert.
  • Verwenden Sie Azure Virtual Network Manager IP-Adressverwaltung, um Zuordnungen nachzuverfolgen und zu automatisieren, während Ihre Umgebung skaliert wird.

Designfokus für die cloudübergreifende IP-Planung

  • Richten Sie zuerst einen globalen Adressplan ein: reservieren Sie Azure CIDR-Blöcke, die sich nicht mit vorhandenen AWS VPCs oder Google Cloud RPC-Netzwerken überschneiden, die für routingfähige VPN- oder Verbindungsverbindungen erforderlich sind.
  • Dokumentieren Sie die Adressbereiche der einzelnen verbundenen Cloud- und Zweigstellen, damit Sie zusammengefasste Routen über Azure Virtual WAN planen können.
  • Reservieren Sie Adressraum für Transitkomponenten, z. B. die Virtual WAN Hub- und VPN-Gateway-Subnetze, mit Platz zum Skalieren, während Sie Cloud-Edges und Verzweigungen hinzufügen.
  • Wenn Überlappungen unvermeidbar sind, planen Sie, NAT auf die betroffenen VPN-Verbindungen anzuwenden oder die Workloads während der Migration neu zu adressieren, statt erst danach.

Voraussetzungen

Bevor Sie Ihre IP-Adresszuweisung planen:

  • Entwurf des virtuellen Netzwerks: Sie verfügen über eine vorhandene oder geplante VNet-Struktur. Wenn Sie Ihre VNets noch nicht entworfen haben, lesen Sie zunächst Azure Virtual Networks und Subnetze.
  • Lokales IP-Inventar: Dokumentieren Sie vorhandene lokale Adressbereiche, einschließlich aller Bereiche, die von Zweigstellen, Rechenzentren oder anderen Cloudanbietern verwendet werden. Nicht überlappende Adressen sind für die Hybridkonnektivität erforderlich.
  • Wachstumsprognosen: Schätzen Sie, wie viele zusätzliche Subnetze und Hosts Sie in den nächsten 2 bis 3 Jahren benötigen werden. Adressraum von vornherein zuzuweisen ist einfacher, als ein VNet später zu erweitern.

Sicherheitsüberlegungen

Die IP-Planung hat direkte Sicherheitsauswirkungen. Befolgen Sie die folgenden Methoden, um Risiken zu reduzieren:

  • Verhindern von Adressüberlappungen: Überlappende IP-Bereiche zwischen lokalen Netzwerken, Azure VNets und peered VNets verursachen Routingfehler. Der Datenverkehr kann das falsche Ziel erreichen oder im Hintergrund gelöscht werden. Stellen Sie sicher, dass jeder Adressbereich im gesamten Netzwerk eindeutig ist.
  • Vermeiden Sie verbotene Bereiche: Azure behält sich die folgenden Bereiche für Plattformvorgänge vor. Verwenden Sie sie niemals als VNet-Adressraum:
    • 169.254.0.0/16 (link-local)
    • 168.63.129.16/32 (internes Azure-DNS)
    • 224.0.0.0/4 (Multicast)
    • 127.0.0.0/8 (Loopback)
    • 255.255.255.255/32 (Übertragung)
  • Dokument und Überwachung: Verwalten Sie einen aktuellen Datensatz aller IP-Zuordnungen. Undokumentierte Bereiche führen zu unbeabsichtigten Überschneidungen, wenn neue Workloads bereitgestellt werden. Verwenden Sie Azure Virtual Network Manager IPAM für die automatisierte Compliance-Nachverfolgung, oder verwalten Sie eine freigegebene Kalkulationstabelle, die während jeder Bereitstellung überprüft wird.
  • Öffentliche IP-Adressen schützen: Verknüpfen Sie Azure DDoS Protection mit Ressourcen für öffentliche IP-Adressen in Produktionsumgebungen. BYOIP-Bereiche können auch durch DDoS Protection geschützt werden.

In diesen Artikeln werden Themen behandelt, die mit der IP-Adressplanung interagieren:

Weitere Informationen

Nächste Schritte

Tip

Auf eigene Faust erkunden? Kehren Sie zum Übersichtsnavigator zurück, um Ihren nächsten Artikel nach Funktion zu finden.

Als Nächstes in Ihrer Lift-and-Shift-Reise:

Sichern Sie Ihre Subnetze mit Netzwerksicherheitsgruppen: Spiegeln Sie Ihre vorhandenen Firewallregeln als NSG-Regeln, um Ihren Sicherheitsstatus in Azure beizubehalten.

Als Nächstes in Ihrer Modernisierungsreise:

Sichern Sie Ihre Subnetze mit Netzwerksicherheitsgruppen: Erzwingen Sie eine strikte Segmentierung, sodass nur Load Balancer-Datenverkehr Ihre App-Subnetze erreicht.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Sichern Sie Ihre Subnetze mit Netzwerksicherheitsgruppen: Spiegeln Sie Ihre AWS-Sicherheitsgruppen und Google Cloud-Firewallregeln als Azure NSGs wieder.

  • Last updated on