Fouten met ongeldige gateway oplossen in Application Gateway

Meer informatie over het oplossen van slechte gatewayfouten (502) die zijn ontvangen bij het gebruik van Azure-toepassing Gateway.

Notitie

Het wordt aanbevolen de Azure Az PowerShell-module te gebruiken om te communiceren met Azure. Zie Azure PowerShell installeren om aan de slag te gaan. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.

Overzicht

Nadat u een toepassingsgateway hebt geconfigureerd, is een van de fouten die u kunt zien serverfout: 502 - Webserver heeft een ongeldig antwoord ontvangen tijdens het fungeren als een gateway of proxyserver. Deze fout kan om de volgende hoofdredenen optreden:

• NSG, UDR of Aangepaste DNS blokkeert de toegang tot leden van de back-endpool.
• Back-end-VM's of exemplaren van virtuele-machineschaalset reageren niet op de standaardstatustest.
• Ongeldige of onjuiste configuratie van aangepaste statustests.
• Azure-toepassing de back-endpool van de gateway niet is geconfigureerd of leeg.
• Geen van de VM's of exemplaren in een virtuele-machineschaalset is in orde.
• Time-out van aanvraag of verbindingsproblemen met gebruikersaanvragen.

Probleem met netwerkbeveiligingsgroep, door de gebruiker gedefinieerde route of aangepaste DNS

Oorzaak

Als de toegang tot de back-end wordt geblokkeerd vanwege een NSG, UDR of aangepaste DNS, kunnen application gateway-exemplaren de back-endpool niet bereiken. Dit probleem veroorzaakt testfouten, wat resulteert in 502-fouten.

De NSG/UDR kan aanwezig zijn in het subnet van de toepassingsgateway of in het subnet waarin de toepassings-VM's worden geïmplementeerd.

Op dezelfde manier kan de aanwezigheid van een aangepaste DNS in het VNet ook problemen veroorzaken. Een FQDN die wordt gebruikt voor leden van de back-endpool kan mogelijk niet correct worden omgezet door de gebruiker geconfigureerde DNS-server voor het VNet.

Oplossing

Valideer de NSG-, UDR- en DNS-configuratie door de volgende stappen uit te voeren:

1. Controleer de NSG's die zijn gekoppeld aan het subnet van de toepassingsgateway. Zorg ervoor dat communicatie met back-end niet wordt geblokkeerd. Zie Netwerkbeveiligingsgroepen voor meer informatie.

2. Controleer de UDR die is gekoppeld aan het subnet van de toepassingsgateway. Zorg ervoor dat de UDR geen verkeer wegleidt van het back-endsubnet. Controleer bijvoorbeeld op routering naar virtuele netwerkapparaten of standaardroutes die worden geadverteerd naar het subnet van de toepassingsgateway via ExpressRoute/VPN.

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

3. Controleer de effectieve NSG en route met de back-end-VM

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

4. Controleer de aanwezigheid van aangepaste DNS in het VNet. DNS kan worden gecontroleerd door de details van de VNet-eigenschappen in de uitvoer te bekijken.

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

5. Als deze aanwezig is, moet u ervoor zorgen dat de DNS-server de FQDN van het back-endpoollid correct kan oplossen.

Problemen met standaardstatustest

Oorzaak

502-fouten kunnen ook frequente indicatoren zijn dat de standaardstatustest geen back-end-VM's kan bereiken.

Wanneer een exemplaar van een toepassingsgateway is ingericht, wordt automatisch een standaardstatustest geconfigureerd voor elke BackendAddressPool met behulp van eigenschappen van de BackendHttpSetting. Er is geen gebruikersinvoer vereist om deze test in te stellen. Wanneer een taakverdelingsregel is geconfigureerd, wordt er een koppeling gemaakt tussen een BackendHttpSetting en een BackendAddressPool. Er wordt een standaardtest geconfigureerd voor elk van deze koppelingen en de toepassingsgateway start een periodieke statuscontroleverbinding met elk exemplaar in de BackendAddressPool op de poort die is opgegeven in het element BackendHttpSetting.

De volgende tabel bevat de waarden die zijn gekoppeld aan de standaardstatustest:

Testeigenschap	Weergegeven als	Beschrijving
Test-URL	http://127.0.0.1/	URL-pad
Interval	30	Testinterval in seconden
Time-out	30	Time-out van test in seconden
Drempelwaarde voor beschadigde status	3	Aantal nieuwe pogingen voor de test. De back-endserver wordt gemarkeerd nadat het aantal opeenvolgende testfouten de drempelwaarde voor beschadigde status heeft bereikt.

Oplossing

• De hostwaarde van de aanvraag wordt ingesteld op 127.0.0.1. Zorg ervoor dat een standaardsite is geconfigureerd en luistert op 127.0.0.1.
• Het protocol van de aanvraag wordt bepaald door het protocol BackendHttpSetting.
• Het URI-pad wordt ingesteld op /.
• Als BackendHttpSetting een andere poort dan 80 opgeeft, moet de standaardsite worden geconfigureerd om naar die poort te luisteren.
• De aanroep om protocol://127.0.0.1:port een HTTP-resultaatcode van 200 te retourneren. Deze code moet worden geretourneerd binnen de time-outperiode van 30 seconden.
• Zorg ervoor dat de geconfigureerde poort is geopend en dat er geen firewallregels of Azure-netwerkbeveiligingsgroepen zijn die binnenkomend of uitgaand verkeer blokkeren op de poort die is geconfigureerd.
• Als klassieke Azure-VM's of cloudservice worden gebruikt met een FQDN of een openbaar IP-adres, moet u ervoor zorgen dat het bijbehorende eindpunt wordt geopend.
• Als de VIRTUELE machine is geconfigureerd via Azure Resource Manager en zich buiten het VNet bevindt waar de toepassingsgateway wordt geïmplementeerd, moet een netwerkbeveiligingsgroep worden geconfigureerd om toegang op de gewenste poort toe te staan.

Zie De configuratie van de infrastructuur van Application Gateway voor meer informatie.

Problemen met aangepaste statustest

Oorzaak

Aangepaste statustests bieden extra flexibiliteit voor het standaardgedrag voor testen. Wanneer u aangepaste tests gebruikt, kunt u het testinterval, de URL, het te testen pad en hoeveel mislukte antwoorden moeten worden geaccepteerd voordat u het exemplaar van de back-endpool als beschadigd markeert.

De volgende aanvullende eigenschappen worden toegevoegd:

Testeigenschap	Description
Naam	Naam van de test. Deze naam wordt gebruikt om te verwijzen naar de test in de HTTP-instellingen van de back-end.
Protocol	Protocol dat wordt gebruikt om de test te verzenden. De test maakt gebruik van het protocol dat is gedefinieerd in de HTTP-instellingen van de back-end
Host	Hostnaam voor het verzenden van de test. Alleen van toepassing wanneer meerdere sites zijn geconfigureerd op de toepassingsgateway. Dit verschilt van de hostnaam van de VIRTUELE machine.
Pad	Relatief pad van de test. Het geldige pad begint met '/'. De test wordt verzonden naar <protocol>://<host>:<poortpad><>
Interval	Testinterval in seconden. Dit is het tijdsinterval tussen twee opeenvolgende tests.
Time-out	Time-out van de test in seconden. Als er binnen deze time-outperiode geen geldig antwoord wordt ontvangen, wordt de test gemarkeerd als mislukt.
Drempelwaarde voor beschadigde status	Aantal nieuwe pogingen voor de test. De back-endserver wordt gemarkeerd nadat het aantal opeenvolgende testfouten de drempelwaarde voor beschadigde status heeft bereikt.

Oplossing

Controleer of de aangepaste statustest juist is geconfigureerd, zoals wordt weergegeven in de voorgaande tabel. Naast de voorgaande stappen voor probleemoplossing moet u ook het volgende controleren:

• Zorg ervoor dat de test correct is opgegeven volgens de handleiding.
• Als de toepassingsgateway is geconfigureerd voor één site, moet standaard de hostnaam worden opgegeven als 127.0.0.1, tenzij anders geconfigureerd in aangepaste test.
• Zorg ervoor dat een aanroep naar http://< host>:<port><path> een HTTP-resultaatcode van 200 retourneert.
• Zorg ervoor dat Interval, Time-out en UnhealtyThreshold binnen de acceptabele bereiken vallen.
• Als u een HTTPS-test gebruikt, moet u ervoor zorgen dat de back-endserver geen SNI vereist door een terugvalcertificaat te configureren op de back-endserver zelf.

Time-out aanvragen

Oorzaak

Wanneer een gebruikersaanvraag wordt ontvangen, past de toepassingsgateway de geconfigureerde regels toe op de aanvraag en stuurt deze door naar een exemplaar van de back-endpool. Er wordt gewacht op een configureerbaar tijdsinterval voor een antwoord van het back-endexemplaren. Dit interval is standaard 20 seconden. Als in Application Gateway V1 de toepassingsgateway in deze interval geen antwoord van de back-endtoepassing ontvangt, krijgt de gebruikersaanvraag een 502-fout. Als in Application Gateway v2 de toepassingsgateway in dit interval geen antwoord van de back-endtoepassing ontvangt, wordt de aanvraag geprobeerd tegen een tweede lid van de back-endpool. Als de tweede aanvraag mislukt, krijgt de gebruikersaanvraag een 504-fout.

Oplossing

Met Application Gateway kunt u deze instelling configureren via de BackendHttpSetting, die vervolgens kan worden toegepast op verschillende pools. Verschillende back-endpools kunnen verschillende BackendHttpSetting hebben en een andere time-out voor aanvragen geconfigureerd.

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

Lege BackendAddressPool

Oorzaak

Als de toepassingsgateway geen VM's of virtuele-machineschaalsets heeft geconfigureerd in de back-endadresgroep, kan er geen klantaanvraag worden gerouteerd en wordt er een ongeldige gatewayfout verzonden.

Oplossing

Zorg ervoor dat de back-endadresgroep niet leeg is. Dit kan via PowerShell, CLI of portal.

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

De uitvoer van de voorgaande cmdlet moet geenmpty back-endadresgroep bevatten. In het volgende voorbeeld ziet u twee pools die zijn geconfigureerd met een FQDN of een IP-adres voor de back-end-VM's. De inrichtingsstatus van de BackendAddressPool moet geslaagd zijn.

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"
}]

Beschadigde exemplaren in BackendAddressPool

Oorzaak

Als alle exemplaren van BackendAddressPool niet in orde zijn, heeft de toepassingsgateway geen back-end waarnaar de gebruikersaanvraag moet worden doorgestuurd. Dit kan ook het geval zijn wanneer back-endinstanties in orde zijn, maar niet de vereiste toepassing hebben geïmplementeerd.

Oplossing

Zorg ervoor dat de exemplaren in orde zijn en dat de toepassing correct is geconfigureerd. Controleer of de back-endinstanties kunnen reageren op een ping vanaf een andere VIRTUELE machine in hetzelfde VNet. Als deze is geconfigureerd met een openbaar eindpunt, moet u ervoor zorgen dat een browseraanvraag voor de webtoepassing kan worden gebruikt.

Upstream SSL-certificaat komt niet overeen

Oorzaak

Het TLS-certificaat dat is geïnstalleerd op back-endservers komt niet overeen met de hostnaam die is ontvangen in de header van de hostaanvraag.

In scenario's waarin End-to-end TLS is ingeschakeld, is een configuratie die wordt bereikt door de juiste 'Back-end HTTP-Instellingen' te bewerken en daar de configuratie van de instelling 'Back-endprotocol' te wijzigen in HTTPS, verplicht om ervoor te zorgen dat de CNAME van het TLS-certificaat dat op back-endservers is geïnstalleerd, overeenkomt met de hostnaam die in de HTTP-hostheaderaanvraag naar de back-end wordt verzonden.

Ter herinnering, het effect van het inschakelen van de back-end HTTP-Instellingen de optie van protocol HTTPS in plaats van HTTP, is dat het tweede deel van de communicatie tussen de exemplaren van de Application Gateway en de back-endservers wordt versleuteld met TLS.

Als gevolg van het feit dat application gateway standaard dezelfde HTTP-hostheader naar de back-end verzendt als ontvangen van de client, moet u ervoor zorgen dat het TLS-certificaat dat op de back-endserver is geïnstalleerd, wordt uitgegeven met een CNAME die overeenkomt met de hostnaam die is ontvangen door die back-endserver in de HTTP-hostheader. Houd er rekening mee dat deze hostnaam, tenzij anders is opgegeven, hetzelfde is als de hostnaam die van de client is ontvangen.

Voorbeeld:

Stel dat u een Application Gateway hebt om de https-aanvragen voor domein-www.contoso.com te verwerken. U kunt het domein contoso.com gedelegeerd aan een openbare Azure DNS-zone en een A DNS-record in die zone die www.contoso.com verwijst naar het openbare IP-adres van de specifieke toepassingsgateway die de aanvragen gaat verwerken.

Op die Application Gateway moet u een listener hebben voor de host www.contoso.com met een regel waarvoor de 'ondersteunde HTTP-instelling' is gedwongen protocol HTTPS te gebruiken (zodat end-to-end TLS wordt gegarandeerd). Dezelfde regel kan een back-endpool hebben geconfigureerd met twee virtuele machines waarop IIS wordt uitgevoerd als webservers.

Zoals we weten dat het inschakelen van HTTPS in de 'Ondersteunde HTTP-instelling' van de regel het tweede deel van de communicatie tussen de Application Gateway-exemplaren en de servers in de back-end maakt om TLS te gebruiken.

Als de back-endservers geen TLS-certificaat hebben uitgegeven voor de CNAME-www.contoso.com of *.contoso.com, mislukt de aanvraag met Serverfout: 502 - Webserver heeft een ongeldig antwoord ontvangen tijdens het fungeren als een gateway of proxyserver omdat het upstream SSL-certificaat (het certificaat dat op de back-endservers is geïnstalleerd) niet overeenkomt met de hostnaam in de hostheader, en daarom mislukt de TLS-onderhandeling.

www.contoso.com --> FRONT-END-IP van APP GW --> Listener met een regel waarmee 'Back-end-HTTP-Instellingen' wordt geconfigureerd voor het gebruik van protocol HTTPS in plaats van HTTP --> Back-endpool -> Webserver (er moet een TLS-certificaat zijn geïnstalleerd voor www.contoso.com)

Oplossing

het is vereist dat de CNAME van het TLS-certificaat dat is geïnstalleerd op de back-endserver, overeenkomt met de hostnaam die is geconfigureerd in de HTTP-back-endinstellingen, anders mislukt het tweede deel van de end-to-end-communicatie tussen de exemplaren van de Application Gateway en de back-end, mislukt met 'Upstream SSL-certificaat komt niet overeen', en wordt een serverfout geretourneerd: 502 - Webserver heeft een ongeldig antwoord ontvangen tijdens het fungeren als een gateway of proxyserver

Volgende stappen

Als het probleem niet wordt opgelost met de voorgaande stappen, opent u een ondersteuningsticket.