Azure Fabric-Kommunikations-IP-Adressen

Azure Virtual Desktop-Sitzungshosts (AVD) und Windows 365 Cloud-PCs benötigen Konnektivität mit zwei Azure Plattform-IP-Adressen. Diese Adressen bieten Zugriff auf kerne Infrastrukturdienste, die Bereitstellung, Integritätsüberwachung, Identität und Plattformkommunikation unterstützen.

Der Datenverkehr zu diesen Adressen erfolgt auf Azure Plattformfabricebene. Es verhält sich anders als Datenverkehr zu FQDN-basierten Endpunkten und muss entsprechend behandelt werden.

In diesem Artikel wird erläutert, was diese IP-Adressen sind, warum sie wichtig sind, wie sie sich von anderen Endpunkten unterscheiden und wie Sie sicherstellen können, dass die Konnektivität erfolgreich ist.

Übersicht

Azure Virtual Desktop-Sitzungshosts und Windows 365 Cloud-PCs müssen mit den folgenden IP-Adressen verbunden sein:

Adresse	Protokoll	Ausgehender Port	Zweck	Diensttag
169.254.169.254	TCP	80	Azure Instance Metadata Service (IMDS)	Nicht zutreffend
168.63.129.16	TCP	80, 32526	Integritätsüberwachung des Sitzungshosts	Nicht zutreffend

Wichtig

Diese Adressen werden in allen Azure Regionen und Cloudumgebungen verwendet, einschließlich Azure öffentlichen Cloud, Azure Government und Azure China. Der Verlust der Konnektivität mit beiden Adressen führt zu Bereitstellungsfehlern, Integritätsberichtsproblemen und Dienstbeeinträchtigungen.

Azure Instance Metadata Service (169.254.169.254)

Azure Instance Metadata Service (IMDS) ist ein REST-API-Endpunkt, der Informationen zu einem ausgeführten virtuellen Computer bereitstellt. Software innerhalb des virtuellen Computers (VM) verwendet IMDS für die Integration in die Azure Umgebung.

VMs verwenden IMDS zum Abrufen von:

• VM-Identitäts- und Konfigurationsdaten

• Token für verwaltete Identitäten für die Authentifizierung bei Azure-Diensten

• Geplante Ereignisse und Wartungsbenachrichtigungen

• Metadaten wie Region, Verfügbarkeitszone, VM-Größe und Netzwerkkonfiguration

Die Adresse 169.254.169.254 ist eine link-lokale IP-Adresse. Es ist nicht routingfähig und nur innerhalb der VM zugänglich. Anforderungen an diese Adresse verlassen niemals den physischen Host. Der Azure Hypervisor fängt den Datenverkehr lokal ab und reagiert darauf.

IMDS arbeitet auf Hypervisorebene. Es ist nicht von Netzwerksicherheitsgruppen, benutzerdefinierten Routen oder Azure Firewall Regeln betroffen. Allerdings kann die Betriebssystemkonfiguration innerhalb der VM, z. B. Hostfirewalls oder VPN-Clients, den Zugriff blockieren.

Azure Überwachung der Plattformintegrität (168.63.129.16)

Die Adresse 168.63.129.16 ist eine virtuelle öffentliche IP-Adresse, die von Azure Plattformdiensten für die Kommunikation mit VMs verwendet wird. Diese Adresse wird auch als WireServer-Endpunkt bezeichnet.

VMs verwenden diese Adresse für:

• Integritätsüberwachung und Heartbeatkommunikation über den Azure-VM-Agent

• DNS-Auflösung bei Verwendung Azure bereitgestellten DNS

• DHCP-Kommunikation für Zuweisung und Verlängerung von IP-Adressen

Datenverkehr zu 168.63.129.16 durchläuft das Azure virtuellen Netzwerkfabric. Azure Plattformrouting wendet eine spezielle Behandlung an, um sicherzustellen, dass die Adresse in Netzwerken mit restriktiven Sicherheits- oder Routingkonfigurationen erreichbar bleibt.

Unterschiede zu Standardendpunkten

Azure Virtual Desktop und Windows 365 erfordern auch Verbindungen mit FQDN-basierten Endpunkten, wie z. B. Diensten auf Steuerungsebene, Microsoft Entra ID usw. Der Datenverkehr zu diesen Endpunkten verhält sich wie standardinterner Datenverkehr zu öffentlichen IP-Adressen. Ein Teil dieses Datenverkehrs wie RDP erfordert eine Optimierung in Kundennetzwerken, kann aber im Allgemeinen wie normale öffentliche Endpunkte behandelt werden.

Der Datenverkehr zu 169.254.169.254 und 168.63.129.16 verhält sich jedoch anders.

• Azure intern und nicht routingfähig. Diese Adressen sind Teil Azure internen Plattforminfrastruktur. Sie sind keine Internetendpunkte, werden nicht über öffentliches DNS aufgelöst und können nicht von außerhalb Azure oder aus lokalen Netzwerken aufgerufen werden.

• Sie können nicht per Proxy gesendet werden, da Proxyserver diese Adressen nicht erreichen können. Versuche, diesen Datenverkehr über einen Proxy zu senden, sind nicht erfolgreich, sei es über PAC-Dateien, Gruppenrichtlinie oder Anwendungsproxyeinstellungen.

• Sie können keine VPN-Tunnel oder sichere Webgateways durchlaufen. VPN-Clients und sichere Webgateway-Agents, die im Modus "Vollständiger Tunnel" oder "Tunnelerzwingung" ausgeführt werden, erfassen den gesamten Datenverkehr von der VM. Wenn sie Datenverkehr zu diesen Adressen erfassen, schlägt die Konnektivität fehl, da die Adressen nicht über VPN-Tunnel oder Sicherheitsinfrastrukturen von Drittanbietern erreichbar sind.

• Teilweise geschützt durch Azure Plattformrouting. Azure Netzwerk umfasst Schutzfunktionen, um die Konnektivität mit diesen Adressen auf fabric-Ebene sicherzustellen. Standardrouten wie 0.0.0.0/0 und die meisten Netzwerksicherheitsgruppenregeln blockieren diesen Datenverkehr nicht. Diese Schutzmaßnahmen gelten jedoch nicht für die Konfiguration innerhalb des virtuellen Computers oder für explizite Netzwerkregeln, die auf diese Adressen oder deren Diensttags abzielen.

Es ist daher wichtig, dass Sie sicherstellen, dass die folgenden Konfigurationsprobleme in Ihrer Umgebung nicht vorhanden sind:

Probleme bei der VM-Konfiguration

Die meisten Konnektivitätsprobleme sind auf die Konfiguration innerhalb des virtuellen Computers und nicht auf Azure Konfiguration auf Netzwerkebene zurückzuführen.

VPN-Clients und sichere Webgateway-Agents

Organisationen stellen VPN-Clients oder sichere Webgateway-Agents auf Cloud-PCs und Sitzungshosts bereit, um Sicherheitsrichtlinien zu erzwingen. Beispiele hierfür sind Zscaler Internet Access, Microsoft Entra Internet Access, PaloAlto Global Protect usw.

Wenn diese Agents im Tunnelerzwingungsmodus ausgeführt werden, leiten sie den gesamten Datenverkehr über einen virtuellen Adapter um. Diese Konfiguration kann Datenverkehr zu Azure Plattformadressen enthalten, wodurch die Konnektivität unterbrochen wird.

Zu überprüfende Elemente:

• Verwenden Sie geteiltes Tunneling, damit Azure Plattformdatenverkehr lokal bleibt.

• Konfigurieren expliziter Umgehungs- oder Ausschlussregeln für 169.254.169.254 und 168.63.129.16

Proxy- und PAC-Konfiguration

Proxyeinstellungen, die über PAC-Dateien, Gruppenrichtlinie, WinHTTP, WinINET oder anwendungsspezifische Einstellungen angewendet werden, können dazu führen, dass der virtuelle Computer Azure Plattformdatenverkehr proxyt.

Zu überprüfende Elemente:

• PAC-Dateien geben eine direkte Verbindung für diese Adressen zurück.

• Proxyumgehungslisten enthalten beide Adressen

• Proxyeinstellungen auf Benutzer- und Computerebene werden überprüft.

Hostfirewallregeln

Hostbasierte Firewalls oder Endpoint Protection-Software können ausgehenden TCP-Datenverkehr blockieren.

Zu überprüfende Elemente:

• Zulassen von ausgehendem TCP-Datenverkehr bis 169.254.169.254 an Port 80

• Zulassen von ausgehendem TCP-Datenverkehr bis 168.63.129.16 an den Ports 80 und 32526

Endpunktsicherheits- und Netzwerkfiltersoftware

Antiviren-, Endpunkterkennungs- &-Antworttools (EDR) oder DLP-Tools (Data Loss Prevention, Verhinderung von Datenverlust) können Netzwerküberprüfungsfeatures enthalten.

Zu überprüfende Elemente:

• Stellen Sie sicher, dass diese Tools den Datenverkehr zu diesen Adressen nicht blockieren oder überprüfen.

• Hinzufügen von IP-basierten Zulassungs- oder Ausschlussregeln bei Bedarf

---

Azure Probleme bei der Konfiguration auf Netzwerkebene

Netzwerksicherheitsgruppen

Azure definiert Diensttags für diese Endpunkte:

• AzurePlatformIMDS für 169.254.169.254

• AzurePlatformDNS für 168.63.129.16

Explizite Ablehnungsregeln für diese Diensttags können die Konnektivität beeinträchtigen.

Zu überprüfende Elemente:

• Entfernen von Ablehnungsregeln für diese Diensttags oder -adressen

• Stellen Sie sicher, dass restriktive Alle-Ausgangsregeln explizite Zulassungsregeln für diese Diensttags enthalten.

Benutzerdefinierte Routen und virtuelle Netzwerkgeräte

Azure Plattformrouting stellt normalerweise die Erreichbarkeit unabhängig von standardrouten sicher. Explizite Routen oder komplexe Routingtopologien können jedoch Probleme verursachen.

Zu überprüfende Elemente:

• Keine Routen explizit als Ziel 169.254.169.254 oder 168.63.129.16

• Firewalls oder virtuelle Netzwerkgeräte im Pfad lassen ausgehenden Datenverkehr zu diesen Adressen und Ports zu.

Integritätsprüfungen der Azure-Netzwerkverbindung

Windows 365 Enterprise verwendet Azure-Netzwerkverbindungen, um Cloud-PCs bereitzustellen. Jede Verbindung umfasst automatisierte Integritätsprüfungen, die die Netzwerkkonnektivität überprüfen.

Überprüfen von Integritätsprüfungen

• Netzwerkfabrickonnektivität mit Azure Plattformendpunkten

• Konfiguration der Netzwerksicherheitsgruppe

• Routingtabellenkonfiguration

• DNS-Auflösung mit Azure bereitgestellten DNS

Was Integritätsprüfungen nicht überprüfen

• VPN-Clients oder sichere Webgateway-Agents, die nach der Bereitstellung installiert werden

• Proxy- oder PAC-Konfiguration, die über Gruppenrichtlinie oder Intune angewendet wird

• Hostfirewallregeln oder Endpunktsicherheitssoftware

• Konfiguration, die nach der Zuweisung innerhalb des virtuellen Computers angewendet wird

Eine bestandene Integritätsprüfung bestätigt, dass das Azure Netzwerk Plattformdatenverkehr zulässt. Es wird nicht garantiert, dass Cloud-PCs oder Sitzungshosts diese Endpunkte erreichen können, nachdem die Konfiguration in der VM angewendet wurde.

Zusammenfassung

Konnektivität mit 169.254.169.254 und 168.63.129.16 ist für Azure Virtual Desktop und Windows 365 erforderlich. Das Blockieren dieser Endpunkte führt zu Bereitstellungs- und Betriebsproblemen bei Windows 365 und Azure Virtual Desktop.

Diese Adressen sind Azure interne Plattformendpunkte. Datenverkehr zu diesen Adressen darf nicht per Proxy übertragen, abgefangen oder über VPN-Tunnel oder sichere Webgateways weitergeleitet werden.

Die meisten Konnektivitätsfehler sind auf die Konfiguration innerhalb des virtuellen Computers zurückzuführen, z. B. VPN-Clients, Proxyeinstellungen, Hostfirewalls oder Endpunktsicherheitssoftware. Probleme auf Netzwerkebene sind weniger häufig, können aber auftreten, wenn explizite Regeln auf diese Adressen oder deren Diensttags abzielen.

Azure Integritätsprüfungen der Netzwerkverbindung überprüfen nur die Konnektivität auf Netzwerkebene. Es werden keine Vm-Konfigurationsprobleme erkannt.