Freigeben über

Problembehandlung bei der Integration virtueller Netzwerke mit Azure App Service

  • Artikel

In diesem Artikel werden Tools beschrieben, mit denen Sie Verbindungsprobleme in Azure App Service beheben können, die in ein virtuelles Netzwerk integriert sind.

Hinweis

Die Integration virtueller Netzwerke wird für Docker Compose-Szenarien in App Service nicht unterstützt. Zugriffseinschränkungsrichtlinien werden ignoriert, wenn ein privater Endpunkt vorhanden ist.

Überprüfen der Integration virtueller Netzwerke

Um die Verbindungsprobleme zu beheben, müssen Sie zunächst überprüfen, ob die Integration des virtuellen Netzwerks ordnungsgemäß konfiguriert ist und ob die private IP-Adresse allen Instanzen des App Service-Plans zugewiesen ist.

Verwenden Sie dazu eine der folgenden Methoden:

Überprüfen der privaten IP-Adresse in der Kudu-Debugkonsole

Um auf die Kudu-Konsole zuzugreifen, wählen Sie den App-Dienst im Azure-Portal aus, wechseln Sie zu Entwicklungstools, wählen Sie Erweiterte Tools und dann Los aus. Wählen Sie auf der Seite Kudu-Dienst die Option Extras>Debug Console>CMD aus.

Screenshot: Öffnen der Kudu-Dienstseite im Azure-Portal

Sie können auch direkt über die URL [sitename].scm.azurewebsites.net/DebugConsolezur Kudu Debug-Konsole wechseln.

Führen Sie in der Debugkonsole einen der folgenden Befehle aus:

Windows-betriebssystembasierte Apps

SET WEBSITE_PRIVATE_IP

Wenn die private IP-Adresse erfolgreich zugewiesen wurde, erhalten Sie die folgende Ausgabe:

WEBSITE_PRIVATE_IP=<IP address>

Linux-betriebssystembasierte Apps

set| egrep --color 'WEBSITE_PRIVATE_IP'

Überprüfen der privaten IP-Adresse in der Kudu-Umgebung

Wechseln Sie zur Kudu-Umgebung unter , [sitename].scm.azurewebsites.net/Env und suchen Sie WEBSITE_PRIVATE_IPnach .

Nachdem wir festgestellt haben, dass die Integration des virtuellen Netzwerks erfolgreich konfiguriert wurde, können wir mit dem Konnektivitätstest fortfahren.

Problembehandlung bei ausgehender Konnektivität in Windows-Apps

In nativen Windows-Apps funktionieren die Tools ping, nslookup und tracert aufgrund von Sicherheitseinschränkungen nicht über die Konsole (sie funktionieren in benutzerdefinierten Windows-Containern).

Wechseln Sie direkt unter [sitename].scm.azurewebsites.net/DebugConsolezur Kudu-Konsole.

Zum Testen der DNS-Funktionalität können Sie nameresolver.exeverwenden. Die Syntax lautet:

nameresolver.exe hostname [optional:DNS Server]

Sie können nameresolver verwenden, um die Hostnamen zu überprüfen, von denen Ihre App abhängt. Auf diese Weise können Sie testen, ob Sie etwas falsch mit Ihrem DNS konfiguriert haben oder möglicherweise keinen Zugriff auf Ihren DNS-Server haben. Sie können den DNS-Server, den Ihre App verwendet, in der Konsole anzeigen, indem Sie sich die Umgebungsvariablen WEBSITE_DNS_SERVER und WEBSITE_DNS_ALT_SERVER ansehen.

Hinweis

Das nameresolver.exe-Tool funktioniert derzeit nicht in benutzerdefinierten Windows-Containern.

Um die TCP-Konnektivität mit einer Kombination aus Host und Port zu testen, können Sie tcpping verwenden. Die Syntax lautet.

tcpping.exe hostname [optional: port]

Das Hilfsprogramm tcpping teilt Ihnen mit, ob Sie einen bestimmten Host und Port erreichen können. Es kann nur dann erfolgreich sein, wenn eine Anwendung an der Kombination aus Host und Port lauscht und netzwerkzugriff von Ihrer App auf den angegebenen Host und Port besteht.

Problembehandlung bei ausgehender Konnektivität in Linux-Apps

Navigieren Sie direkt unter [sitename].scm.azurewebsites.netzu Kudu. Wählen Sie auf der Seite Kudu-Dienst die Option Extras>Debug Console>CMD aus.

Zum Testen der DNS-Funktionalität können Sie den Befehl nslookup verwenden. Die Syntax lautet:

nslookup hostname [optional:DNS Server]

Abhängig von den oben genannten Ergebnissen können Sie überprüfen, ob auf Ihrem DNS-Server etwas falsch konfiguriert ist.

Hinweis

Das nameresolver.exe-Tool funktioniert derzeit nicht in Linux-Apps.

Zum Testen der Konnektivität können Sie den Curl-Befehl verwenden. Die Syntax lautet:

curl -v https://hostname
curl hostname:[port]

Debuggen des Zugriffs auf im virtuellen Netzwerk gehostete Ressourcen

Eine Reihe von Faktoren kann verhindern, dass Ihre App einen bestimmten Host und Port erreicht. In den meisten Fällen ist dies eine der folgenden:

  • Eine Firewall ist im Weg. Wenn Sie eine Firewall im Weg haben, erreichen Sie das TCP-Timeout. Das TCP-Timeout beträgt in diesem Fall 21 Sekunden. Verwenden Sie das TCPPING-Tool , um die Konnektivität zu testen. TCP-Timeouts können durch viele Dinge außerhalb von Firewalls verursacht werden, aber beginnen Sie dort.
  • Auf DNS kann nicht zugegriffen werden. Das DNS-Timeout beträgt drei Sekunden pro DNS-Server. Wenn Sie über zwei DNS-Server verfügen, beträgt das Timeout sechs Sekunden. Verwenden Sie nameresolver, um festzustellen, ob das DNS funktioniert. Sie können nslookup nicht verwenden, da dadurch nicht das DNS verwendet wird, mit dem Ihr virtuelles Netzwerk konfiguriert ist. Wenn nicht zugegriffen werden kann, könnte eine Firewall oder NSG den Zugriff auf DNS blockieren, oder es könnte ausfallen. Einige DNS-Architekturen, die benutzerdefinierte DNS-Server verwenden, können komplex sein und gelegentlich timeouts auftreten. Um festzustellen, ob dies der Fall ist, kann die Umgebungsvariable WEBSITE_DNS_ATTEMPTS festgelegt werden. Weitere Informationen zu DNS in App Services finden Sie unter Namensauflösung (DNS) in App Service.

Wenn diese Elemente Ihre Probleme nicht beantworten, suchen Sie zuerst nach Dingen wie:

Regionale Integration virtueller Netzwerke

  • Ist Ihr Ziel eine adresse, die nicht RFC1918 ist, und Sie haben " Route All " nicht aktiviert?
  • Gibt es eine NSG, die ausgehenden Datenverkehr aus Ihrem Integrationssubnetz blockiert?
  • Wenn Sie Azure ExpressRoute oder ein VPN verwenden: Ist Ihr lokales Gateway so konfiguriert, dass datenverkehrssicher an Azure weitergeleitet wird? Wenn Sie Endpunkte in Ihrem virtuellen Netzwerk erreichen können, aber nicht lokal, überprüfen Sie Ihre Routen.
  • Verfügen Sie über ausreichende Berechtigungen zum Festlegen der Delegierung für das Integrationssubnetz? Während der Konfiguration der regionalen VNET-Integration wird Ihr Integrationssubnetz an Microsoft.Web/serverFarms delegiert. Die Benutzeroberfläche für die VNET-Integration delegiert das Subnetz automatisch an Microsoft.Web/serverFarms. Wenn Ihr Konto nicht über ausreichende Netzwerkberechtigungen zum Festlegen der Delegierung verfügt, benötigen Sie eine Person, die Attribute für Ihr Integrationssubnetz festlegen kann, um das Subnetz zu delegieren. Um das Integrationssubnetz manuell zu delegieren, wechseln Sie zur Benutzeroberfläche des Azure Virtual Network Subnetzes, und legen Sie die Delegierung für Microsoft.Web/serverFarms fest.

Das Debuggen von Netzwerkproblemen ist eine Herausforderung, da Sie nicht sehen können, was den Zugriff auf eine bestimmte Host:Port-Kombination blockiert. Einige Ursachen sind:

  • Sie verfügen über eine Firewall auf Ihrem Host, die den Zugriff auf den Anwendungsport von Ihrem Point-to-Site-IP-Bereich aus verhindert. Das Überqueren von Subnetzen erfordert häufig öffentlichen Zugriff.
  • Ihr Zielhost ist ausgefallen.
  • Ihre Anwendung ist ausgefallen.
  • Sie hatten die falsche IP-Adresse oder den falschen Hostnamen.
  • Ihre Anwendung lauscht an einem anderen Port als erwartet. Sie können Ihre Prozess-ID mit dem Lauschport abgleichen, indem Sie "netstat -aon" auf dem Endpunkthost verwenden.
  • Ihre Netzwerksicherheitsgruppen sind so konfiguriert, dass sie den Zugriff auf Ihren Anwendungshost und -port aus Ihrem Point-to-Site-IP-Bereich verhindern.

Sie wissen nicht, welche Adresse Ihre App tatsächlich verwendet. Es kann sich um eine beliebige Adresse im Integrationssubnetz oder im Point-to-Site-Adressbereich handeln, sodass Sie den Zugriff aus dem gesamten Adressbereich zulassen müssen.

Weitere Debugschritte sind:

  • Stellen Sie eine Verbindung mit einer VM in Ihrem virtuellen Netzwerk her, und versuchen Sie, ihren Ressourcenhost:Port von dort aus zu erreichen. Verwenden Sie zum Testen des TCP-Zugriffs den PowerShell-Befehl Test-NetConnection. Die Syntax lautet:
Test-NetConnection hostname [optional: -Port]
  • Rufen Sie eine Anwendung auf einem virtuellen Computer auf, und testen Sie den Zugriff auf diesen Host und Port über die Konsole über Ihre App mithilfe von TCPPING.

Netzwerkproblembehandlung

Sie können auch die Netzwerkproblembehandlung verwenden, um die Verbindungsprobleme für die Apps im App Service zu beheben. Um die Netzwerkproblembehandlung zu öffnen, wechseln Sie zum App Service im Azure-Portal. Wählen Sie Diagnose und Problem lösen aus, und suchen Sie dann nach Netzwerkproblembehandlung.

Screenshot: Öffnen der Netzwerkproblembehandlung im Azure-Portal

Hinweis

Das Szenario mit Verbindungsfehlern unterstützt noch keine Linux- oder Container-basierten Apps.

Verbindungsprobleme: Es überprüft die status der Integration des virtuellen Netzwerks, einschließlich der Überprüfung, ob die private IP-Adresse allen Instanzen des App Service-Plans und den DNS-Einstellungen zugewiesen wurde. Wenn kein benutzerdefiniertes DNS konfiguriert ist, wird der Azure-Standard-DNS angewendet. Sie können auch Tests für einen bestimmten Endpunkt ausführen, mit dem Sie die Konnektivität testen möchten.

Screenshot: Ausführungsproblembehandlung für Verbindungsprobleme

Konfigurationsprobleme : Mit dieser Problembehandlung wird überprüft, ob Ihr Subnetz für die Integration virtueller Netzwerke gültig ist.

Screenshot: Ausführen der Problembehandlung für Konfigurationsprobleme im Azure-Portal

Problem beim Löschen von Subnetzen/VNET : Mit dieser Problembehandlung wird überprüft, ob Ihr Subnetz über Sperren verfügt und ob es nicht verwendete Dienstzuordnungslinks enthält, die möglicherweise das Löschen des VNET/Subnetzes blockieren.

Screenshot: Ausführen der Problembehandlung für Probleme beim Löschen von Subnetzen oder virtuellen Netzwerken

Sammeln von Netzwerkablaufverfolgungen

Das Sammeln von Netzwerkablaufverfolgungen kann bei der Analyse von Problemen hilfreich sein. In Azure-App Services werden Netzwerkablaufverfolgungen aus dem Anwendungsprozess übernommen. Um genaue Informationen zu erhalten, reproduzieren Sie das Problem beim Starten der Netzwerkablaufverfolgungssammlung.

Hinweis

Der Datenverkehr des virtuellen Netzwerks wird nicht in Netzwerkablaufverfolgungen erfasst.

Windows App Services

Führen Sie die folgenden Schritte aus, um Netzwerkablaufverfolgungen für Windows App Services zu erfassen:

  1. Navigieren Sie im Azure-Portal zu Ihrer Web-App.
  2. Wählen Sie im linken Navigationsbereich Diagnose und Problembehandlung aus.
  3. Geben Sie im Suchfeld Netzwerkablaufverfolgung sammeln ein, und wählen Sie Netzwerkablaufverfolgung sammeln aus, um die Sammlung der Netzwerkablaufverfolgung zu starten.

Screenshot: Erfassen einer Netzwerkablaufverfolgung

Um die Ablaufverfolgungsdatei für jede instance abzurufen, die eine Web-App bereitstellen, wechseln Sie in Ihrem Browser zur Kudu-Konsole für die Web-App (https://<sitename>.scm.azurewebsites.net). Laden Sie die Ablaufverfolgungsdatei aus dem Ordner C:\home\LogFiles\networktrace oder D:\home\LogFiles\networktrace herunter.

Linux App Services

Führen Sie die folgenden Schritte aus, um Netzwerkablaufverfolgungen für Linux App Services zu sammeln, die keinen benutzerdefinierten Container verwenden:

  1. Installieren Sie das tcpdump Befehlszeilenprogramm, indem Sie die folgenden Befehle ausführen:

    apt-get update
apt install tcpdump

  2. Stellen Sie über das Secure Shell-Protokoll (SSH) eine Verbindung mit dem Container her.

  3. Identifizieren Sie die Schnittstelle, die aktiv ist und ausgeführt wird, eth0indem Sie den folgenden Befehl ausführen (z. B. ):

    root@<hostname>:/home# tcpdump -D

1.eth0 [Up, Running, Connected]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
7.dbus-system (D-Bus system bus) [none]
8.dbus-session (D-Bus session bus) [none]

  4. Starten Sie die Netzwerkablaufverfolgungssammlung, indem Sie den folgenden Befehl ausführen:

    root@<hostname>:/home# tcpdump -i eth0 -w networktrace.pcap

    Ersetzen Sie durch eth0 den Namen der tatsächlichen Schnittstelle.

Stellen Sie zum Herunterladen der Ablaufverfolgungsdatei über Methoden wie Kudu, FTP oder eine Kudu-API-Anforderung eine Verbindung mit der Web-App her. Hier ist ein Anforderungsbeispiel zum Auslösen des Dateidownloads:

https://<sitename>.scm.azurewebsites.net/api/vfs/<path to the trace file in the /home directory>/filename

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.