Wenn Azure Files trotz Private Endpoint öffentlich aufgelöst wird

Unter Admins gibt es einen alten Witz: Es ist immer DNS.

Diesmal war es auch DNS. Nur nicht das DNS, das ich mir angeschaut habe.

Als ich beschlossen habe, mehr zu schreiben, habe ich versprochen, genau die Momente zu teilen, in denen es heißt: „Das müsste funktionieren, tut es aber nicht.“ Das hier ist einer davon.

Die Zielarchitektur

Wir bauen immer mehr unserer Umgebungen mit Azure Virtual Desktop (AVD) wirklich Cloud-native auf. Die Zielarchitektur ist einfach:

• Microsoft Entra joined Session-Hosts
• Microsoft Entra Kerberos für den Zugriff auf die Profilfreigabe
• Azure Files für die FSLogix-Profilcontainer
• Private Endpoints, der öffentliche Netzwerkzugriff auf dem Storage Account ist deaktiviert
• Managed Identity
• keine Abhängigkeit der Session-Hosts von einem klassischen Active Directory

Und natürlich alles mit Terraform bereitgestellt.

Die Infrastruktur stand, also war ich bei der Konfiguration von FSLogix angekommen.

Alles sah korrekt aus

Ich bin die übliche Liste durchgegangen, in Azure und in Intune:

1. Der Private Endpoint für den Storage Account existierte.
2. Die Private DNS Zone für Azure Files, privatelink.file.core.windows.net, war konfiguriert.
3. Der A-Record zeigte auf die private IP des Endpoints.
4. Die Zone war mit dem VNet der Session-Hosts verknüpft.
5. Das Konfigurationsprofil für FSLogix war sauber über Intune verteilt.

Alles grün.

ABER: FSLogix erreichte Azure Files nicht über SMB auf Port 445.

Noch verwirrender: Wenn der Session-Host den Namen des Storage Accounts aufgelöst hat, kam eine öffentliche Microsoft-IP zurück statt der Adresse des Private Endpoints.

Auf den ersten Blick sah das nach einem Problem mit Private DNS aus, oder nach einem anderen Netzwerkproblem.

War es nicht.

Was tatsächlich passiert ist

Um das Problem zu verstehen, hilft ein Blick darauf, wie die Namensauflösung bei einem Private Endpoint funktioniert.

FSLogix verbindet sich mit dem normalen Namen des Storage Accounts, \\<account>.file.core.windows.net\<share>. Den privatelink-Namen verwendet es nie direkt. Sobald ein Private Endpoint existiert, liefert das öffentliche DNS für diesen Namen einen CNAME auf <account>.privatelink.file.core.windows.net. Was danach passiert, hängt davon ab, wer antwortet:

• Azure DNS in einem VNet, das mit der privaten Zone verknüpft ist, antwortet mit der privaten IP des Endpoints.
• Jeder andere Resolver antwortet mit der öffentlichen IP des Speicherdienstes.

Das Ergebnis hängt also nicht allein von der Konfiguration in Azure ab. Es hängt davon ab, welchen Resolver der Session-Host tatsächlich fragt.

Bei uns war die Antwort der Zscaler-Client auf dem Session-Host. Zscaler hat DNS und Netzwerkverkehr so verändert, dass der erwartete Weg über Azure Private DNS umgangen wurde. Statt über privatelink.file.core.windows.net auf den Private Endpoint wurde der Name des Storage Accounts weiter auf den öffentlichen Microsoft-Endpoint aufgelöst. Und weil der öffentliche Netzwerkzugriff auf dem Storage Account deaktiviert war, ist die Verbindung natürlich gescheitert. Genau so, wie der Storage Account konfiguriert war.

Aus Sicht von Azure war nichts kaputt. Der Verkehr hat nur nie den Weg genommen, den Azure erwartet hat.

So prüfen Sie es auf dem Session-Host

Wer in derselben Situation landet, bekommt mit ein paar Befehlen auf dem Session-Host in einer Minute viel Klarheit:

# Was bekommt der Session-Host tatsächlich?
Resolve-DnsName <account>.file.core.windows.net

# Was antwortet Azure DNS, wenn man direkt fragt?
Resolve-DnsName <account>.file.core.windows.net -Server 168.63.129.16

# Erreicht SMB den Storage Account?
Test-NetConnection <account>.file.core.windows.net -Port 445

# Welche DNS-Server nutzt Windows, und leiten Regeln bestimmte Namen um?
Get-DnsClientServerAddress
Get-DnsClientNrptPolicy

Sehen möchten Sie den CNAME auf <account>.privatelink.file.core.windows.net und am Ende der Kette die private IP Ihres Endpoints.

• Die erste Abfrage liefert eine öffentliche IP, die zweite die private. Azure Private DNS ist in Ordnung. Die Frage ist, wen der Host stattdessen fragt: einen eigenen DNS-Server, der auf dem VNet eingetragen ist, oder einen Agenten auf dem Host selbst.
• Beide liefern eine öffentliche IP. Prüfen Sie zuerst die Azure-Seite: den VNet-Link, den Record und die DNS-Server, die auf dem VNet eingetragen sind. Ist dort alles korrekt, vergleichen Sie mit einem Session-Host, auf dem der Agent nicht läuft.
• DNS stimmt, aber Port 445 scheitert trotzdem. Dann ist der Netzwerkpfad dran: Netzwerksicherheitsgruppen, Routing und auch hier jeder Agent, der Verkehr tunnelt.

Die Lösung

Nachdem die passenden Zscaler-Ausnahmen gesetzt waren, wurde der Name sofort auf die IP des Private Endpoints aufgelöst, und TCP 445 funktionierte wie erwartet. FSLogix war zufrieden, und ich auch.

Welche Ausnahmen Sie brauchen, hängt davon ab, wie Zscaler bei Ihnen eingerichtet ist. Eine Liste, die für alle passt, gibt es nicht. Das Ziel ist aber überall dasselbe:

• DNS-Anfragen für den Storage Account werden innerhalb des VNet beantwortet, damit die privatelink-Zone ihre Arbeit machen kann.
• Verkehr zum Private Endpoint bleibt auf dem privaten Weg und wird nicht woandershin geschickt.

Sprechen Sie früh mit den Verantwortlichen für Zscaler. Oft ist das ein anderes Team als das, das AVD aufbaut, und dieses Gespräch kann länger dauern als die eigentliche Konfiguration.

Was ich daraus mitnehme

Wenn Private Endpoint und Private DNS korrekt aussehen, der Client aber trotzdem einen öffentlichen Endpoint auflöst, gehen Sie nicht davon aus, dass Azure DNS kaputt ist. Prüfen Sie das Endgerät selbst, in diesem Fall den Session-Host. Zscaler, VPN-Clients, DNS-Filter und andere Security-Agenten können den tatsächlichen DNS- und Netzwerkpfad komplett verändern.

Bei Cloud-native AVD übersieht man das leicht, weil ein Session-Host nicht nur eine VM in einem Subnetz ist. Er ist auch ein verwaltetes Endgerät und kann dieselben Security-Agenten tragen wie jedes andere Endgerät. Deshalb gehört er auf die Checkliste: Bevor Sie Private DNS verdächtigen, prüfen Sie, was auf dem Session-Host läuft und wie es mit DNS umgeht.

Manchmal ist die Cloud-Konfiguration korrekt. Das Problem ist, was mit dem Verkehr passiert, bevor er sie überhaupt erreicht.

Hoffentlich spart das jemandem ein paar Stunden Fehlersuche. Fragen? Schreiben Sie mir einfach eine Nachricht auf LinkedIn.