Planen der IP-Adressierung

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

Überlegungen zum Entwurf:

• Die Überlappung von IP-Adressräumen zwischen lokalen und Azure-Regionen führt zu erheblichen Konflikten.

• Azure VPN Gateway kann überlappende, lokale Standorte mit überlappenden IP-Adressräumen durch die NAT-Funktion (Netzwerkadressenübersetzung) verbinden. Dieses Feature ist allgemein in Azure Virtual WAN und im eigenständigen Dienst Azure VPN Gateway verfügbar.

  

• Nach dem Erstellen Ihres virtuellen Netzwerks können Sie weitere Adressräume hinzufügen. Dieser Prozess bedingt keinen Ausfall, wenn das virtuelle Netzwerk bereits über ein Peering virtueller Netzwerke mit einem anderen virtuellen Netzwerk verbunden ist. Stattdessen muss für jedes Remotepeering ein Neusynchronisierungsvorgang durchgeführt werden, nachdem sich der Netzwerkadressraum geändert hat.

• Azure reserviert fünf IP-Adressen in jedem Subnetz. Berücksichtigen Sie diese Adressen, wenn Sie die Größe virtueller Netzwerke und Subnetze anpassen.

• 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 im Subnetz zu erstellen.

Entwurfsempfehlungen:

• Planen Sie nicht überlappende IP-Adressräume für Azure-Regionen und lokale Standorte bereits im Voraus.

• Verwenden Sie die IP-Adressen aus der Adresszuordnung für private Internetadressen, 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)

• In Umgebungen mit begrenzter Verfügbarkeit von privaten IP-Adressen sollten Sie die Verwendung von IPv6 erwägen. Virtuelle Netzwerke können nur IPv4-Stapel oder duale IPv4- und IPv6-Stapel sein.

  

• 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 bei Verwendung von CIDR-Subnetzdefinitionen (klassenloses domänenübergreifendes Routing) /2. IPv6-Subnetze müssen genau die Größe /64 aufweisen.

• 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 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 routingfähige virtuelle Zielzonen-Spoke-Netzwerke und den Azure Private Link-Dienst, um die IPv4-Erschöpfung zu verhindern.

Überlegungen zu IPv6

Eine zunehmende Anzahl von Organisationen führt IPv6 in ihren Umgebungen ein. Diese Einführung wird durch die Ausschöpfung des öffentlichen IPv4-Raums, die Knappheit privater IPv4–Netzwerke, insbesondere in großen Netzwerken, und die Notwendigkeit, Verbindungen mit nur IPv6-Clients bereitzustellen, vorangetrieben. 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, Diagrammen und Leitfäden, finden Sie im Azure Architecture Center-Anleitung für IPv6.

Überlegungen zum Entwurf:

• Phase Ihrer IPv6-Einführung. Implementieren Sie IPv6 basierend auf Ihren geschäftlichen Anforderungen nach Bedarf. 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)-Diensten 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.

  Azure Load Balancer mit Internetzugriff für die SKU „Basic“ können mit einer IPv6-Adresse bereitgestellt werden. Diese Konfiguration ermöglicht native End-to-End-IPv6-Konnektivität zwischen öffentlichen Internetclients und Azure Virtual Machines (VMs) über den Load Balancer. Dieser Ansatz ermöglicht auch die native ausgehende End-to-End-IPv6-Konnektivität zwischen VMs und öffentlichen IPv6-fähigen Internetclients. Beachten Sie, dass für diesen Ansatz jedes Gerät im Pfad zum Verarbeiten 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. Er 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) 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 signifikant angesehen wird, sollten Sie die Infrastruktur, die ausschließlich IPv4 verwendet, weiterhin auf dem Back-End verwenden und ein virtuelles Netzwerkgerät (NVA) eines Drittanbieters mit IPv4/IPv6-Gateway mit dualem Stapel für die Dienstbereitstellung bereitstellen.

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

  

Entwurfsempfehlungen:

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

• Stellen Sie die NVA in Skalierungsgruppen für virtuelle Computer mit flexibler Orchestrierung (VMSS Flex) für Resilienz bereit und machen Sie über Azure Load-Balancer, das über ein öffentliches IP-Adress-Front-End verfügt, im Internet verfügbar.

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

• Stellen Sie Azure Front Door für globales Datenverkehrsrouting bereit.

  Zu den Azure Front Door-Funktionen gehören Proxy-IPv6-Clientanforderungen und Datenverkehr zu einem reinen IPv4-Back-End, wie hier gezeigt:

  

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

• NVAs werden vom Kunden verwaltet, arbeiten auf Ebene 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, der auf Ebene 7 (HTTP/HTTPS) arbeitet. 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 beidem verwenden. NVAs werden in einer regionalen Bereitstellung verwendet. Azure Front Door wird verwendet, um den Datenverkehr an eine oder mehrere regionale Bereitstellungen in verschiedenen Azure-Regionen oder an andere internetorientierte Standorte 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 IPv6 Classless Inter-Domain Routing-Block (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 haben, 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-Adresssystem für virtuelle Azure-Netzwerke.
• Weisen Sie einen IPv6 CIDR-Blocks zu Ihrem virtuellen Netzwerk und Subnetz oder BYOIP IPv6 hinzu. Die 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. Sie enthält acht Gruppen mit 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 dann gefolgt von einem Schrägstrich und einer Zahl von 1 bis 128. Beispiel: 2001:db8:1234:1a00::/64.
• Aktualisieren Sie Ihre Routingtabellen, 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 weiterleitet.
• Aktualisieren Sie Ihre Sicherheitsgruppenregeln so, dass Regeln für IPv6-Adressen eingeschlossen werden. Dadurch kann IPv6-Datenverkehr zu und von Ihren Instanzen fließen. Wenn Sie über Regeln für Netzwerksicherheitsgruppen 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 den dualen Stapel, oder stellen Sie ein NVA bereit, wie zuvor beschrieben, das von IPv4 in IPv6 übersetzt wird.

Tools für die IP-Adressverwaltung (IPAM)

Die Verwendung eines IPAM-Tools kann Sie bei der IP-Adressplanung in Azure unterstützen, da es eine zentrale Verwaltung und Transparenz 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:

Abhängig von Ihren Anforderungen und der Größe Ihrer Organisation stehen Ihnen zahlreiche IPAM-Tools zur Verfügung. Die Optionen reichen von einem grundlegenden Excel-basierten Inventar über eine Community-gesteuerte Open-Source-Lösung bis hin zu umfassenden Unternehmensprodukten mit erweiterten Features und Support.

• Berücksichtigen Sie die folgenden Faktoren, wenn Sie bewerten, welches IPAM-Tool implementiert werden soll:

  • Mindestfeatures, die für Ihre Organisation erforderlich sind
  • Gesamtkosten (Total Cost of Ownership, TCO), einschließlich Lizenzierung und laufender Wartung
  • Überwachungspfade, Protokollierung und rollenbasierte Zugriffssteuerungen
  • Authentifizierung und Autorisierung über Microsoft Entra ID
  • Zugriff über die API
  • Integrationen mit anderen Netzwerkverwaltungstools und -systemen
  • Aktiver Communitysupport oder die Supportebene des Softwareanbieters

• 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 Ihnen die Verwaltung über eine zentrale Benutzeroberfläche oder über eine RESTful-API.

• 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-Adressräume für Anwendungsteams ohne Abhängigkeiten und Engpässe zu optimieren.

• Ein wichtiger Teil der IPAM-Toolfunktionalität besteht darin, die IP-Adressraumnutzung zu inventarisieren und sie logisch zu organisieren.

Entwurfsempfehlungen:

• Der Prozess der Reservierung nicht überlappender IP-Adressräume sollte das Anfordern unterschiedlicher Größen basierend auf den Anforderungen der einzelnen Anwendungszielzonen unterstützen.

  • Beispielsweise können Sie das T-Shirt-Größensystem übernehmen, um anwendungsorientierten Teams die Beschreibung ihrer Anforderungen zu erleichtern:
    • 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 IaC-Ansatz (Infrastructure as Code) zu unterstützen. Dieses Feature ist auch entscheidend für die nahtlose Integration von IPAM in Ihren Abonnementverkauf Prozess, wodurch das Risiko von Fehlern und die Notwendigkeit eines manuellen Eingriffs verringert werden.

  • Ein Beispiel für einen IaC-Ansatz ist Bicep mit seiner Bereitstellungsskriptfunktion oder Terraform-Datenquellen zum dynamischen Abrufen von Daten aus der IPAM-API.

• Erstellen Sie eine systematische Anordnung für Ihre IP-Adressräume, indem Sie sie nach Azure-Regionen und Workload-Archetypen strukturieren, um eine sauber und nachverfolgbare Netzwerkinventur sicherzustellen.

• Der Außerbetriebnahmeprozess für Workloads sollte das Entfernen nicht mehr verwendeter IP-Adressräume umfassen, die später für anstehende neue Workloads neu verwendet werden können, um eine effiziente Ressourcennutzung zu fördern.