Freigeben über

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.

Hinweis

Es wird empfohlen, das Azure Az PowerShell-Modul für die Interaktion mit Azure zu verwenden. Informationen zu den ersten Schritten finden Sie unter Installieren von Azure PowerShell. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.

Ü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:

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:

Überprüfungseigenschaft Wert Beschreibung
Überprüfungs-URL http://127.0.0.1/ URL-Pfad
Intervall 30 Überprüfungsintervall in Sekunden
Zeitüberschreitung 30 Zeitüberschreitung der Überprüfung in Sekunden
Fehlerhafter Schwellenwert 3 Anzahl der Wiederholungsversuche der Überprüfung Der Back-End-Server wird als ausgefallen markiert, nachdem die Anzahl der aufeinanderfolgenden fehlerhaften Tests den Fehlerschwellenwert erreicht.

Lösung

  • Der Hostwert der Anforderung ist 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 ist festgelegt auf /
  • 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:

Überprüfungseigenschaft Beschreibung
Name Name der Überprüfung. Dieser Name wird verwendet, um in den Back-End-HTTP-Einstellungen auf den Integritätstest zu verweisen.
Protokoll Das zum Senden der Überprüfung verwendete Protokoll. Für den Integritätstest wird das in den HTTP-Einstellungen des Back-Ends festgelegte Protokoll verwendet.
Gastgeber Hostname zum Senden der Überprüfung Nur relevant, wenn in Application Gateway mehrere Standorte konfiguriert sind. Entspricht nicht dem VM-Hostnamen.
`Path` Relativer Pfad der Überprüfung. Der gültige Pfad beginnt mit „/“. Der Test wird an <Protokoll>://<Host>:<Port><Pfad> gesendet
Intervall Überprüfungsintervall in Sekunden Dies ist das Zeitintervall zwischen zwei aufeinanderfolgenden Überprüfungen.
Zeitüberschreitung Zeitüberschreitung der Überprüfung in Sekunden. Die Überprüfung wird als fehlerhaft markiert, wenn innerhalb des Zeitraums für die Zeitüberschreitung keine gültige Antwort empfangen wird.
Fehlerhafter Schwellenwert Anzahl der Wiederholungsversuche der Überprüfung Der Back-End-Server wird als ausgefallen markiert, nachdem die Anzahl der aufeinanderfolgenden fehlerhaften Tests den Fehlerschwellenwert erreicht.

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 das Anwendungsgateway v2 in diesem Intervall keine Antwort von der Backend-Anwendung empfängt, wird die Anforderung bei einem zweiten Backend-Pool-Mitglied versucht. 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.

Back-EndAddressPoolsText:

[{
    "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 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.

Als Erinnerung: Wenn in den "Backend-HTTP-Einstellungen" die Option für das Protokoll HTTPS statt HTTP aktiviert wird, hat dies zur Folge, dass der zweite Teil der Kommunikation zwischen den Instanzen des Application Gateways und den Backend-Servern mit TLS verschlüsselt wird.

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. 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.com verweist auf die öffentliche IP des jeweiligen Anwendungsgateways, das die Anforderungen bedienen soll.

Auf diesem Anwendungsgateway sollten Sie über einen Listener für den Host www.contoso.com mit einer Regel verfügen, die die "Backend-HTTP-Einstellung" so konfiguriert, dass das Protokoll HTTPS verwendet wird, um End-to-End-TLS sicherzustellen. Dieselbe Regel hat möglicherweise einen Back-End-Pool mit zwei virtuellen Computern konfiguriert, auf denen IIS als Webserver läuft.

Wie wir wissen, führt das Aktivieren von HTTPS in der "Backend-HTTP-Einstellung" der Regel dazu, dass der zweite Teil der Kommunikation zwischen den Application Gateway-Instanzen 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-Adresse --> Listener mit einer Regel, die "Backend-HTTP-Einstellungen" konfiguriert, um das Protokoll HTTPS anstelle von HTTP zu verwenden --> Backend-Pool --> Webserver (muss ein TLS-Zertifikat installiert haben für www.contoso.com)

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

Nächste Schritte

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