Häufige Fehlerursachen mit Azure Private Endpoints, Private Link Service & private DNS-Zonen
Damit die Fehlersuche für deine Azure Infrastruktur etwas einfacher ausfällt, habe ich im folgenden Beitrag die häufigsten Fehler mit privaten Endpunkten, dem Private Link Service und privaten DNS-Zonen zusammengefasst.
Einführung
Im Alltag von Azure Cloud Engineers treten häufig unerwartete Probleme mit einzelnen Azure-Diensten oder deren Konnektivität auf. In diesem Beitrag habe ich für die Verwendung von private Endpoints, dem Private Link Service und privaten DNS-Zonen Fehlerursachen herausgesucht, die nicht immer eindeutig erkennbar sind.
Private DNS Einträge
In einem VNet können verschiedenste Ressourcen wie virtuelle Maschinen, Container Apps oder per Private Endpoint eingebundene Dienste (bspw. Azure App Services, Storage Accounts, Key Vaults) betrieben werden. Für die Namensauflösung innerhalb des VNets werden Azure Private DNS-Zonen verwendet, die FQDNs den jeweiligen privaten IP-Adressen zuordnen.
Gerade bei Terraform-Deployments kann es vorkommen, dass sich private IP-Adressen von Diensten ändern, die zugehörigen DNS-Einträge jedoch nicht automatisch aktualisiert werden. Dies führt zu Konnektivitätsproblemen, die oft schwer zu identifizieren sind. Auch wenn in der Regel die Anpassungen der Recordsets in den privaten DNS-Zonen ebenfalls in die Terraform-Skripte integriert werden, kann dieses Problem in Sonderfällen auftreten.
Beispiel-Szenario:
- Du bemerkst, dass ein Dienst im VNet nicht mehr erreichbar ist.
- Von einer anderen Ressource im selben VNet (bspw. einer Container App) führst du ping https://app-name.cas-env-suffix.region.azurecontainerapps.io aus.
- Der Befehl liefert dir die aktuell aufgelöste private IP-Adresse.
- Lösung: Vergleiche diese mit private IP-Adresse mit dem Recordset-Eintrag in der jeweiligen privaten DNS-Zone des Ziel-Dienstes.
Falls die privaten IP-Adressen nicht übereinstimmen, ist vermutlich der Recordset in der DNS-Zone veraltet und muss aktualisiert werden.
Nicht funktionierende Private Endpoints
Private Endpoints sind eine elegante Möglichkeit, Azure-Dienste sicher und privat über eine direkte Verbindung in deinem VNet bereitzustellen. Doch wenn die Verbindung plötzlich nicht mehr funktioniert, beginnt oft die erfolglose Fehlersuche.
Typische Ursachen:
- Fehlende oder falsche DNS-Auflösung: Wie bereits im davorigen Kapitel spielt die Azure Private DNS-Zone eine zentrale Rolle. Wenn der zugehörige DNS-Eintrag nicht korrekt auf die private IP des Endpunkts und der dazugehörigen Netzwerkkarte zeigt (z. B. nach einem Re-Deployment), kann der Dienst nicht mehr erreicht werden.
- Fehlende Netzwerkrouten oder NSG-Regeln: Der Private Endpoint kann zwar erstellt sein, aber wenn Network Security Groups (NSGs) oder User Defined Routes (UDRs) den Traffic zum Private Endpoint Subnet blockieren, kommt es zu Timeouts oder abgelehnten Verbindungen.
- Nicht genehmigte Private Endpoint Verbindungen: In vielen Fällen muss eine Private Endpoint Verbindung im Azure Portal zunächst freigegeben werden bevor sie tatsächlich funktioniert. Ohne diese Freigabe bleibt der Endpoint im Status "Pending" und die Verbindung schlägt fehl.
- Subnetzprobleme oder IP-Adresskonflikte: Private Endpoints werden in ein dafür spezifisch delegiertes Subnetz deployt. Wenn das Subnetz des Private Endpoints zu klein ist und alle möglichen IP-Adressen bereits vergeben sind, kann die Zuweisung scheitern ohne klare Fehlermeldung.
Meine Empfehlung:
- Damit du nicht ständig ins Azure Portal zur Genehmigung von Private Endpoints dich einloggen musst, solltest du einen scheduled Job einrichten, der einen Auto-Approve Prozess etabliert.
- Beim initialen Deployment deines VNets sollte dein Private Endpoint Subnets relativ groß sein, da die Anzahl der Private Endpoints sehr stark steigen kann. Ein Beispiel dafür sind Azure Storage Accounts, die für jeden einzelnen Storage Type (Blob, File, Queue, Table) jeweils einen Private Endpoint anlegen.
- Für Private Endpoints entscheidet man sich bewusst, wenn Compliance Richtlinien diese erfordern. Falls du Kosten sparen möchtest und deine Cloud Security Anforderungen es ermöglichen, kannst du ebenso auf Service Endpoints umschwenken.
Dieses Problem kann auch der Grund dafür sein, dass dein Azure Dienst nicht über das Application Gateway erreichbar ist. Das Application Gateway löst den Dienst über die FQDN auf und wenn diese auf eine falsche private IP-Adresse verweist, kann der Dienst nicht aufgerufen werden.
Nicht funktionierende Endpunkte in FrontDoor
Azure Front Door ist ideal, um globale Webanwendungen mit hoher Verfügbarkeit und niedriger Latenz bereitzustellen. Doch auch hier können Probleme beim Aufrufen der jeweiligen FrontDoor Routen auftreten.
False Negatives bei Health Probes
Ein häufiges Problem sind Health Probes die fehlschlagen, obwohl der Endpunkt erreichbar ist. Das ist ein bekanntes Problem, dass durch Origin Groups hervorgerufen wird, die nur eine Origin besitzen. In diesem Fall empfiehlt Azure tatsächlich die Health Probe zu entwerfen, andernfalls musst du mit sporadischen False Negatives rechnen.
Zitat aus der Microsoft Dokumentation lautet wie folgt:
If there's only a single origin in your origin group, the single origin gets few health probes. This might lead to a dip in origin health metrics but your traffic doesn't get impacted.
Origin nicht erreichbar, trotz richtiger Konfiguration
Während ein Application Gateway in einem spezifischen VNet deployt wird, ist FrontDoor ein globaler Dienst. Aus diesem Grund kannst du als Origin nicht direkt die private IP-Adresse eines Dienstes in deinem VNet als Host eines Endpunktes eintragen. Damit musst du den Traffic aus FrontDoor entweder an öffentliche Endpunkte bspw. deines Storage Accounts, App Services oder Application Gateways weiterleiten oder den Private Link Service nutzen.
Falls du den Private Link Service nutzen möchtest, um direkt über den Azure Backbone deine Ressourcen aus deinem VNet in FrontDoor zu verwenden, musst du deine FrontDoor Instanz auf die Premium SKU upgraden. Damit kannst du den Private Link Service nutzen, der ähnlich wie Private Endpoints deine FrontDoor Instanz direkt über das Azure Backbone und verschlüsselt mit den einzelnen Diensten wie Storage Accounts, App Services und Key Vaults verbindet. Dabei wird nicht wie bei Private Endpoints eine virtuelle Netzwerkkarte mit einer statischen internen IP Adresse in deinem VNet deployt, sondern die jeweiligen Dienste werden direkt über den Azure Backbone miteinander verknüpft.
Beispiel-Szenario:
- Du hast eine Origin Group in FrontDoor korrekt konfiguriert, jedoch kannst du über die konfigurierte Domain, Sub-Path etc. nicht auf deinen Service zugreifen.
Aus dem Azure Portal ist leider oft nicht ersichtlich, was das eigentliche Problem ist und die Private Link Verbindungen scheinen soweit richtig eingerichtet zu sein.
Oftmals reicht es aus, die jeweilige Origin Group in der FrontDoor Instanz aufzurufen und die Private Link Erstellung zu wiederholen.
Das kannst du an folgender Stelle tun:
- Frontdoor Instanz auswählen.
- In der Side-Bar Origin Groups auswählen.
- Fehlerhafte Origin Group auswählen.
- Auf Origin Host-Name klicken.
- Enable Private Link Service deaktivieren.
- Die Änderungen mit Apply anwenden.
- Die Schritte wiederholen und Enable Private Link Service wieder aktivieren.
- Nach erfolgreicher Erstellung in der Azure Suche zum Private Link Center wechseln.
- In der Side-Bar Pending Connections auswählen
- Die Private Link Connection für unsere FrontDoor Origin bestätigen.
Mit diesem Vorgehen sollten sich Probleme mit App Services, Key Vaults und Storage Accounts in kurzer Zeit lösen lassen.
Seit kurzer Zeit gibt es auch die Möglichkeit für Container Apps den Private Link Service in Verbindung mit FrontDoor zu nutzen. Dabei kannst du die Schritte zuvor wiederholen, jedoch musst du zusätzlich einmal in das jeweilige Container App Environment der Container App springen und unter Networking die Private Link Verbindungen händisch bestätigen.
Meine Container App ist nicht erreichbar
Bei der Konfiguration von privaten DNS-Zonen für Azure Container Apps gibt es teilweise Abweichungen zu anderen Diensten wie Storage Accounts und App Services. Für einen Storage Account, der über private Endpoints in dein VNet integriert wurde, würdest du in der privaten DNS-Zone privatelink.blob.storage.azure.net für jeden Storage Account einen Recordset mit der jeweiligen IP der Netzwerkkarte des private Endpoints anlegen. Das Gleiche würde für App Services mit der privaten DNS-Zone privatelink.azurewebsites.net passieren.
Während Storage Accounts und App Services jeweils individuelle interne IP Adressen besitzen, ist im Fall von Container Apps die private DNS-Zone region-name.azurecontainerapps.io zu pflegen. Das Besondere dabei ist, dass nicht für jede einzelne Container App ein Recordset angelegt wird, sondern pro Container App Environment ein Recordset. Dabei ist die IP Adresse des internen Load Balancers des Container App Environments zu verwenden.
Als Name des Recordsets musst du ein Wildcard mit anschließender Erwähnung des Container App Environment Suffixes erstellen. Für app-name.suffix.region-name.azurecontainerapps.io würdest du als Name des Recordsets *.suffix einpflegen. Diese Werte sind dabei nur als Platzhalter und zur Erklärung gedacht. Die interne IP Adresse zum Referenzieren findest du in der Übersicht des jeweiligen Container App Environments.
Eine weitere Ursache für die fehlende Erreichbarkeit kann die falsche Ingress Einstellung in deiner Container App sein. Dazu musst du unter Networking > Ingress Ingress Traffic erlauben und kannst dann diesen auf dein Container App Environment oder VNet beschränken. Bitte schaue hier auch, ob der richtige Port deines Docker Containers exposed ist.
Fazit
Die Verwendung von Private Endpoints, Private Link Services und privaten DNS-Zonen bringt viele Vorteile im Hinblick auf Sicherheit und Compliance, erfordert jedoch auch ein gutes Verständnis für die zugrunde liegende Infrastruktur.
Häufige Fehlerquellen wie veraltete DNS-Einträge, fehlende Genehmigungen oder falsch konfigurierte Netzwerkrouten können die Konnektivität erheblich beeinträchtigen und sind oft nur schwer zu identifizieren.
Besonders bei automatisierten Deployments mit Terraform lohnt es sich, regelmäßig die DNS-Zonen und IP-Zuweisungen zu prüfen. Auch der gezielte Einsatz von Tools wie dem Private Link Center sowie das Einrichten von Auto-Approval-Prozessen kann den operativen Aufwand deutlich reduzieren.
Wer die beschriebenen Fallstricke kennt und systematisch vorgeht, kann die Vorteile privater Verbindungen in Azure voll ausschöpfen und das ohne dabei in typische Stolperfallen zu geraten.