Problembehandlung bei schlechtem Gateway (502) in Azure Application Gateway

Zusammenfassung

Erfahren Sie, wie Sie Bad Gateway-Fehler (502) in Azure Application Gateway beheben, um den Zugriff auf Ihre Web-Apps schnell und zuverlässig wiederherzustellen.

Symptome

Nachdem Sie ein Anwendungsgateway konfiguriert haben, wird möglicherweise der Fehler Serverfehler 502 angezeigt: Webserver hat eine ungültige Antwort empfangen, während sie als Gateway oder Proxyserver fungiert. Dieser Fehler kann aus einem der folgenden Gründe auftreten:

• Netzwerksicherheitsgruppe (Network Security Group, NSG), benutzerdefinierte Route (UDR) oder benutzerdefiniertes DNS-Problem.
• Die Standardintegritätssonde kann keine Back-End-VMs erreichen.
• Anforderungs-Timeout oder Verbindungsprobleme bei Benutzeranforderungen.
• Der Back-End-Pool des Anwendungsgateways ist nicht konfiguriert oder leer.
• Fehlerhafte Instanzen in Back-EndAddressPool.
• Das Upstream-SSL-Zertifikat stimmt nicht überein.

Netzwerksicherheitsgruppe, benutzerdefinierte Route oder benutzerdefiniertes DNS-Problem

Ursache

Wenn ein NSG-, UDR- oder benutzerdefinierter DNS-Zugriff auf das Back-End blockiert, können Anwendungsgatewayinstanzen den Back-End-Pool nicht erreichen. Dieses Problem verursacht Probefehler, was zu 502 Fehlern führt.

Der NSG/UDR kann entweder im Anwendungsgateway-Subnetz oder im Subnetz vorhanden sein, in dem die Anwendungs-VMs bereitgestellt werden.

Ebenso kann das Vorhandensein eines benutzerdefinierten DNS im VNet auch Probleme verursachen. Ein FQDN, der für Back-End-Poolmitglieder verwendet wird, kann vom vom Benutzer konfigurierten DNS-Server für das VNet möglicherweise nicht ordnungsgemäß aufgelöst werden.

Lösung

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

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

2. Überprüfen Sie das UDR, das dem Anwendungsgateway-Subnetz zugeordnet ist. Stellen Sie sicher, dass die benutzerdefinierte Route (UDR) nicht den ausgehenden Datenverkehr vom Back-End-Subnetz umleitet. Überprüfen Sie z. B. das Routing an virtuelle Netzwerkgeräte oder Standardrouten, die über ExpressRoute/VPN an das Anwendungsgateway-Subnetz angekündigt werden.

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

3. Überprüfen Sie die wirksame NSG und die Route mit der Backend-VM.

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

4. Überprüfen Des Vorhandenseins von benutzerdefiniertem DNS im VNet. Überprüfen Sie DNS, indem Sie Details zu den VNet-Eigenschaften in der Ausgabe prüfen.

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

5. Wenn vorhanden, stellen Sie sicher, dass der DNS-Server den FQDN des Mitglieds des Backend-Pools ordnungsgemäß auflösen kann.

Standard-Gesundheitsprüfung kann Backend-VMs nicht erreichen

Ursache

502-Fehler können auch darauf hinweisen, dass die Standardintegritätsuntersuchung keine Back-End-VMs erreichen kann.

Wenn Sie eine Application Gateway-Instanz bereitstellen, wird automatisch eine Standardintegritätssonde für jeden BackendAddressPool mithilfe der Eigenschaften der BackendHttpSettings konfiguriert. Sie müssen keine Eingabe bereitstellen, um diese Sonde einzustellen. Wenn Sie eine Lastenausgleichsregel konfigurieren, ordnen Sie ein Back-EndHttpSetting einem Back-EndAddressPool zu. Jede dieser Zuordnungen hat eine Standardprobe konfiguriert, und das Anwendungs-Gateway startet eine Verbindung zur regelmäßigen Überprüfung des Zustands zu jeder Instanz im BackendAddressPool an dem im BackendHttpSetting-Element angegebenen Port.

In der folgenden Tabelle sind die Werte aufgeführt, die der Standardintegritätssonde zugeordnet sind:

Lösung

• Der Hostwert der Anforderung ist auf 127.0.0.1 festgelegt. Stellen Sie sicher, dass eine Standardwebsite konfiguriert ist und auf 127.0.0.1 läuft.
• Das Back-EndHttpSetting-Protokoll bestimmt das Protokoll der Anforderung.
• Der URI Path ist auf /* gesetzt.
• Wenn Back-EndHttpSetting einen anderen Port als 80 angibt, konfigurieren Sie die Standardwebsite, um an diesem Port zu lauschen.
• Der Aufruf von protocol://127.0.0.1:port sollte einen HTTP-Ergebniscode von 200 zurückgeben. Dieser Code sollte innerhalb des 30-Sekunden-Timeoutzeitraums zurückgegeben werden.
• Stellen Sie sicher, dass der konfigurierte Port geöffnet ist und es keine Firewallregeln oder Azure Netzwerksicherheitsgruppen gibt, die eingehenden oder ausgehenden Datenverkehr für den Port blockieren.
• Wenn Sie Azure klassischen VMs oder Clouddienst mit einem FQDN oder einer öffentlichen IP verwenden, stellen Sie sicher, dass Sie den entsprechenden endpoint öffnen.
• Wenn Sie den virtuellen Computer über Azure Resource Manager konfigurieren und sich außerhalb des VNet befinden, in dem das Anwendungsgateway bereitgestellt wird, müssen Sie eine Network-Sicherheitsgruppe konfigurieren, um den Zugriff auf den gewünschten Port zu ermöglichen.

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

Ungültige oder fehlerhafte Konfiguration von benutzerdefinierten Integritätssonden

Ursache

Benutzerdefinierte Gesundheitsprüfungen bieten Ihnen mehr Flexibilität als das Standardverhalten bei der Überprüfung. Wenn Sie benutzerdefinierte Probes verwenden, können Sie das Abfrageintervall, die URL und den zu testenden Pfad festlegen. Zudem können Sie bestimmen, wie viele fehlgeschlagene Antworten akzeptiert werden, bevor die Back-End-Poolinstanz als fehlerhaft markiert wird.

In der folgenden Tabelle werden die zusätzlichen Eigenschaften beschrieben, die Sie festlegen können:

Lösung

Überprüfen Sie, ob Sie den benutzerdefinierten Integritätstest ordnungsgemäß konfiguriert haben, wie in der vorherigen Tabelle dargestellt. Stellen Sie zusätzlich zu den vorherigen Schritten zur Problembehandlung auch die folgenden Schritte sicher:

• Stellen Sie sicher, dass Sie die Sonde entsprechend der Anleitung richtig angeben.
• Wenn Sie das Anwendungsgateway für einen einzelnen Standort konfigurieren, geben Sie den Standardhostnamen als 127.0.0.1 an, es sei denn, Sie konfigurieren dies in der benutzerdefinierten Überprüfung anders.
• Stellen Sie sicher, dass ein Aufruf einen http://<host>:<port><path> HTTP-Ergebniscode von 200 zurückgibt.
• Stellen Sie sicher, dass die Werte "Interval", "Timeout" und "UnhealthyThreshold" innerhalb der zulässigen Bereiche liegen.
• Wenn Sie eine HTTPS-Probe verwenden, stellen Sie sicher, dass der Back-End-Server SNI nicht erfordert, indem Sie ein Fallbackzertifikat auf dem Back-End-Server selbst konfigurieren.

Zeitüberschreitungs- oder Verbindungsprobleme bei Benutzeranforderungen

Ursache

Wenn das Anwendungsgateway eine Benutzeranforderung empfängt, wendet es die konfigurierten Regeln auf die Anforderung an und leitet sie an eine Back-End-Poolinstanz weiter. Es wartet auf ein konfigurierbares Zeitintervall für eine Antwort aus der Back-End-Instanz. Dieses Intervall beträgt standardmäßig 20 Sekunden. Wenn das Anwendungsgateway v1 in diesem Intervall keine Antwort von der Back-End-Anwendung empfängt, erhält die Benutzeranforderung einen Fehler von 502. Wenn das Anwendungsgateway v2 in diesem Intervall keine Antwort von der Back-End-Anwendung empfängt, wird die Anforderung an ein zweites Back-End-Poolmitglied weitergeleitet. Wenn die zweite Anforderung fehlschlägt, erhält die Benutzeranforderung einen Fehler von 504.

Lösung

Sie können diese Einstellung über das Back-EndHttpSetting konfigurieren, das Sie auf verschiedene Pools anwenden können. Verschiedene Back-End-Pools können unterschiedliche Back-EndHttpSetting-Konfigurationen und unterschiedliche Anforderungstimeouteinstellungen aufweisen.

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

Der Back-End-Pool des Anwendungsgateways ist nicht konfiguriert oder leer.

Ursache

Wenn das Anwendungsgateway keine VMs oder VM-Skalierungsgruppen im Back-End-Adresspool konfiguriert hat, kann es keine Kundenanfrage weiterleiten und eine Bad Gateway-Fehlermeldung senden.

Lösung

Stellen Sie sicher, dass der Back-End-Adresspool nicht leer ist. Sie können diese Bedingung über PowerShell, CLI oder das Portal überprüfen.

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

Die Ausgabe des vorhergehenden Cmdlets sollte einen nicht leeren Backend-Adresspool enthalten. Das folgende Beispiel zeigt zwei zurückgegebene Pools, die mit einem FQDN oder IP-Adressen für die Back-End-VMs konfiguriert sind. Der Bereitstellungsstatus des Back-EndAddressPools muss sein Succeeded.

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 Backend-Adresspool

Ursache

Wenn alle Instanzen von BackendAddressPool fehlerhaft sind, hat das Anwendungsgateway kein funktionierendes Back-End, um Benutzeranforderungen weiterzuleiten. Diese Bedingung kann auch auftreten, wenn Backend-Instanzen funktionsfähig sind, aber die erforderliche Anwendung nicht bereitgestellt ist.

Lösung

Stellen Sie sicher, dass die Instanzen fehlerfrei sind und die Anwendung ordnungsgemäß konfiguriert ist. Überprüfen Sie, ob die Back-End-Instanzen auf einen Ping von einem anderen virtuellen Computer im selben virtuellen Netzwerk reagieren können. Wenn Sie einen öffentlichen Endpunkt konfigurieren, stellen Sie sicher, dass eine Browseranforderung an die Webanwendung dienstbar ist.

Vorgelagertes SSL-Zertifikat stimmt nicht überein

Ursache

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

In Szenarien, in denen End-to-End-TLS aktiviert ist, eine Konfiguration, die durch Bearbeiten der entsprechenden "Back-End-HTTP-Einstellungen" erreicht wird und die Konfiguration der Einstellung "Back-End-Protokoll" auf HTTPS geändert wird, ist es obligatorisch, sicherzustellen, dass der DNS-NAME des tls-Zertifikats, das auf Back-End-Servern installiert ist, dem Hostnamen entspricht, der in der HTTP-Hostheaderanforderung zum Back-End kommt.

Wenn Sie als Erinnerung in den 'Backend-HTTP-Einstellungen' die Option für das Protokoll HTTPS anstelle von HTTP aktivieren, 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 er vom Client empfängt, müssen Sie sicherstellen, dass das auf dem Back-End-Server installierte TLS-Zertifikat mit einem DNS-NAMEN 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, das die HTTPS-Anforderungen für die Domäne www.contoso.combedient. Sie könnten die Domäne contoso.com an eine Azure DNS öffentliche Zone delegiert haben, und einen DNS-Eintrag in dieser Zone, der www.contoso.com auf die öffentliche IP des spezifischen Anwendungsgateways verweist, das die Anforderungen bedient.

Auf diesem Anwendungsgateway sollten Sie einen Listener für den Host www.contoso.com mit einer Regel haben, die die "Backend-HTTP-Einstellung" zwingt, das Protokoll HTTPS zu verwenden (um End-to-End-TLS sicherzustellen). Dieselbe Regel könnte einen Back-End-Pool mit zwei virtuellen Computern konfiguriert haben, auf denen IIS als Webserver ausgeführt wird.

Wie wir wissen, aktiviert die Aktivierung von HTTPS in der "Backed HTTP-Einstellung" der Regel, dass der zweite Teil der Kommunikation zwischen den Anwendungsgatewayinstanzen und den Servern im Backend TLS verwendet.

Wenn die Back-End-Server kein TLS-Zertifikat für den DNS-NAMEN www.contoso.com oder *.contoso.com ausgestellt haben, schlägt die Anforderung mit Dem Serverfehler 502 fehl: Webserver hat eine ungültige Antwort erhalten, während sie als Gateway oder Proxyserver fungiert , da das upstream-SSL-Zertifikat (das auf den Back-End-Servern installierte Zertifikat) nicht mit dem Hostnamen im Hostheader übereinstimmt. daher schlägt die TLS-Aushandlung fehl.

www.contoso.com --> APP GW Front-End-IP --> Listener mit einer Regel, die die "Back-End-HTTP-Einstellungen" so konfiguriert, dass das Protokoll HTTPS anstelle von HTTP verwendet wird --> Back-End-Pool --> Webserver (muss über ein installiertes TLS-Zertifikat für www.contoso.com verfügen)

Lösung

Es ist erforderlich, dass der DNS-NAME des auf dem Back-End-Server installierten TLS-Zertifikats mit dem Hostnamen übereinstimmt, der in den HTTP-Back-End-Einstellungen konfiguriert ist, andernfalls der zweite Teil der End-to-End-Kommunikation, die zwischen den Instanzen des Anwendungsgateways und dem Back-End erfolgt, schlägt mit "Upstream SSL-Zertifikat stimmt nicht überein", und löst einen Serverfehler zurück: 502 – Webserver erhielt eine ungültige Antwort, während sie als Gateway- oder Proxyserver fungiert