Wie in jeder anderen Public Cloud gibt es auch in Azure verschiedene Typen von IP-Adressen, nämlich öffentliche und private. Zudem können beide je nach SKU (Basic, Standard) unterschiedliche Verfahren für die Zuweisung verwenden (statisch, dynamisch) und stehen in zwei separaten Stacks (IPv4, IPv6) zur Verfügung.
Private IP-Adressen werden in einem virtuellen Azure-Netzwerk oder in Ihrem lokalen Netzwerk benutzt, sobald Sie ein VPN-Gateway oder eine ExpressRoute-Verbindung nutzen, um das private Netzwerk nach Azure zu erweitern.
Öffentliche IP-Adressen benötigen Sie für die Kommunikation mit dem Internet, einschließlich der von außen zugänglicher Azure-Dienste, weil nur sie geroutet werden. Die zulässigen Adressebereiche für private IP-Adressen sind im RFC 1918 geregelt.
Notwendigkeit zum Einsatz statischer IPs
IP-Adressen können statisch oder dynamisch zugewiesen werden. Statische IP-Adressen ändern sich nicht. Sie braucht man eigentlich nur in folgenden Situationen:
- DNS-Namensauflösung, bei der eine Änderung der IP-Adresse die Aktualisierung der Hosteinträge erfordern würde.
- SSL-Zertifikate, die mit einer IP-Adresse verknüpft sind.
- Firewall-Regeln, die Datenverkehr mithilfe von IP-Adressbereichen zulassen oder verweigern.
- Auf IP-Adressen basierende Sicherheitsmodelle, für die Apps oder Dienste eine bestimmte IP-Adresse benötigen.
- Rollenbasierte VMs wie Domänen-Controller und DNS-Server.
Verwendung dynamischer Adressen
Dynamische Adressen werden erst zugewiesen, nachdem eine Azure-Ressource eine öffentliche IP-Adresse erhalten hat und zum ersten Mal startet. Diese können sich ändern, nachdem sie einer Ressource zugewiesen wurden, etwa wenn eine virtuelle Maschine gestoppt (freigegeben) und dann neu gestartet wird.
Die Adresse bleibt hingegen gleich, wenn eine virtuelle Maschine neu gestartet oder gestoppt wird, dabei jedoch nicht freigegeben wird. Dynamische Adressen werden freigegeben, wenn eine öffentliche IP-Adresse von der Ressource getrennt wird, der sie zugeordnet ist.
Statische Adressen werden direkt zugewiesen, wenn eine öffentliche IP-Adresse erstellt wird und solange nicht freigegeben, bis Sie sie löschen. Ist die Adresse keiner Ressource zugeordnet, so können Sie die Zuweisungsmethode ändern, nachdem die Adresse erstellt wurde.
Private IP-Adressen
Wie ich in meinem Artikel zur Azure Firewall bereits beschrieben habe, erhält jede Azure-VM bei ihrer Erstellung eine private IP-Adresse aus dem Adressbereich des betreffenden Subnetzes. Die Zuweisungsart lässt sich zwar wahlweise auf statisch oder dynamisch setzen, aber wenn die VM über den Azure Ressource Manager (ARM) bereitgestellt wird, was mittlerweile der Standard ist, ändert das nichts am Verhalten.
Egal ob die private IP-Adresse dynamisch oder statisch ist, sie bleibt der VM bis zum Löschen der Ressource zugewiesen. Beim Wechsel zur statischen Methode haben Sie die Möglichkeit, die vorgeschlagene bzw. bis dato dynamische IP-Adresse zu übernehmen oder eine andere gültige IP-Adresse aus dem Adressbereiches des Subnetzes zu wählen.
Daher ist es in der Cloud immer wichtig, dass die Sie die gewünschten Adressbereiche vorher sorgfältig auf Subnetz-Ebene planen.
Was allerdings nicht geht, ist das Reservieren einer privaten IP-Adresse aus dem Subnetz für eine VM, die noch gar nicht existiert. Die private IP-Adresse sehen Sie dann auch in der IP-Konfiguration innerhalb des Gastsystems, wofür Azure stets mit DHCP verwendet. Dabei ist allerdings kein DNS-Server eingetragen, weil die VM normalerweise erstmal keiner Domäne beitritt.
Öffentliche IP-Adressen
Folgende Tabelle aus der Azure-Dokumentation enthält die Eigenschaft einer öffentlichen IP-Adresse, die sich einer Ressource zuordnen lässt sowie die Zuordnungsmethoden, wobei öffentlicher IPv6-Support zurzeit noch nicht für alle Ressourcentypen verfügbar ist.
| Ressource oberste Ebene | Zuordnung der IP | Dyn. IPv4 | Stat. IPv4 | Dyn. IPv6 | Stat. IPv6 |
|---|---|---|---|---|---|
| Virtueller Computer | Netzwerkschnittstelle | Ja | Ja | Ja | Ja |
| Öffentlicher Lastenausgleich | Front-End-Konfiguration | Ja | Ja | Ja | Ja |
| Gateway für virtuelle Netzwerke (VPN) | Gateway-IP-Konfiguration | Ja (nur Nicht-AZ) | Ja | Nein | Nein |
| Gateway für virtuelle Netzwerke (ER) | Gateway-IP-Konfiguration | Ja | Nein | Ja (Preview) | Nein |
| NAT Gateway | Gateway-IP-Konfiguration | Nein | Ja | Nein | Nein |
| Anwendungs-Gateway | Front-End-Konfiguration | Ja (nur V1) | Ja (nur V2) | Nein | Nein |
| Azure Firewall | Front-End-Konfiguration | Nein | Ja | Nein | Nein |
| Bastion Host | Konfiguration der öffentlichen IP-Adresse | Nein | Ja | Nein | Nein |
| RouteServer | Front-End-Konfiguration | Nein | Ja | Nein | Nein |
Die Auswahl der SKU für die öffentliche IP-Adresse wirkt sich direkt auf die Zuweisungsmethode, die Sicherheit, die verfügbaren Ressourcen und die Redundanz aus. Bei einer öffentlichen IP-Adresse vom Typ Standard ist die Zuweisung beispielsweise immer statisch.
Die SKUs Standard und Basic unterscheiden sich nicht nur bei der Zuweisungsmethode. Auch in puncto Sicherheit ist die Standard-SKU oft die bessere Wahl.
Microsoft konzipiert nämlich die Standard-SKU nach dem Prinzip standardmäßig sicher, das heißt, sie ist bei Verwendung als Frontend für eingehenden Datenverkehr gesperrt (etwa wenn angehängt an die NIC einer virtuellen Maschine). Daher benötigen Sie zwingend eine Netzwerksicherheitsgruppe (NSG), um den gewünschten Traffic zuzulassen.
Eine öffentliche IP-Adresse mit Basic-SKU ist standardmäßig geöffnet. Hier ist das Verwenden von Netzwerksicherheitsgruppen dringend empfohlen, wenngleich sie zum Einschränken des ein- oder ausgehenden Datenverkehrs optional sind.
Standardzugriff in ausgehender Richtung für Azure-VMs
Und noch ein letztes Missverständnis, mit dem ich gern aufräumen möchte: Ich habe in meinem Artikel zu Azure Firewall bereits erläutert, dass jede Azure-VM per Voreinstellung ausgehenden Internet-Zugriff hat.
Das liegt einerseits an den Default-Routen (bei Azure System-Routen genannt), die jedem Subnet eines Azure-VNets eine Route zum impliziten Standard-Gateway jedes Netzwerks (xxx.xxx.xxx.1) zuordnen.
Zudem enthalten die Standard-Paketfilter, bei Azure Network Security Group (NSGs) genannt, in ausgehender Richtung stets eine Regel, die Internet-Kommunikation erlaubt. Dank Stateful Inspektion kann dann jede Azure-VM beispielsweise OS-Updates abholen, ohne dass Sie dazu eine eingehende Regel schreiben müssen.
Dazu braucht die VM natürlich eine öffentliche IP-Adresse oder muss per NAT in der Lage sein, eine Route ins Internet zu finden. Versucht man allerdings versehentlich oder mit Absicht, bei einer Azure-VM, die ausschließlich über eine private IP-Adresse verfügt, das Internet zu erreichen, scheint dies trotzdem zu funktionieren. Was ist da los? Ist hier etwa ein verstecktes NAT-Gateway im Spiel? Nein.
Wenngleich Microsoft selbst empfiehlt, einer VM, die Internet-Konnektivität benötigt, entweder explizit eine öffentliche IP-Adresse zuzuweisen oder NAT zu spendieren (zum Beispiel über eine eingehende NAT-Regel eines Azure Load Balancers bzw. der Azure Firewall oder unter Zuhilfenahme des Azure PaaS-Dienstes NAT-Gateway), scheint eine Azure-VM über eine Art versteckte öffentliche IP-Adresse zu verfügen. Und genau das ist des Rätsels Lösung.