Freigeben über


Fehlerbehebung bei der Integration virtueller Netzwerke mit Azure App Service

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

Notiz

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 zuerst überprüfen, ob die Integration des virtuellen Netzwerks ordnungsgemäß konfiguriert ist und ob die private IP allen Instanzen des App Service Plans zugewiesen ist.

Wenden Sie hierzu eine der folgenden Methoden an:

Überprüfen der privaten IP in der Kudu Debug-Konsole

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

Screenshot, der zeigt, wie Sie die Kudu-Dienstseite im Azure-Portal öffnen.

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 OS-basierte Apps

SET WEBSITE_PRIVATE_IP

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

WEBSITE_PRIVATE_IP=<IP address>

Linux OS-basierte Apps

set| egrep --color 'WEBSITE_PRIVATE_IP'

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

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

Nachdem wir festgestellt haben, dass die Integration des virtuellen Netzwerks erfolgreich konfiguriert ist, können wir mit dem Verbindungstest fortfahren.

Problembehandlung bei ausgehender Konnektivität in Windows-Apps

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

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

Zum Testen der DNS-Funktionalität können Sie nameresolver.exe verwenden. Die Syntax ist:

nameresolver.exe hostname [optional:DNS Server]

Sie können nameresolver verwenden, um die Hostnamen zu überprüfen, von denen Ihre App abhängig ist. Auf diese Weise können Sie testen, ob Sie mit Ihrem DNS falsch konfiguriert sind oder vielleicht keinen Zugriff auf Ihren DNS-Server haben. Den von Ihrer App verwendeten DNS-Server können Sie in der Konsole in den Umgebungsvariablen WEBSITE_DNS_SERVER und WEBSITE_DNS_ALT_SERVER einsehen.

Hinweis

Das Tool „nameresolver.exe“ funktioniert zurzeit nicht in benutzerdefinierten Windows-Containern.

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

tcpping.exe hostname [optional: port]

Das tcpping-Hilfsprogramm teilt Ihnen mit, ob Sie einen bestimmten Host und Port erreichen können. Erfolg kann nur angezeigt werden, wenn eine Anwendung an der Host- und Portkombination lauscht, und es gibt Netzwerkzugriff von Ihrer App auf den angegebenen Host und Port.

Problembehandlung bei ausgehender Konnektivität in Linux-Apps

Wechseln Sie direkt zu Kudu unter [sitename].scm.azurewebsites.net. Wählen Sie auf der Seite "Kudu-Dienst" die Option "Tools>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]

Je nach den oben genannten Ergebnissen können Sie überprüfen, ob auf Ihrem DNS-Server etwas falsch konfiguriert ist.

Notiz

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

Zum Testen der Konnektivität können Sie den Befehl "Curl " 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. Meistens ist dies eine der folgenden:

  • Eine Firewall. Falls eine Firewall den Zugriff verhindert, wird das TCP-Timeout ausgelöst. Das TCP-Timeout entspricht hier 21 Sekunden. Überprüfen Sie die Verbindung mithilfe des tcpping-Tools. TCP-Timeouts können zwar auch viele andere Ursachen haben, es empfiehlt sich jedoch, bei der Firewall zu beginnen.
  • Kein DNS-Zugriff. 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 dies nicht das DNS verwendet, mit dem Ihr virtuelles Netzwerk konfiguriert ist. Wenn auf sie nicht zugegriffen werden kann, könnte eine Firewall oder eine NSG den Zugriff auf DNS blockieren, oder dies könnte nicht möglich sein. 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 Name Resolution (DNS) in App Service.

Sollte das Problem weiterhin bestehen, überprüfen Sie zunächst Folgendes:

Regionale Integration des virtuellen Netzwerks

  • Ist Ihr Ziel eine RFC 1918-fremde Adresse und Route All (Gesamten Datenverkehr weiterleiten) nicht aktiviert?
  • Blockiert eine Netzwerksicherheitsgruppe ausgehenden Datenverkehr aus Ihrem Integrationssubnetz?
  • Bei einer Verbindung über Azure ExpressRoute oder ein VPN: Ist Ihr lokales Gateway zum Zurückleiten von Datenverkehr an Azure konfiguriert? Wenn Sie die Endpunkte in Ihrem virtuellen Netzwerk erreichen können, aber nicht lokal, überprüfen Sie Ihre Routen.
  • Verfügen Sie über ausreichende Berechtigungen, um Delegierung für das Integrationssubnetz festzulegen? Während der Konfiguration der Integration des regionalen virtuellen Netzwerks wird Ihr Integrationssubnetz an „Microsoft.Web/serverFarms“ delegiert. Das Subnetz wird von der Benutzeroberfläche der VNET-Integration automatisch an „Microsoft.Web/serverFarms“ delegiert. Wenn Ihr Konto nicht über ausreichende Netzwerkberechtigungen verfügt, um Delegierung festzulegen, benötigen Sie eine Person, die in Ihrem Integrationssubnetz Attribute festlegen kann, um das Subnetz zu delegieren. Wenn Sie das Subnetz für die Integration manuell delegieren möchten, 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. Mögliche Ursachen:

  • Sie verfügen über eine aktivierte Firewall auf Ihrem Host, die den Zugriff auf den Anwendungsport über Ihren Point-to-Site-IP-Adressbereich verhindert Für die Durchquerung von Subnetzen ist häufig öffentlicher Zugriff erforderlich.
  • Zielhost ausgefallen
  • Anwendung nicht verfügbar
  • Falsche IP-Adresse oder falscher Hostname
  • Die Anwendung lauscht über einen anderen Port als erwartet. Sie können Ihre Prozess-ID auf den lauschenden Port festlegen, indem Sie auf dem Endpunkthost „netstat -aon“ verwenden.
  • Netzwerksicherheitsgruppen sind so konfiguriert, dass der Zugriff auf Ihren Anwendungshost und -port aus Ihrem Point-to-Site-IP-Adressbereich verhindert wird.

Ihnen ist nicht bekannt, welche Adresse Ihre App tatsächlich verwendet. Es kann sich um eine beliebige Adresse im Integrationssubnetz oder Point-to-Site-Adressbereich handeln. Sie müssen daher den Zugriff vom gesamten Adressbereich zulassen.

Weitere Debugschritte sind unter anderem:

  • Stellen Sie eine Verbindung mit einer VM im virtuellen Netzwerk her, und versuchen Sie, die Ressource host:port von dort aus zu erreichen. Zum Testen des TCP-Zugriffs verwenden Sie den PowerShell-Befehl Test-NetConnection. Die Syntax ist:
Test-NetConnection hostname [optional: -Port]
  • Rufen Sie eine Anwendung auf einer VM auf, und testen Sie den Zugriff auf den jeweiligen Host und Port über die Konsole der App mit tcpping.

Netzwerkproblembehandlung

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

Screenshot, der zeigt, wie Sie die Netzwerkproblembehandlung im Azure-Portal öffnen.

Notiz

Das Verbindungsproblemenszenario unterstützt noch keine Linux- oder Container-basierten Apps.

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

Screenshot der Ausführung der Problembehandlung für Verbindungsprobleme.

Konfigurationsprobleme – Diese Problembehandlung überprüft, ob Ihr Subnetz für die Integration des virtuellen Netzwerks gültig ist.

Screenshot, der zeigt, wie Sie die Problembehandlung für Konfigurationsprobleme im Azure-Portal ausführen.

Problem beim Löschen von Subnetz/VNet – Diese Problembehandlung überprüft, ob Ihr Subnetz sperrt und ob es nicht verwendete Dienstzuordnungslinks enthält, die möglicherweise das Löschen des VNet/Subnetzes blockieren.

Screenshot, der zeigt, wie Sie Problembehandlungen für Subnetz- oder virtuelle Netzwerklöschprobleme ausführen.

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.

Notiz

Der virtuelle Netzwerkdatenverkehr wird nicht in Netzwerkablaufverfolgungen erfasst.

Windows App Services

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

  1. Navigieren Sie im Azure-Portal zu Ihrer Web App.
  2. Wählen Sie in der linken Navigationsleiste "Diagnostizieren" und " Probleme lösen" aus.
  3. Geben Sie im Suchfeld "Netzwerkablaufverfolgung sammeln" ein, und wählen Sie " Netzwerkablaufverfolgung sammeln" aus, um die Netzwerkablaufverfolgungssammlung zu starten.

Screenshot, der zeigt, wie eine Netzwerkablaufverfolgung erfasst wird.

Um die Ablaufverfolgungsdatei für jede Instanz abzurufen, die eine Web App bedient, 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-Dienste 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 ausgeführt wird, indem Sie den folgenden Befehl ausführen (z eth0. 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 den eth0 Namen der tatsächlichen Schnittstelle.

Um die Ablaufverfolgungsdatei herunterzuladen, stellen Sie eine Verbindung mit der Web App über Methoden wie Kudu, FTP oder eine Kudu-API-Anforderung 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.