Freigeben über

Plan für die IP-Adressierung

Es ist wichtig, dass Ihre Organisation die IP-Adressierung in Azure plant. Durch die Planung wird sichergestellt, dass der IP-Adressraum sich nicht an lokalen Standorten und in Azure-Regionen überschneidet.

Überlegungen zum Entwurf:

  • Überlappende IP-Adressräume in lokalen Umgebungen und Azure-Regionen führen zu erheblichen Konflikt- und Spannungsherausforderungen.

  • Das Azure VPN-Gateway kann lokale Standorte mit sich überschneidenden IP-Adressbereichen über die Network Address Translation (NAT)-Funktion verbinden. Dieses Feature ist allgemein in Azure Virtual WAN und in eigenständigem Azure VPN-Gateway verfügbar.

    {Diagramm, das zeigt, wie NAT mit VPN-Gateway funktioniert.}

  • Sie können nach dem Erstellen eines virtuellen Netzwerks Adressraum hinzufügen. Dieser Vorgang benötigt keinen Ausfall, wenn das virtuelle Netzwerk bereits über virtuelles Netzwerk-Peering mit einem anderen virtuellen Netzwerk verbunden ist. Stattdessen benötigt jedes Remote-Peering einen erneuten Synchronisierungsvorgang , nachdem sich der Netzwerkspeicherplatz geändert hat.

  • Azure reserviert fünf IP-Adressen innerhalb jedes Subnetzes. Berücksichtigen Sie diese Adressen, wenn Sie virtuelle Netzwerke dimensionieren und die dazugehörigen Subnetze einschließen.

  • Einige Azure-Dienste erfordern dedizierte Subnetze. Zu diesen Diensten gehören Azure Firewall und Azure VPN-Gateway.

  • Sie können Subnetze an bestimmte Dienste delegieren, um Instanzen eines Diensts innerhalb des Subnetzes zu erstellen.

Entwurfsempfehlungen:

  • Planen Sie vorab nicht-überlappende IP-Adressräume in den Azure-Regionen und an lokalen Standorten.

  • Verwenden Sie IP-Adressen aus der Adresszuweisung für privates Internet, die als RFC 1918-Adressen bezeichnet werden.

  • Verwenden Sie nicht die folgenden Adressbereiche:

    • 224.0.0.0/4 (Multicast)
    • 255.255.255.255/32 (Übertragung)
    • 127.0.0.0/8 (Loopback)
    • 169.254.0.0/16 (Verbindungslokal)
    • 168.63.129.16/32 (internes DNS)

  • Für Umgebungen mit eingeschränkter Verfügbarkeit privater IP-Adressen sollten Sie IPv6 verwenden. Virtuelle Netzwerke können nur IPv4- oder Dualstapel IPv4+IPv6 sein.

    Diagramm, das den dualen IPv4- und IPv6-Stapel zeigt.

  • Erstellen Sie keine großen virtuellen Netzwerke wie /16. Dadurch wird sichergestellt, dass der IP-Adressraum nicht verschwendet wird. Das kleinste unterstützte IPv4-Subnetz ist /29, und das größte ist /2, wenn man klassenlose Inter-Domain-Routing(CIDR)-Subnetzdefinitionen verwendet. IPv6-Subnetze müssen genau /64 in der Größe sein.

  • Erstellen Sie keine virtuellen Netzwerke, ohne den erforderlichen Adressraum im Voraus zu planen.

  • Verwenden Sie keine öffentlichen IP-Adressen für virtuelle Netzwerke, insbesondere, wenn die öffentlichen IP-Adressen nicht zu Ihrer Organisation gehören.

  • Berücksichtigen Sie die Dienste, die Sie verwenden werden. Es gibt einige Dienste mit reservierten IP-Adressen, etwa AKS mit CNI-Netzwerken

  • Verwenden Sie nicht routbare Landezonen-Spoke-Virtualnetzwerke und den Azure Private Link-Dienst, um die Erschöpfung von IPv4-Adressen zu verhindern.

Überlegungen zu IPv6

Eine zunehmende Anzahl von Organisationen nimmt IPv6 in ihren Umgebungen an. Diese Einführung wird durch die öffentliche IPv4-Raumausschöpfung, private IPv4-Knappheit, insbesondere in großen Netzwerken, gesteuert und die Notwendigkeit, verbindungen mit nur IPv6-Clients bereitzustellen. Es gibt keinen universellen Ansatz für die Einführung von IPv6. Es gibt jedoch bewährte Methoden, die Sie befolgen können, wenn Sie IPv6 planen und in Ihren vorhandenen Azure-Netzwerken implementieren.

Das Microsoft Cloud Adoption Framework für Azure hilft Ihnen, die Überlegungen zu verstehen, die sie berücksichtigen müssen, wenn Sie Systeme in der Cloud erstellen. Informationen zu den bewährten Architekturmethoden für das Entwerfen nachhaltiger Systeme finden Sie unter Designprinzipien für die Azure-Zielzone. Ausführliche Empfehlungen und bewährte Methoden für Ihre Cloudarchitektur, einschließlich Referenzarchitekturbereitstellungen, Diagramme und Leitfäden, finden Sie im Architekturcenter-Handbuch für IPv6.

Überlegungen zum Entwurf:

  • Gestalten Sie die Einführung von IPv6 phasenweise. Implementieren Sie nach Bedarf IPv6 basierend auf Ihren Geschäftlichen Anforderungen. Denken Sie daran, dass IPv4 und IPv6 so lange wie nötig koexistieren können.

  • In Szenarien, in denen Anwendungen auf Infrastruktur as a Service (IaaS)-Dienste basieren, die über vollständige IPv6-Unterstützung verfügen, z. B. virtuelle Computer (VMs), ist die systemeigene End-to-End-Verwendung von IPv4 und IPv6 möglich. Diese Konfiguration vermeidet Übersetzungskomplikationen und stellt die meisten Informationen für den Server und die Anwendung bereit.

    Sie können Basic-SKU netzwerkorientierte Azure Load Balancer mit einer IPv6-Adresse bereitstellen. Diese Konfiguration ermöglicht die systemeigene End-to-End-IPv6-Konnektivität zwischen dem öffentlichen Internet und Azure-VMs über den Lastenausgleich. Dieser Ansatz erleichtert auch native End-to-End-ausgehende Verbindungen zwischen VMs und IPv6-fähigen Clients im öffentlichen Internet. Beachten Sie, dass für diesen Ansatz jedes Gerät im Pfad zum Behandeln von IPv6-Datenverkehr erforderlich ist.

    Der systemeigene End-to-End-Ansatz ist am nützlichsten für die direkte Server-zu-Server- oder Client-zu-Server-Kommunikation. Es ist für die meisten Webdienste und Anwendungen nicht nützlich, die in der Regel durch Firewalls, Webanwendungsfirewalls oder Reverseproxys geschützt sind.

  • Einige komplexe Bereitstellungen und Anwendungen, die eine Kombination aus Drittanbieterdiensten, Plattform-as-a-Service-Diensten (PaaS)-Diensten und Back-End-Lösungen verwenden, unterstützen möglicherweise nicht systemeigene IPv6. In diesen Fällen müssen Sie NAT/NAT64 oder eine IPv6-Proxylösung verwenden, um die Kommunikation zwischen IPv6 und IPv4 zu ermöglichen.

  • Wenn die Komplexität der Anwendungsarchitektur oder anderer Faktoren wie Schulungskosten als bedeutend angesehen wird, sollten Sie die Nutzung der Nur-IPv4-Infrastruktur im Back-End in Betracht ziehen und ein duales IPv4/IPv6-Gateway eines virtuellen Netzwerk-Geräts (NVA) eines Drittanbieters zur Dienstbereitstellung einsetzen.

    Eine typische Bereitstellung, die einen NVA verwendet, kann wie folgt aussehen:

    Diagramm, das ein Dual-Stack-IPv4/IPv6-Gateway zeigt, das Zugriff auf ein nur-IPv4-Backend ermöglicht.

Entwurfsempfehlungen:

Hier ist ein genauerer Blick darauf, wie eine typische Architektur aussehen könnte:

Diagramm, das ein IPv4/IPv6-Lastenausgleichsmodul zeigt, das Zugriff auf ein nur IPv4-Back-End ermöglicht.

  • Stellen Sie das NVA in Virtual Machine Scale Sets mit flexibler Orchestrierung (VMSS Flex) für Resilienz bereit und machen Sie es über den Azure Load Balancer, welcher über ein öffentliches IP-Adress-Front-End verfügt, dem Internet verfügbar.

    Die NVAs akzeptieren IPv4- und IPv6-Datenverkehr und übersetzen ihn in nur IPv4-Datenverkehr, um auf die Anwendung im Anwendungssubnetz zuzugreifen. Der Ansatz reduziert die Komplexität für das Anwendungsteam und reduziert die Angriffsfläche.

  • Stellen Sie Azure Front Door bereit, um ein globales Routing für den Webdatenverkehr bereitzustellen.

    Zu den Funktionen von Azure Front Door gehört das Weiterleiten von IPv6-Clientanforderungen und -Datenverkehr an ein reines IPv4-Backend, wie in diesem Beispiel gezeigt:

    Diagramm, das Azure Front Door zeigt, die den Zugriff auf ein Backend ermöglicht, das nur IPv4 unterstützt.

Dies sind die wichtigsten Unterschiede zwischen dem NVA-Ansatz und dem Azure Front Door-Ansatz:

  • NVAs werden vom Kunden verwaltet, arbeiten an Layer 4 des OSI-Modells und können in demselben virtuellen Azure-Netzwerk wie die Anwendung mit einer privaten und öffentlichen Schnittstelle bereitgestellt werden.
  • Azure Front Door ist ein globaler Azure PaaS-Dienst und arbeitet bei Layer 7 (HTTP/HTTPS). Das Back-End der Anwendung ist ein internetorientierter Dienst, der gesperrt werden kann, um nur Datenverkehr von Azure Front Door zu akzeptieren.

In komplexen Umgebungen können Sie eine Kombination aus beiden verwenden. NVAs werden im Rahmen einer regionalen Bereitstellung eingesetzt. Azure Front Door wird verwendet, um den Datenverkehr an eine oder mehrere regionale Bereitstellungen in verschiedenen Azure-Regionen oder an anderen internetorientierten Standorten weiterzuleiten. Um die beste Lösung zu ermitteln, empfehlen wir Ihnen, die Funktionen von Azure Front Door und der Produktdokumentation zu überprüfen.

CIDR-Blöcke des virtuellen IPv6-Netzwerks:

  • Sie können einen einzelnen klassenlosen IPv6-Inter-Domänen-Routingblock (CIDR) zuordnen, wenn Sie ein neues virtuelles Netzwerk in einer vorhandenen Azure-Bereitstellung in Ihrem Abonnement erstellen. Die Größe des Subnetzes für IPv6 muss "/64" sein. Die Verwendung dieser Größe stellt eine zukünftige Kompatibilität sicher, wenn Sie das Routing des Subnetzes an ein lokales Netzwerk aktivieren möchten. Einige Router können nur /64 IPv6-Routen akzeptieren.
  • Wenn Sie über ein vorhandenes virtuelles Netzwerk verfügen, das nur IPv4 unterstützt, und Ressourcen in Ihrem Subnetz, die nur für die Verwendung von IPv4 konfiguriert sind, können Sie die IPv6-Unterstützung für Ihr virtuelles Netzwerk und Ihre Ressourcen aktivieren. Ihr virtuelles Netzwerk kann im Dual-Stack-Modus ausgeführt werden, wodurch Ihre Ressourcen über IPv4, IPv6 oder beides kommunizieren können. IPv4- und IPv6-Kommunikation sind voneinander unabhängig.
  • Sie können die IPv4-Unterstützung für Ihr virtuelles Netzwerk und Ihre Subnetze nicht deaktivieren. IPv4 ist das Standardmäßige IP-Adressierungssystem für virtuelle Azure-Netzwerke.
  • Ordnen Sie einen IPv6 CIDR-Block Ihrem virtuellen Netzwerk und Subnetz zu oder verwenden Sie BYOIP IPv6. CIDR-Notation ist eine Methode zur Darstellung einer IP-Adresse und ihrer Netzwerkmaske. Die Formate dieser Adressen sind wie folgt:
    • Eine einzelne IPv4-Adresse ist 32 Bit, mit vier Gruppen von bis zu drei Dezimalziffern. Beispiel: 10.0.1.0.
    • Ein IPv4 CIDR-Block hat vier Gruppen von bis zu drei Dezimalstellen, von 0 bis 255, getrennt durch Punkte und gefolgt von einem Schrägstrich und einer Zahl von 0 bis 32. Beispiel: 10.0.0.0/16.
    • Eine einzelne IPv6-Adresse ist 128 Bit. Es enthält acht Gruppen von vier hexadezimalen Ziffern. Beispiel: 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
    • Ein IPv6 CIDR-Block weist vier Gruppen von bis zu vier hexadezimalen Ziffern auf, getrennt durch Doppelpunkte, gefolgt von einem Doppelpunkt und anschließend einem Schrägstrich und einer Zahl von 1 bis 128. Beispiel: 2001:db8:1234:1a00::/64.
  • Aktualisieren Sie Ihre Routentabellen, um IPv6-Datenverkehr weiterzuleiten. Erstellen Sie für öffentlichen Datenverkehr eine Route, die den gesamten IPv6-Datenverkehr vom Subnetz an das VPN-Gateway oder ein Azure ExpressRoute-Gateway weiter leitet.
  • Aktualisieren Sie Ihre Sicherheitsgruppenregeln so, dass Regeln für IPv6-Adressen enthalten sind. Dadurch kann IPv6-Datenverkehr zu und von Ihren Instanzen fließen. Wenn Sie Über Netzwerksicherheitsgruppenregeln verfügen, um den Datenverkehrsfluss an und von Ihrem Subnetz zu steuern, müssen Sie Regeln für IPv6-Datenverkehr einschließen.
  • Wenn Ihr Instanztyp IPv6 nicht unterstützt, verwenden Sie dualen Stapel, oder stellen Sie einen NVA bereit, wie zuvor beschrieben, der von IPv4 in IPv6 übersetzt wird.

IP-Adressverwaltung (IPAM)-Tools

Die Verwendung eines IPAM-Tools kann Sie bei der IP-Adressplanung in Azure unterstützen, da es eine zentrale Verwaltung und Sichtbarkeit bietet und Überschneidungen und Konflikte in IP-Adressräumen verhindert. Dieser Abschnitt führt Sie durch wichtige Überlegungen und Empfehlungen bei der Einführung eines IPAM-Tools.

Überlegungen zum Entwurf:

Je nach Ihren Anforderungen und der Größe Ihrer Organisation stehen zahlreiche IPAM-Tools zur Verfügung. Die Optionen reichen von einem einfachen Excel-basierten Bestand bis hin zu open-source communitygesteuerten Lösungen oder umfassenden Enterprise-Produkten mit erweiterten Features und Support.

  • Berücksichtigen Sie diese Faktoren beim Auswerten des zu implementierenden IPAM-Tools:

    • Mindestfunktionen, die von Ihrer Organisation benötigt werden
    • Gesamtbetriebskosten (TCO), einschließlich Lizenzierung und laufender Wartung
    • Überwachungspfade, Protokollierung und rollenbasierte Zugriffssteuerungen
    • Authentifizierung und Autorisierung über Die Microsoft Entra-ID
    • Zugriff über API
    • Integrationen mit anderen Netzwerkverwaltungstools und -systemen
    • Aktiver Communitysupport oder die Ebene des Supports vom Softwareanbieter

  • Erwägen Sie die Auswertung eines Open-Source-IPAM-Tools wie Azure IPAM. Azure IPAM ist eine einfache Lösung, die auf der Azure-Plattform basiert. Es ermittelt automatisch die IP-Adressnutzung innerhalb Ihres Azure-Mandanten und ermöglicht es Ihnen, alles über eine zentralisierte Benutzeroberfläche oder über eine RESTful-API zu verwalten.

  • Berücksichtigen Sie das Betriebsmodell Ihrer Organisationen und den Besitz des IPAM-Tools. Das Ziel der Implementierung eines IPAM-Tools besteht darin, den Prozess der Anforderung neuer IP-Adressplätze für Anwendungsteams ohne Abhängigkeiten und Engpässe zu optimieren.

  • Ein wichtiger Bestandteil der IPAM-Toolfunktionalität besteht darin, die Nutzung des IP-Adressraums zu inventarisieren und logisch zu organisieren.

Entwurfsempfehlungen:

  • Der Vorgang zum Reservieren nicht überlappender IP-Adressräume sollte das Anfordern unterschiedlicher Größen basierend auf den Anforderungen der einzelnen Anwendungslandzonen unterstützen.

    • So können Sie beispielsweise T-Shirt-Größenanpassungen einführen, damit Anwendungsteams ihre Anforderungen beschreiben können:
      • Klein - /24 - 256 IP-Adressen
      • Mittel – /22 – 1.024 IP-Adressen
      • Groß - /20 - 4.096 IP-Adressen

  • Ihr IPAM-Tool sollte über eine API zum Reservieren nicht überlappender IP-Adressräume verfügen, um einen Infrastruktur as Code (IaC)-Ansatz zu unterstützen. Diese Funktion ist auch entscheidend für die nahtlose Integration von IPAM in Ihren Abonnementverkaufsprozess, wodurch das Risiko von Fehlern und die Notwendigkeit eines manuellen Eingriffs reduziert werden.

    • Ein Beispiel für einen IaC-Ansatz ist Bicep mit seiner Bereitstellungsskriptfunktionalität oder Terraform-Datenquellen , um Daten dynamisch aus der IPAM-API abzurufen.

  • Erstellen Sie eine systematische Anordnung für Ihre IP-Adressräume, indem Sie sie entsprechend Azure-Regionen und Workload-Archetypen strukturieren und so einen sauberen und nachverfolgbaren Netzwerkbestand sicherstellen.

  • Der Außerbetriebsetzungsprozess für Workloads sollte das Entfernen von nicht mehr verwendeten IP-Adressräumen umfassen, die später für anstehende neue Workloads neu verwendet werden können und eine effiziente Ressourcenauslastung fördern.