Behandeln von Fehlern aufgrund eines ungültigen Gateways in Application Gateway

Erfahren Sie mehr zur Problembehandlung bei Fehlern aufgrund eines ungültigen Gateways (502) in Application Gateway.

Überblick

Nach der Konfiguration eines Anwendungsgateways wird Ihnen möglicherweise dieser Fehler angezeigt: Serverfehler: 502 – Webserver hat als Gateway oder Proxyserver eine ungültige Antwort erhalten. Dieser Fehler kann folgende Hauptursachen haben:

• Eine NSG, eine benutzerdefinierte Route (UDR, user-defined route) oder ein benutzerdefiniertes DNS blockiert den Zugriff auf Back-End-Poolmitglieder.
• Back-End-VMs oder Instanzen der VM-Skalierungsgruppe reagieren nicht auf die standardmäßige Integritätsüberprüfung.
• Benutzerdefinierte Integritätsüberprüfungen sind ungültig oder nicht korrekt konfiguriert.
• Der Back-End-Pool von Azure Application Gateway ist nicht konfiguriert oder leer.
• Die virtuellen Computer oder Instanzen in der VM-Skalierungsgruppe befinden sich nicht in einem fehlerfreien Zustand.
• Bei der Anforderung tritt ein Timeout auf, oder es liegen Verbindungsprobleme bei Benutzeranforderungen vor.

Netzwerksicherheitsgruppe, benutzerdefinierte Route oder benutzerdefiniertes DNS-Problem

Ursache

Wenn der Zugriff auf das Back-End wegen einer NSG, benutzerdefinierten Route oder einem benutzerdefinierten DNS blockiert ist, können Application Gateway-Instanzen den Back-End-Pool nicht erreichen. Dieses Problem verursacht Testfehler, die zu Fehlern vom Typ 502 führen.

Die NSG/UDR könnte entweder im Application Gateway-Subnetz oder im Subnetz vorhanden sein, in dem die Anwendungs-VMs bereitgestellt sind.

Auf ähnliche Weise könnte auch das Vorhandensein eines benutzerdefinierten DNS im VNet auch Probleme verursachen. Ein für Back-End-Poolmitglieder verwendeter FQDN wird vom durch den Benutzer konfigurierten DNS-Server möglicherweise nicht ordnungsgemäß für das VNet aufgelöst.

Lösung

Überprüfen Sie die NSG-, UDR- und DNS-Konfiguration, indem Sie die folgenden Schritte durchlaufen:

1. Überprüfen Sie NSGs, die dem Application Gateway-Subnetz zugeordnet sind. Stellen Sie sicher, dass die Kommunikation mit dem Back-End nicht blockiert ist. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

2. Überprüfen Sie die UDR, die dem Application Gateway-Subnetz zugeordnet ist. Stellen Sie sicher, dass die UDR keinen Datenverkehr vom Back-End-Subnetz wegleitet. Überprüfen Sie z. B. das Routing zu virtuellen Geräten oder Standardrouten, die dem Application Gateway-Subnetz über ExpressRoute/VPN angekündigt werden.

   $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
   Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
   

3. Überprüfen Sie die effektiven NSGs und Routen mit dem virtuellen Back-End-Computer.

   Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
   Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
   

4. Überprüfen Sie das Vorhandensein eines benutzerdefinierten DNS im VNet. DNS kann überprüft werden, indem Sie einen Blick auf die Details der VNet-Eigenschaften in der Ausgabe werfen.

   Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
   DhcpOptions            : {
                              "DnsServers": [
                                "x.x.x.x"
                              ]
                            }
   

5. Falls vorhanden, stellen Sie sicher, dass der DNS-Server den FQDN von Back-End-Poolmitgliedern ordnungsgemäß auflösen kann.

Probleme mit der standardmäßigen Integritätsüberprüfung

Ursache

502-Fehler sind auch oftmals darauf zurückzuführen, dass Back-End-VMs für die standardmäßige Integritätsüberprüfung nicht erreichbar sind.

Beim Bereitstellen einer Application Gateway-Instanz wird unter Verwendung von Eigenschaften der Back-End-HTTP-Einstellung automatisch für jeden Back-End-Adresspool eine standardmäßige Integritätsüberprüfung konfiguriert. Zum Festlegen dieser Überprüfung ist keinerlei Benutzereingabe erforderlich. Wenn eine Regel für den Lastenausgleich konfiguriert wird, erfolgt eine Zuordnung zwischen einer Back-End-HTTP-Einstellung und dem Back-End-Adresspool. Für diese Zuordnungen wird jeweils eine standardmäßige Integritätsüberprüfung konfiguriert, und Application Gateway stellt über den im BackendHttpSetting-Element angegebenen Port in regelmäßigen Abständen eine Verbindung mit den einzelnen Instanzen im Back-End-Adresspool her, um die Integrität zu überprüfen.

Die folgende Tabelle enthält die Werte der standardmäßigen Integritätsüberprüfung:

Lösung

• Der Hostwert der Anforderung wird auf 127.0.0.1 festgelegt. Stellen Sie sicher, dass die Standardwebsite konfiguriert ist und an 127.0.0.1 lauscht.
• Das Protokoll der Anforderung wird durch das BackendHttpSetting-Protokoll bestimmt.
• Der URI-Pfad wird auf / festgelegt.
• Falls im BackendHttpSetting-Element nicht der Port 80 angegeben ist, muss die Standardwebsite so konfiguriert werden, dass sie am angegebenen Port lauscht.
• Der Aufruf von protocol://127.0.0.1:port sollte den HTTP-Ergebniscode 200 zurückgeben. Dieser Code sollte innerhalb des Timeoutzeitraums von 30 Sekunden zurückgegeben werden.
• Vergewissern Sie sich, dass der konfigurierte Port geöffnet ist und dass eingehender oder ausgehender Datenverkehr am konfigurierten Port nicht durch Firewallregeln oder Azure-Netzwerksicherheitsgruppen blockiert wird.
• Wenn klassische Azure-VMs oder ein klassischer Azure-Clouddienst mit einem FQDN oder einer öffentlichen IP-Adresse verwendet werden, stellen Sie sicher, dass der entsprechende Endpunkt geöffnet ist.
• Falls der virtuelle Computer über Azure Resource Manager konfiguriert wurde und sich außerhalb des virtuellen Netzwerks befindet, in dem Application Gateway bereitgestellt ist, muss für den Zugriff auf den gewünschten Port eine Netzwerksicherheitsgruppe konfiguriert werden.

Weitere Informationen finden Sie unter Konfiguration der Application Gateway-Infrastruktur.

Probleme mit einer benutzerdefinierten Integritätsüberprüfung

Ursache

Benutzerdefinierte Integritätsüberprüfungen sorgen für zusätzliche Flexibilität. Bei Verwendung von benutzerdefinierten Überprüfungen können Sie das Überprüfungsintervall, die URL und den zu überprüfenden Pfad konfigurieren und festlegen, wie viele fehlerhafte Antworten akzeptiert werden, bevor die Back-End-Pool-Instanz als fehlerhaft gekennzeichnet wird.

Folgende Zusatzeigenschaften werden hinzugefügt:

Lösung

Vergewissern Sie sich anhand der Tabelle weiter oben, dass die benutzerdefinierte Integritätsüberprüfung ordnungsgemäß konfiguriert ist. Stellen Sie zusätzlich zu den oben aufgeführten Problembehandlungsschritten auch Folgendes sicher:

• Stellen Sie anhand der Anleitungsicher, dass die Überprüfung ordnungsgemäß angegeben ist.
• Wenn Application Gateway für einen einzelnen Standort konfiguriert ist, muss der Hostname standardmäßig als 127.0.0.1 angegeben werden, sofern in der benutzerdefinierten Überprüfung nichts anderes konfiguriert ist.
• Vergewissern Sie sich, dass ein Aufruf von „http://<Host>:<Port><Pfad>“ den HTTP-Ergebniscode 200 zurückgibt.
• Stellen Sie sicher, dass „Intervall“, „Zeitüberschreitung“ und „Fehlerhafter Schwellenwert“ innerhalb des zulässigen Bereichs liegen.
• Stellen Sie bei Verwendung einer HTTPS-Überprüfung sicher, dass der Back-End-Server kein SNI erfordert, indem Sie ein Fallback-Zertifikat auf dem Back-End-Server selbst erstellen.

Anforderungstimeout

Ursache

Wenn eine Benutzeranforderung empfangen wird, wendet das Anwendungsgateway die konfigurierten Regeln auf die Anforderung an und leitet sie an eine Back-End-Poolinstanz weiter. Danach wartet es eine bestimmte Zeit auf eine Antwort von der Back-End-Instanz. Dieses Intervall ist standardmäßig auf 20 Sekunden festgelegt. Wenn bei Application Gateway v1 das Anwendungsgateway innerhalb dieses Intervalls keine Antwort von der Back-End-Anwendung erhält, führt die Benutzeranforderung zu einem Fehler vom Typ 502. Wenn bei Application Gateway v2 das Anwendungsgateway innerhalb dieses Intervalls keine Antwort von der Back-End-Anwendung erhält, wird die Anforderung an ein zweites Back-End-Poolmitglied gesendet. Wenn die zweite Anforderung fehlschlägt, resultiert die Benutzeranforderung im Fehler 504.

Lösung

Mit Application Gateway können Sie diese Einstellung über das BackendHttpSetting-Element konfigurieren und auf verschiedene Pools anwenden. Bei unterschiedlichen Back-End-Pools können unterschiedliche Back-End-HTTP-Einstellungen und unterschiedliche Anforderungstimeouts konfiguriert sein.

    New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

Leerer Back-End-Adresspool

Ursache

Falls im Back-End-Adresspool des Anwendungsgateways keine VMs konfiguriert sind oder keine VM-Skalierungsgruppe konfiguriert ist, können Kundenanforderungen nicht weitergeleitet werden, und es wird die Fehlermeldung „Ungültiges Gateway“ gesendet.

Lösung

Vergewissern Sie sich, dass der Back-End-Adresspool nicht leer ist. Hierzu können Sie entweder PowerShell, die Befehlszeilenschnittstelle oder das Portal verwenden.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

Die Ausgabe des vorherigen Cmdlets muss nicht leere Back-End-Adresspools enthalten. Das folgende Beispiel zeigt die Rückgabe von zwei Pools, die mit einem FQDN oder einer IP-Adresse für Back-End-VMs konfiguriert sind. Der Bereitstellungszustand des Back-End-Adresspools muss „Succeeded“ lauten.

BackendAddressPoolsText:

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

Fehlerhafte Instanzen im Back-End-Adresspool

Ursache

Wenn alle Instanzen des Back-End-Adresspools fehlerhaft sind, steht dem Anwendungsgateway kein Back-End zur Weiterleitung von Benutzeranforderungen zur Verfügung. Dies kann auch auftreten, wenn zwar fehlerfreie Back-End-Instanzen vorhanden sind, diese aber nicht über die erforderliche Anwendung verfügen.

Lösung

Stellen Sie sicher, dass die Instanzen fehlerfrei sind und die Anwendung ordnungsgemäß konfiguriert ist. Prüfen Sie, ob die Back-End-Instanzen auf ein Ping von einer anderen VM im gleichen virtuellen Netzwerk reagieren. Vergewissern Sie sich bei einer Konfiguration mit öffentlichem Endpunkt, dass eine an die Webanwendung gerichtete Browseranforderung verarbeitet werden kann.

Vorgelagertes SSL-Zertifikat stimmt nicht überein

Ursache

Das auf den Back-End-Servern installierte TLS-Zertifikat stimmt nicht mit dem Hostnamen überein, der im Hostanforderungsheader empfangen wurde.

Die Szenarien mit aktivierter End-to-End TLS erfordern eine gewisse Konfiguration. Dort müssen die entsprechenden "Back-End-HTTP-Einstellungen" bearbeitet und die Konfiguration der Einstellung "Back-End-Protokoll" auf HTTPS geändert werden. Es muss unbedingt sichergestellt werden, dass der CNAME des auf Back-End-Servern installierten TLS-Zertifikats dem Hostnamen entspricht, der in der HTTP-Hostheaderanforderung zum Back-End kommt.

Zur Erinnerung: Durch die Aktivierung der HTTPS-Protokoll-Option anstatt HTTP auf „Backend HTTP Settings“ wird der zweite Teil der Kommunikation zwischen den Instanzen des Anwendungsgateways und den Back-End-Servern mit TLS verschlüsselt.

Aufgrund der Tatsache, dass das Anwendungsgateway standardmäßig denselben HTTP-Hostheader an das Back-End sendet, wie es vom Client empfangen wird, müssen Sie sicherstellen, dass das auf dem Back-End-Server installierte TLS-Zertifikat mit einem CNAME ausgegeben wird, der dem Hostnamen entspricht, der vom Back-End-Server im HTTP-Hostheader empfangen wird. Denken Sie daran, dass dieser Hostname, sofern nicht anders angegeben, mit dem vom Client empfangenen Hostnamen identisch ist.

Beispiel:

Stellen Sie sich vor, Sie verfügen über ein Anwendungsgateway, um die HTTPS-Anforderungen der Domain www.contoso.com zu bedienen. Möglicherweise haben Sie die Domain contoso.com an eine öffentliche Azure DNS-Zone delegiert und ein A DNS-Eintrag in dieser Zone mit www.contoso.comverweist auf die öffentliche IP des jeweiligen Anwendungsgateways, das die Anforderungen bedienen soll.

Auf diesem Application Gateway müssen Sie einen Listener für den Host www.contoso.com mit einer Regel haben, die die "Backed HTTP-Einstellung" zum Verwenden von PROTOKOLL-HTTPS erzwungen hat (Sicherstellen von End-to-End-TLS). Dieselbe Regel hat möglicherweise einen Back-End-Pool mit zwei virtuellen Computern konfiguriert, auf denen IIS als Webserver läuft.

Wie wir wissen, Aktivierung von HTTPS in der "Backed HTTP-Einstellung" der Regel macht den zweiten Teil der Kommunikation zwischen den Application Gateway Instanzen und den Servern im Back-End zur Verwendung von TLS.

Haben die Back-End-Server kein für die CNAME www.contoso.com oder *.contoso.com ausgestelltes Zertifikat, schlägt die Anforderung fehl mit Serverfehler 502 – Webserver als Gateway oder Proxyserver erhielt eine ungültige Antwort, weil das upstream-SSL-Zertifikat (das auf den Back-End-Servern installierte Zertifikat) nicht mit dem Hostnamen im Hostheader übereinstimmt, deswegen schlägt die TLS-Aushandlung fehl.

www.contoso.com --> APP GW Front-End-IP --> Listener mit einer Regel, die "Back-End-HTTP-Einstellungen" für die Verwendung von HTTPS anstelle von HTTP konfiguriert –> Back-End-Pool --> Webserver (braucht ein für www.contoso.cominstalliertes TLS-Zertifikat)

Lösung

Es ist erforderlich, dass der CNAME des auf dem Back-End-Server installierten TLS-Zertifikats mit dem Hostnamen übereinstimmt, der in den HTTP-Back-End-Einstellungen konfiguriert ist. Sonst wird der zweite Teil der End-to-End-Kommunikation, die zwischen den Instanzen des Anwendungsgateways und dem Back-End erfolgt, fehlschlagen. Es kommt die Meldung "Upstream SSL-Zertifikat stimmt nicht überein" und Serverfehler: 502 – Webserver erhielt eine ungültige Antwort, während sie als Gateway- oder Proxyserver fungiert

Nächste Schritte

Sollte sich das Problem mit den oben genannten Schritten nicht beheben lassen, erstellen Sie ein Supportticket.