Eine private Container Apps-App über Point-to-Site-VPN erreichen

Eine interne Container Apps-Umgebung braucht einen privaten Eingang, einen passenden Hostnamen und einen Resolver, den das VPN erreichen kann. Führen Sie jeden Schritt aus und prüfen Sie dann die Ablehnung.

Dieses Runbook behandelt eine Container Apps-Umgebung mit Workload-Profilen und einem internen Einstiegspunkt im virtuellen Netzwerk, der von einem Laptop über ein genehmigtes Point-to-Site-VPN erreicht wird, wobei der direkte FQDN der App verwendet wird und keine HTTP-Routen auf Umgebungsebene existieren. der Umgebungseingang ist vom Client aus erreichbar, der Ingress-Bereich der App lässt den Aufrufer zu, und der Hostname wird auf den privaten Eingang aufgelöst. Jeder Schritt unten hinterlässt ein überprüfbares Ergebnis und ein Rollback, das nichts berührt, was Sie nicht geändert haben. Arbeiten Sie sie in der angegebenen Reihenfolge ab, denn kein späterer Schritt kann eine im Schritt 1 falsch getroffene Bereichsentscheidung ausgleichen.

Bevor Sie DNS anfassen, klären Sie das Wort intern. Es wird in diesem Produkt für zwei verschiedene Bereiche verwendet, und ihre Verwechslung ist der häufigste Grund, warum ein funktionierender Name trotzdem nichts Nützliches zurückgibt.

Schritt 1: Umgebungs- und App-Bereich festlegen

Lesen Sie die Ingress-Konfiguration der App, bevor Sie einen Eintrag ändern:

SettingBoundary
Internal environmentThe environment entry is reached through its private network arrangement
App with internal ingressCallers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately
App with external ingress in an internal environmentThe app accepts outside traffic through the environment's private entry

Interner Ingress wird am internen Load Balancer der Umgebung innerhalb des VNet der Umgebung bereitgestellt, die Frage ist also nicht, ob der Laptop eine andere Container-App ist, sondern ob er dieses VNet erreichen kann. Ein VPN-Client mit einer Route in das VNet und der Standarddomäne der Umgebung, die über die private Zone aufgelöst wird, ist ein zulässiger Aufrufer, und genau das bauen die restlichen Schritte auf. Eine interne Umgebung ohne öffentlichen Eingang ist ein anderer Sachverhalt als eine App mit internem Ingress, und externer Ingress auf App-Ebene gibt der Umgebung keine öffentliche Tür. Schreiben Sie den Bereich sowohl ins Ticket als auch ins Portal, denn der nächste Ingenieur liest zuerst das Ticket.

Bestätigen Sie diesen Bereich mit dem Konfigurationseigentümer, bevor Sie fortfahren, und halten Sie das Tor eng: Wenn keine Route in das VNet der Umgebung existiert oder die Standarddomäne der Umgebung nicht über die private Zone aufgelöst wird, stoppen Sie und reparieren Sie zuerst diesen Pfad. Kein späterer Schritt kann einen Aufrufer ersetzen, der das VNet nicht erreichen oder den Namen nicht auflösen kann.

Schritt 2: den echten Hostnamen und die Eingangsadresse erfassen

Notieren Sie die Standarddomäne der Umgebung, ihre statische private Eingangsadresse und den konfigurierten FQDN der App, entnommen der Ressource und nicht einem alten Screenshot oder einer Wiki-Seite:

az containerapp env show -n ENV -g RG \
  --query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
  --query "properties.configuration.ingress.fqdn"

Die Anleitung zum privaten Eingang von Container Apps beschreibt, wie die Domäne der Umgebung mit ihrer internen Adresse abgeglichen wird, während die Hostnamen der Anwendung intakt bleiben. Genau diese Form bauen Sie hier von Hand, also gleichen Sie den Zoneninhalt daran an, statt ein neues Namensschema zu erfinden.

Wenn die gelesene Domäne nicht mit dem FQDN übereinstimmt, den die App meldet, stoppen Sie und gleichen Sie beide jetzt ab. Eine Zone auf dem falschen Suffix zu bauen erzeugt einen Hostnamen, der perfekt auflöst und trotzdem auf dem falschen virtuellen Host landet.

Schritt 3: die private Zone auf den Resolver-Pfad des VPN legen

Erstellen oder verwenden Sie die unterstützte private DNS-Zone für die tatsächliche Standarddomäne der Umgebung erneut, mit den dokumentierten Platzhalter- und Adresseinträgen, die auf den statischen Eingang zeigen. Verknüpfen Sie die Zone mit dem passenden virtuellen Netzwerk und machen Sie die private Autorität über den genehmigten Resolver-Pfad des VPN erreichbar, statt anzunehmen, dass die Verknüpfung ausreicht.

Ein Point-to-Site-Client braucht normalerweise einen eingehenden Endpunkt eines privaten Resolvers oder einen unterstützten DNS-Weiterleiter, um diese Zone zu erreichen. Eine Zone zu verknüpfen ändert, was Azure für verknüpfte Netzwerke auflöst; es leitet nicht den öffentlichen Resolver jedes externen Laptops um. Ersetzen Sie sie nicht durch eine DNS-Zone für private Endpunkte aus einem anderen Container Apps-Netzwerkmodell, denn die Eintragsnamen und das Zonensuffix passen nicht zusammen.

Das Rollback für diesen Schritt ist das Entfernen der Zonenverknüpfung oder des hinzugefügten Eintrags. Notieren Sie, welches von beidem es war, denn das Löschen einer gemeinsam genutzten Zone, um eine einzelne Verknüpfung rückgängig zu machen, ist ein bekannter Weg, eine zweite Umgebung zu beschädigen.

Schritt 4: den Namen und dann das abgelehnte Publikum testen

Testen Sie Hostname und TLS-Identität zusammen, nicht nur die Adresse. Für eine kontrollierte Namenszuordnungsdiagnose können Sie die Adresse festnageln und dabei den Hostnamen erhalten:

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

Ersetzen Sie den Hostnamen durch den echten FQDN der App und die Adresse durch den echten internen Eingang. Das betrifft nur diese eine Anforderung und ist keine DNS-Bereitstellung. Fügen Sie -k nicht hinzu, um einen Identitätsfehler in einen scheinbaren Erfolg zu verwandeln, denn eine Zertifikatsabweichung ist das Signal, dass Sie den falschen Listener treffen.

Die numerische Adresse direkt anzufordern kann den falschen virtuellen Host auswählen oder die Validierung fehlschlagen lassen, selbst während TCP 443 antwortet, daher behandeln Sie einen erfolgreichen IP-Test als Beleg über das Netzwerk und nichts weiter. Vom vorgesehenen Laptop ist der normale Resolver-Pfad der DNS-Weiterleiter des Clients oder der eingehende Endpunkt des privaten Resolvers, der die Zone hostet, und ein Fehler dort ist ein Erreichbarkeitsproblem des Resolvers, kein fehlender Eintrag. Bestätigen Sie, dass dieselbe Anforderung auf diesem Pfad erfolgreich ist, und bestätigen Sie dann, dass das abgelehnte Publikum weiterhin abgelehnt wird.

Was zu protokollieren und was zurückzurollen ist

Der Zielport des Containers und der HTTPS-Port des Clients sind getrennte Einstellungen. Veröffentlichen Sie den Zielport des Containers nicht über das VPN, weil der Container dort lauscht, und erweitern Sie keine Netzwerkregel, damit ein Porttest besteht. Beide Änderungen überleben den Vorfall und sind später schwer zuzuordnen.

Schließen Sie mit einer frischen Anwendungsoperation vom vorgesehenen Laptop ab, mit seiner autorisierten Identität und seinem normalen DNS, und prüfen Sie dann, dass ein nicht autorisierter Aufrufer weiterhin scheitert. Prüfen Sie, während Sie in der App-Konfiguration sind, auch, ob eine HTTP-Route auf Umgebungsebene diese App als Ziel bereitstellt, denn diese Route ist eine zweite Tür, die der Ingress-Bereich nicht beschreibt.

Notieren Sie fünf Werte zusammen: Umgebungsbereich, Ingress-Bereich der App, FQDN, private Eingangsadresse und Resolver-Eigentümer. Diese fünf beschreiben den gesamten Zugriffsvertrag, und die nächste Person, die ihn debuggt, wird genau danach fragen.

Ähnliche Artikel