Wie eine Azure-Web-App über ein VPN eine lokale Umgebung erreicht

Die ausgehende Anfrage der Web-App hinterlässt einen Worker, den Sie nie sehen, von einer Quelle, die Sie nicht ausgewählt haben, und die Büro-Firewall muss sie akzeptieren. Das ist das ganze Problem in einem Satz. Durch die regionale VNet-Integration erhält die Anfrage einen Pfad in ein virtuelles Netzwerk, und das Site-to-Site-VPN überträgt sie von dort aus. Alles, was danach schief geht, hängt davon ab, welchen Quellbereich und welche Route das Paket tatsächlich verwendet hat.

Was der Worker tatsächlich sendet

App Service führt Ihren Code auf Workern aus, die sich außerhalb der Netzwerkansicht Ihres Abonnements befinden. Wenn die regionale Integration aktiviert ist, wird ausgehender Datenverkehr an ein delegiertes Subnetz in einem VNet in derselben Region übergeben und das Paket wird dort angezeigt, bevor es fortgesetzt wird. Durch die Integration wird die App nicht in das VNet verschoben und ihre eingehende Adresse wird nicht geändert. Es gibt ausgehenden Flüssen nur einen anderen ersten Hop.

Standardmäßig nimmt nur der private Adressraum diesen Pfad, sodass normale Internetziele immer noch direkt vom Worker ausgehen. Alles über das VNet weiterzuleiten ist eine separate Einstellung und eine separate Entscheidung, da dadurch auch Ihre öffentlichen Abhängigkeiten über den Tunnel gesendet werden.

Konfigurationsdatenverkehr, wie etwa ein Container-Image-Pull beim Start, folgt seinen eigenen Routing-Regeln und kann fehlschlagen, während Ihre API-Aufrufe erfolgreich sind.

Das Integrationssubnetz ist die Quelle, die Sie zulassen müssen

Das Büro sieht den Adressbereich des Integrationssubnetzes oder was auch immer Ihre Appliance übersetzt, nicht die öffentlichen ausgehenden Adressen der App. Fügen Sie diesen Bereich in die Datenverkehrsauswahl des Standort-VPN und in die lokale Firewallregel ein. Wenn der Tunnel richtlinienbasiert ist, Selektoren, die ihn auslassen, verwerfen das Paket, selbst wenn eine Route vorhanden ist.

Erlauben Sie keinem einzigen Mitarbeiter, den Sie zufällig bemerkt haben. Instanzen ändern sich mit der Skalierung und Plattformwartung, und eine an eine Adresse angeheftete Regel bricht im schlimmsten Moment.

Halten Sie die Zielseite eng: ein Dienst, ein Port, eine Richtung, wobei der Rückweg explizit erlaubt ist.

Peering und Gateway-Transit sind explizit

Wenn sich das VPN-Gateway in einem Hub-VNET und das Integrationssubnetz in einem Spoke befindet, muss für den Pfad der Gateway-Transit beim Hub-Peering zugelassen und die Verwendung des Remote-Gateways beim Spoke-Peering aktiviert sein. Peering allein überträgt den Datenverkehr zwischen den beiden VNets und nichts weiter. Bei den effektiven Routen im Integrationssubnetz bestätigen Sie, dass der nächste Gateway-Hop wirklich vorhanden ist.

Ein Hub-and-Spoke-Design, dessen Routing-Tabelle 0.0.0.0/0 an eine Firewall sendet, ist eine gängige Variante, und diese Firewall benötigt dann eine eigene Regel für das lokale Präfix.

Zeichnen Sie den Weg auf Papier, bevor Sie ein Ticket beim Netzwerkteam eröffnen, denn das erspart Ihnen einen Tag des Rätselratens. Beziehen Sie die Rückrichtung in die Zeichnung ein, da dies die Hälfte ist, die die Leute vergessen.

Eingehender privater Endpunkt ist die andere Richtung

Ein privater Endpunkt macht die App aus einem VNet heraus erreichbar. Für den ausgehenden Anruf der App im Büro hat es keine Auswirkung, und Teams konfigurieren regelmäßig einen, während die eigentliche Anforderung das Gegenteil war.

Ältere Dokumentationen beschreiben die Gateway-erforderliche Integration basierend auf Point-to-Site-VPN, einer anderen Funktion mit eigenen Anforderungen. Microsoft plant die Einstellung dieser Funktion für den 31. März 2027 und empfiehlt stattdessen die regionale Integration.

Kopieren Sie keine ältere Point-to-Site-Konfiguration, nur weil sie in einem alten Beispiel verwendet wurde.

Mit dem eigenen Kontext der App überprüfen

Testen Sie von der bereitgestellten App aus, nicht von Ihrem Laptop und nicht von einer VM im selben VNet. Protokollieren Sie die aufgelöste Adresse, das Verbindungsergebnis und die Antwort auf Anwendungsebene separat, da ein DNS-Fehler, ein TCP-Timeout und ein Authentifizierungsablehnungspunkt bei drei verschiedenen Eigentümern vorliegen. Wenn die Namensauflösung fehlschlägt, reparieren Sie das private DNS für das VNet, bevor Sie den Tunnel berühren.

Ein grüner Tunnelstatus beweist nur, dass das Gateway aktiv ist. Es sagt nichts über Selektoren, Firewall-Regeln oder DNS aus.

Wenn die Anfrage endlich funktioniert, schreiben Sie den Quellbereich, den Zielport und die DNS-Zone in das Runbook der App. Die nächste Person, die das Problem behebt, beginnt mit Ihrer Notiz und nicht mit der Statusseite des Gateways.