Reservierte IP-Adressen in Azure

Kürzlich habe ich in diesem Artikel (Link) die verschiedenen Arten von IP-Adressen in Azure – Öffentliche und Private, welche jeweils dynamisch oder fix sein können – erklärt. Heute möchte ich noch mal näher auf private IP-Adressen eingehen. Da es sich um private IP-Adressen handelt, kannst du zwar durch Wahl der Adressbereich gemäß RFC 1819 die Größe deiner virtuellen Netzwerke und Subnetze weitgehend frei bestimmen, einige Adresse stehen aber für Subnetze und virtuelle Maschinen nicht zur Verfügung, weil Azure Diese für sich selbst reserviert.  

Passende Schulungen

AZ-104 Microsoft Azure Administrator (AZ-104T00)

AZ-104 Microsoft Azure Administrator (AZ-104T00): Azure Administration für Profis

AZ-305 – Designing Microsoft Azure Infrastructure Solutions (AZ-305T00)

Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!

Wie bereits im genannten Artikel erwähnt, hast du bei der Gestaltung der Adressbereiche deiner virtuellen Netzwerke in Azure gemäß https://www.rfc-editor.org/rfc/rfc1918 RFC 1918 großen Spielraum: Folgende Bereiche kannst du 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 kannst du den in https://www.rfc-editor.org/rfc/rfc6598 RFC 6598 beschriebenen Adressraum 100.64.0.0 bis 100.127.255.255 (Präfix: 100.64/10) verwenden. Alle übrigen Adressräume, inklusive der von IETF anerkannten privaten, nicht routingbaren Adressräumen, könnten zwar funktionieren, führen aber unter Umständen zu unerwünschten Nebenwirkungen.

Da es sich um private IP-Adressen handelt, musst du nicht nach der sonst üblichen Prämisse des Einsparens von IP-Adressen vorgehen. Sei eher großzügig, um jederzeit auf Szenarien vorbereitet zu sein, die du aktuell noch gar nicht auf dem Schirm hast. Da sich deine Subnetze üblicherweise an den Service-Anforderungen deiner Workloads ausrichten, brauchst du für „öffentliche“ Subnetze, also solche, in denen du auch virtuelle Maschinen und PaaS-Dienste mit öffentlichen IP-Adressen platzierst, eher einen kleineren Adressraum, wie /25 oder kleiner. Bei privaten Subnetzen sollte /24 die absolute Untergrenze darstellen. Dort stehen dir dann theoretisch 256 Adressen (0 bis 255) zur Verfügung, praktisch „256  minus 5 (in Azure reservierte Adressen) = 251“. Die virtuellen Netzwerke (vNets) hingegen müssen groß genug sein, um ausreichend Subnetze ohne Überschneidung (plane hierbei unbedingt großzügig) 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.. Du solltest daher ruhig bei /16 bleiben. 

Da es sich um private Adressebereiche handelt, kannst du auch in der gleichen Region problemlos 10.0.0.0 mehrfach verwenden, allerdings solltest du das nicht tun. Vermeide Überschneidungen von Adressebereichen, wenn du vNets später einmal „peeren“ möchtest. Auch solltest du die Überlappung mit on premise verwendeten Adressbereichen vermeiden, wenn du vorhast, deinen lokalen Standort per VPN anzubinden. Auch wenn du Adressbereiche von virtuellen Netzwerken nachträglich erweitern kannst, solltest du in jeden Fall sorgfältig und großzügig planen. Dass die erste für deine virtuellen Hosts verfügbare Host-Adresse die xxx.xxx.xxx.4 ist, habe ich in oben verlinkten Artikel ebenfalls bereits erwähnt. Das liegt daran, dass die 5 IP-Adressen …

Passende Schulungen

AZ-700 – Designing and Implementing Microsoft Azure Networking Solutions (AZ-700T00)

• 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

reserviert sind.

Allerdings gibt es noch weitere IPv4-Adresse-Bereiche und Einzeladressen, die du keinesfalls für deine Azure-vNets oder VMs verwenden darfst. 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

Auf den Adress-Bereich 169.254.0.0/16 und die spezifische öffentliche Host-Adresse 168.63.129.16/32 werde ich im Laufe des Beitrages noch spezifisch eingehen, weil beide eine besondere Bedeutung in Azure haben. Zunächst aber noch ein paar weitere Empfehlungen zum Design eines virtuellen Netzwerks. Verwende wie oben beschrieben z. B. den Adressbereich 10.0.0.0/16 für dein erstes virtuelles Netzwerk, zähle für jedes weitere virtuelle Netzwerk das zweite Oktett hoch. Bei der Planung der Subnetze ist etwas Vorsicht geboten, weil die Namen folgender „Spezial“-Subnetze reserviert, bzw. fest vorgegeben sind. Das sind:

GatewaySubnet: für das Subnetz des „Azure Gateways für virtuelle Netzwerke“, ein VPN-Gateway als PaaS-Dienst in Azure. Dieses musst du 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 du diesen Plattform-Dienst in Azure verwendest (Link). Dieses ist konzeptionell ein gewöhnliches Subnetz (im Gegensatz zum Gateway-Subnetz), muss aber exakt so heißen. Den Subnetz-Adressraum kannst du zwar selbst bestimmen, die Größe muss aber zwingend /26 oder größer sein (/25, /24 usw.). Bestandkunden konnten vor einigen Monaten noch /27 verwenden, für neu anzulegende Firewalls muss es aber /26 sein. Gleiches gilt für das …

AzureBastionSubnet: Wenn du den PaaS-Dienst „Azure Bastion“ zum Bereitstellen eines verwalteten Bastion-Service verwendest, muss dieser in einem Subnet mit exakt diesem Namen platziert werden, das ebenfalls /26 oder größer sein muss.

ApplicatonGatewaySubnetz: Ein weiteres typisches „Spezial“-Subnetz, welches du häufig benötigen wirst, ist das Subnetz für ein Application Gateway. Hierbei handelt es sich um einen Plattformdienst von Microsoft, der einen Anwendungs-Loadbalancer auf HTTP-Ebene bereitstellt. Im Gegensatz zu den anderen erwähnten Spezial-Subnetzen bist du hier völlig frei in der Subnetz-Bezeichnung und im Adressbereich. Bedenke hier, dass das Application Gateway automatisch skalieren kann und du für jede einzelne Gateway-Instanz eine IP-Adresse benötigst. Die Application Gateway-SKU „Standard“ unterstützt z. B. bis zu 32 Instanzen (32 Instanz-IP-Adressen + 1 private Front-End-IP-Konfiguration + 5 für Azure Reservierte). Das ist der Grund, warum Microsoft auch hier eine Mindest-Subnetzgröße von /26 empfiehlt.

Ferner wirst du in der Regel ein gewöhnliches öffentliches Subnetz benötigen und ein oder mehrere private. Ich selbst lege in der Regel 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, wie Sophos, Barracuda, Fortigate oder ähnliches. Hier kann es auch ein kleineres Subnetz /27 oder /28 sein, je nachdem, wie viele IP-Adressen du benötigst.

Ich persönlich finde es nützlich bei der Aufteilung deines vNet-Adressraums „vorne“ Platz für die Spezial-Subnetze frei zu lassen, egal ob du diese zu Anfang benötigst oder nicht. Besser du siehst diese Subnetze von vorneherein vor, als dich später in fragmentierten Adressbereichen zurecht finden zu müssen. Außerdem ist es gut, sich eine Systematik anzugewöhnen, die für alle Netzwerk gleich ist; dann musst du nie groß nachdenken. Unter der Berücksichtigung der „Spezial“-Subnetze beginne ich bei einem angenommenen vNet-Adressraum von 10.0.0.0/16 mit den „gewöhnlichen“ Subnetzen stets erst bei 10.0.4.0/24. Ein praktikables Beispiel unter Berücksichtigung aller erwähnten Eventualitä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 finaler Planungsvorschlag so aus:

Kommen wir abschließend zu den beiden oben erwähnten Spezial-Adressen:

Azure Instance Metadata Service (Windows)

Der Azure Instance Metadata Service (IMDS) stellt jederzeit Informationen zu den Instanzen aller derzeit ausgeführten virtueller 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 Webproxys innerhalb der VM umgehen (-NoProxy), 169.254.169.254 also gleich behandeln wie die unter erklärte Adresse 168.63.129.16. Per Powershell lässt sich der IDMS beispielsweise wie folgt abfragen:

Invoke-RestMethod -Headers @{“Metadata”=”true”} -Method GET  -Uri \ http://169.254.169.254/metadata/instance?api-version=2021-02-01

In JSON konvertiert sieht das ganze so aus

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

Wozu wird die IP-Adresse 168.63.129.16 verwendet?

Die öffentliche IP-Adresse 168.63.129.16 darfst du keinesfalls verwenden. Es handelt sich hierbei um eine virtuelle öffentliche IP-Adresse. Sie wird als Kommunikationskanal zu den Ressourcen der Azure-Plattform genutzt. Da Kunden wie beschrieben (nahezu) beliebige Adressräume für ihre privaten virtuellen Netzwerke verwenden können, müssen die Ressourcen der Azure-Plattform zwingend als eindeutige öffentliche IP-Adresse darstellbar sein.

Diese virtuelle öffentliche IP-Adresse ermöglich folgende Vorgänge in/mit 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 entsprechend gefilterten Namensauflösung für Ressourcen wie z. B. Azure-VMs, welche keinen impliziten, benutzerdefinierten DNS-Server verwenden. Dieser Filter garantiert, dass Kunden immer nur die Host-Namen ihrer eigenen Ressourcen auflösen können. Du kannst bekanntlich wahlweise für jedes Azure-vNet oder jede virtuelle Netzwerkkarte auch benutzerdefinierte DNS-Server angeben.

• Die virtuelle IP-Adresse wird auch von den Integritätstests des Azure Load Balancers verwendet, um den Integritätszustand der Backend-VMs zu ermitteln.
• Ferner ermöglichen der Kommunikationskanal das Abrufen einer dynamischen IP-Adresse vom DHCP-Dienst in Azure durch die VM.
• Auch die Taktmeldungen für den Gast-Agenten bei PaaS-Rollen wird über diese Adresse ermöglicht.

Da diese öffentliche IP-Adresse im Besitz von Microsoft ist, ändert sie sich nie und du solltst sie daher in etwaigen lokalen Firewall-Richtlinien (innerhalb der VM in ausgehender Richtung) stets zulassen. Sollte diese Adresse gesperrt sein, könnte es in verschiedenen Szenarien zu unerwartetem Verhalten kommen, da 168.63.129.16 eine virtuelle IP des Hostknotens ist und daher von benutzerdefinierten Routen nicht umgangen wird.