Private IP-Adressen in Azure verwenden

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.

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

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.

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.