Private IP-Adressen in Azure verwenden


    Tags: ,

    Azure Virtual NetworkAzure bietet öffentliche und private IP-Adressen, die jeweils dynamisch oder statisch sein können. Bei privaten IP-Adressen können Sie zwar den Bereich gemäß RFC 1819 und somit die Größe der virtuellen Netzwerke frei bestimmen. Einige Adressen stehen aber für Subnetze und VMs nicht zur Verfügung, weil Azure diese selbst beansprucht.

    Bei der Gestaltung der Adressbereiche für virtuelle Netzwerke in Azure haben Sie gemäß RFC 1918 großen Spielraum. Folgende Bereiche können Sie verwenden:

    • 10.0.0.0 – 10.255.255.255 (in CIDR-Notation 10/8-Präfix)
    • 172.16.0.0 – 172.31.255.255 (in CIDR-Notation 172.16/12-Präfix)
    • 192.168.0.0 – 192.168.255.255 (in CIDR-Noation: Präfix: 192.168/16)

    Außerdem können Sie den in RFC 6598 beschriebenen Adressraum 100.64.0.0 bis 100.127.255.255 (Präfix: 100.64/10) verwenden. Alle übrigen, inklusive der von IETF als privat anerkannten, nicht routingbaren Adressen könnten zwar funktionieren, führen aber möglicherweise zu unerwünschten Nebenwirkungen.

    Da sich die Subnetze üblicherweise an den Service-Anforderungen der Workloads ausrichten, brauchen Sie für solche, in denen Sie virtuelle Maschinen und PaaS-Dienste mit öffentlichen IP-Adressen platzieren, eher einen kleineren Adressraum, wie /25 oder kleiner.

    Bei privaten Subnetzen sollte /24 die absolute Untergrenze darstellen. Dort stehen dann theoretisch 256 Adressen (0 bis 255) zur Verfügung, praktisch aber 256  minus 5 (in Azure reservierte Adressen) = 251.

    Die virtuellen Netzwerke (vNets) hingegen müssen groß genug sein, um ausreichend Subnetze ohne Überschneidung aufnehmen zu können. Azure erstellt standardmäßig das erste virtuelle Netzwerk in jeder Region mit der Adresse 10.0.0.0 im CIDR-Bereich /16 mit 65536 Adressen zur Verfügung, das zweite mit 10.1.0.0/16 usw. Sie sollten daher ruhig bei /16 bleiben.

    Da es sich um private Adressbereiche handelt, können Sie auch in der gleichen Region problemlos 10.0.0.0 mehrfach verwenden. Allerdings sollten Sie das nicht tun. Vermeiden Sie Überschneidungen von Adressbereichen, wenn Sie vNets später einmal "peeren" möchten.

    Auch sollten Sie eine Überlappung mit on premise vermeiden, wenn Sie vorhaben, ihren lokalen Standort per VPN anzubinden.

    Dass die erste für virtuelle Hosts verfügbare Host-Adresse die xxx.xxx.xxx.4 ist, liegt daran, dass die folgenden fünf IP-Adressen reserviert sind:

    • xxx.xxx.xxx.0 - für die Netzwerk-Adresse
    • xxx.xxx.xxx.255 - für die Broadcast-Adresse
    • xxx.xxx.xxx.1 - für das Standard-Gateway des virtuellen Netzwerkes
    • xxx.xxx.xxx.2 und xxx.xxx.xxx.3 für den DNS-Dienste der Azure-Plattform

    Es gibt noch weitere IPv4-Adressbereiche und Einzeladressen, die Sie keinesfalls für Ihre vNets oder VMs verwenden dürfen. Das sind

    • 224.0.0.0/4 (Multicast)
    • 255.255.255.255/32 (Broadcast)
    • 127.0.0.0/8 (Loopback)
    • 169.254.0.0/16 (Link-local)
    • 168.63.129.16/32 (Internal DNS)

    Netzwerkplanung

    Bei der Planung der Subnetze ist etwas Vorsicht geboten, weil die Namen folgender spezieller Subnetze reserviert bzw. fest vorgegeben sind. Das sind:

    • GatewaySubnet:  reserviert für das Subnetz des Azure Gateways für virtuelle Netzwerke, ein VPN-Gateway als PaaS-Dienst in Azure. Dieses müssen Sie direkt über die zugehörige Schaltfläche +Gatewaysubnetz anlegen. Microsoft verwendet für dieses bei einem vNet-Bereich 10.xxx.xxx.xxx/16 per Default 10.xxx.1.0/24. Ich empfehle hierfür 10.xxx.0/26 zu verwenden.
    • AzureFirewallSubnet: für das Subnetz der Azure Firewall, wenn Sie diesen Plattform-Dienst in Azure verwenden. Dieses ist konzeptionell ein gewöhnliches Subnetz (im Gegensatz zum Gateway-Subnetz), muss aber exakt so heißen. Den Adressraum können Sie zwar selbst bestimmen, die Größe muss aber zwingend /26 oder größer sein (/25, /24 usw.).
    • AzureBastionSubnet: Wenn Sie den PaaS-Dienst Azure Bastion zum Bereitstellen eines verwalteten Bastion-Service verwenden, muss dieser in einem Subnet mit exakt diesem Namen platziert werden, das ebenfalls /26 oder größer sein muss.
    • ApplicatonGatewaySubnetz: Ein weiteres Spezial-Subnetz, welches Sie häufig benötigen werden, ist eines für Application Gateway. Hierbei handelt es sich um einen Plattformdienst, der einen Load-Balancer auf HTTP-Ebene bereitstellt. Sie sind hier völlig frei bei der Wahl der Subnetz-Bezeichnung und des Adressbereichs. Bedenken Sie, dass das Application Gateway automatisch skalieren kann und Sie für jede einzelne Gateway-Instanz eine IP-Adresse benötigen. Microsoft empfiehlt auch hier eine Mindest-Subnetzgröße von /26.

    In der Regel lege ich auch noch ein Subnetz für eine DMZ zur Mikrosegmentierung an, um bei Bedarf einen Router, ein VPN-Gateway und/oder eine Firewall-Lösung (in der Regel All-In-One) auf Basis einer virtuellen Maschine bereitstellen zu können. Hier kann es auch ein kleineres Subnetz /27 oder /28 sein, je nachdem, wie viele IP-Adressen Sie benötigen.

    Ich persönlich finde es nützlich, bei der Aufteilung des vNet-Adressraums vorne Platz für die Spezial-Subnetze frei zu lassen, egal ob Sie diese zu Anfang benötigen oder nicht. Besser Sie sehen diese Subnetze von vorneherein vor, als sich später in fragmentierten Adressbereichen zurechtfinden zu müssen.

    Außerdem ist es gut, sich eine Systematik anzugewöhnen, die für alle Netzwerke gleich ist. Bei einem angenommenen vNet-Adressraum von 10.0.0.0/16 beginne ich mit den gewöhnlichen Subnetzen stets erst bei 10.0.4.0/24. Ein praktikables Beispiel unter Berücksichtigung aller erwähnten Eventuali­täten könnte dann so aussehen:

    • GatewaySubnet: 10.0.0.0/26
    • AzureFirewallSubnet: 10.0.1.0/26
    • AzureBastionSubnet: 10.0.2.0/26
    • ApplicatonGatewaySubnetz: 10.0.3.0/26
    • DMZ-Subnet: 10.0.4.0/28
    • Frontend-Subnet: 10.0.5.0/25
    • Backend-Subnet1: 10.0.6.0/24
    • Backend-Subnet2: 10.0.7.0/24

    Im Azure-Portal sieht mein Planungsvorschlag so aus wie auf der folgenden Abbildung.

    Vorschlag für eine Subnetz-Segmentierung in einem Azure-vNet

    Azure Instance Metadata Service (Windows)

    Der Azure Instance Metadata Service (IMDS) stellt Informationen zu den Instanzen aller derzeit ausgeführten virtuellen Computer in Form einer REST-API zur Verfügung, die nur innerhalb der VM über die nicht routingfähigen IP-Adresse (169.254.169.254), auch APIPA oder Zeroconf genannt, abgerufen werden kann.

    Die Kommunikation zwischen der VM und dem IMDS verlässt niemals den Host. Daher müssen HTTP-Clients bei Abfragen von IMDS etwaige Web-Proxys innerhalb der VM umgehen (-NoProxy), 169.254.169.254 also gleich behandeln wie die unten erklärte Adresse 168.63.129.16. Per PowerShell lässt sich der IDMS beispielsweise wie folgt abfragen und das Ergebnis in JSON ausgeben:

    Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET  `
    -Uri http://169.254.169.254/metadata/instance?api-version=2021-02-01 |
    ConvertTo-Json -Depth 64

    Anfragen des IDMS aus einer Azure-VM

    Wozu dient die IP-Adresse 168.63.129.16?

    Die virtuelle öffentliche IP-Adresse 168.63.129.16 dürfen Sie keinesfalls verwenden. Sie wird als Kommunikationskanal zu Azure-Ressourcen genutzt. Da Kunden (nahezu) beliebige Adressräume für ihre privaten virtuellen Netzwerke verwenden können, müssen die Ressourcen der Azure-Plattform als eindeutige öffentliche IP-Adresse darstellbar sein.

    Diese virtuelle öffentliche IP-Adresse ermöglicht folgende Vorgänge auf der Azure-Plattform:

    • Kommunikation zwischen VM-Agent und Azure-Plattform, um anzuzeigen, dass der Agent im Zustand ready ist.
    • Kommunikation mit dem virtuellen DNS-Server zur Bereitstellung einer gefilterten Namensauflösung für Ressourcen wie Azure-VMs, welche keinen impliziten, benutzer­definierten DNS-Server verwenden. Dieser Filter garantiert, dass Kunden immer nur die Host-Namen ihrer eigenen Ressourcen auflösen können.
    • Die virtuelle IP-Adresse wird auch von den Integritätstests des Azure Load Balancers genutzt, um den Zustand der Backend-VMs zu ermitteln.
    • Der Kommunikationskanal ermöglicht das Abrufen einer dynamischen IP-Adresse vom DHCP-Dienst in Azure durch die VM.
    • Auch die Taktmeldungen für den Gastagenten bei PaaS-Rollen werden über diese Adresse ermöglicht.

    Benutzerdefinierten DNS-Server verwenden

    Da diese öffentliche IP-Adresse im Besitz von Microsoft ist, ändert sie sich nie und Sie sollten sie daher in etwaigen lokalen Firewall-Richtlinien (innerhalb der VM in ausgehender Richtung) stets zulassen.

    Sollte diese Adresse gesperrt sein, könnte es zu unerwartetem Verhalten kommen, da 168.63.129.16 eine virtuelle IP des Host-Knotens ist und daher von benutzerdefinierten Routen nicht umgangen wird.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet ist seit fast 30 Jahren selb­ständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehe­malige und aktuelle IT-Magazine sowie Blogs.

    Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.

    Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zerti­fi­zierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grund­lagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.

    Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Infor­mationen und Anmel­dung über sein Azure-Blog.

    Verwandte Beiträge

    Weitere Links

    1 Kommentar

    Wenn man eine NSG nutzt, so ist die Quell IP die öffentliche, aber die Ziel IP die interne (private) IP. Es hat einiges an Zeit und Nerven gekostet mit dem Support bis das klar war. Die Dokumentation, insb. der Hilfetext im Azure Portal ist irreführend, da für die Ziel IP eine public IPv6 als Beispiel angegeben wird.