Felsöka fel med felaktig gateway (502) i Azure Application Gateway

Sammanfattning

Lär dig hur du felsöker fel med felaktig gateway (502) i Azure Application Gateway så att du snabbt kan återställa tillförlitlig åtkomst till dina webbappar.

Symptoms

När du har konfigurerat en programgateway kan du se felet "Serverfel: 502 – Webbservern fick ett ogiltigt svar när den fungerade som en gateway eller proxyserver". Det kan bero på följande:

• Problem med nätverkssäkerhetsgrupp (NSG), användardefinierad routning (UDR) eller anpassad DNS
• Standardhälsoavsökningen kan inte nå backend-VM:ar
• Tidsgränsen för backend-begäran har överskridits
• Application Gateways serverdelspool är inte konfigurerad eller tom
• Felaktiga instanser i BackendAddressPool
• Det överordnade SSL-certifikatet matchar inte

Problem med nätverkssäkerhetsgrupp, användardefinierad väg eller anpassad DNS

Orsak

Om en NSG, UDR eller anpassad DNS blockerar åtkomsten till serverdelen kan programgatewayinstanser inte nå serverdelspoolen. Det här problemet orsakar sondfel, vilket resulterar i fel 502.

Du kan ha en NSG eller UDR i antingen undernätet för programgatewayen eller det undernät där de virtuella programdatorerna (VM) distribueras.

På samma sätt kan förekomsten av en anpassad DNS i det virtuella nätverket (VNet) också orsaka problem. Den användarkonfigurerade DNS-servern för det virtuella nätverket kanske inte matchar ett fullständigt kvalificerat domännamn (FQDN) som används för medlemmar i serverdelspoolen.

Lösning

Verifiera dina NSG-, UDR- och DNS-konfigurationer. Gör det genom att följa dessa steg:

1. Kontrollera de NSG:er som är associerade med programgatewayens undernät. Se till att kommunikationen till serverdelen inte blockeras. Mer information finns i Nätverkssäkerhetsgrupper.

2. Kontrollera den UDR som är kopplad till undernätet för programgatewayen. Kontrollera att UDR inte dirigerar trafik bort från serverdelsundernätet. Du kan till exempel söka efter routning till virtuella nätverksinstallationer eller standardvägar som annonseras till programgatewayundernätet med hjälp av Azure ExpressRoute eller Azure VPN. Kör följande kommandon i Azure PowerShell.

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

3. Sök efter effektiva NSG:er och vägar med den virtuella serverdelsdatorn. Kör följande kommandon i Azure PowerShell.

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

4. Kontrollera om det finns anpassad DNS i det virtuella nätverket. Kontrollera DNS genom att titta på informationen om VNet-egenskaperna i utdata.

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

5. Om det finns ska du säkerställa att DNS-servern kan lösa backend-poolmedlemmens FQDN korrekt.

Standardhälsoavsökningen kan inte nå backend-VM:ar

Orsak

Ett 502-fel kan också indikera att standardhälsoavsökningen inte kan nå virtuella serverdelsdatorer.

När du etablerar en instans av en programgateway konfigureras automatiskt en standardavsökning för hälsokontroll för varje BackendAddressPool med hjälp av egenskaperna för BackendHttpSetting.

Du behöver inte ange några indata för att ställa in den här prob. När du konfigurerar en belastningsutjämningsregel associerar du en BackendHttpSetting med en BackendAddressPool. Var och en av dessa associationer har en standardavsökning konfigurerad, och programgatewayen startar en periodisk anslutning för hälsokontroll till varje instans i BackendAddressPool via den port som anges i elementet BackendHttpSetting.

I följande tabell visas de värden som är associerade med standardhälsoavsökningen.

Lösning

Använd följande vägledning för att felsöka standardhälsoavsökningen.

• Värdvärdet för begäran är inställt på 127.0.0.1. Kontrollera att en standardwebbplats är konfigurerad och lyssnar på 127.0.0.1.
• Protokollet BackendHttpSetting avgör protokollet för begäran.
• URI-sökvägen är inställd på /*.
• Om BackendHttpSetting anger en annan port än 80 konfigurerar du standardplatsen för att lyssna på den porten.
• Anropet till protocol://127.0.0.1:port ska returnera en HTTP-resultatkod på 200. Den här koden ska returneras inom tidsgränsen på 30 sekunder.
• Kontrollera att den konfigurerade porten är öppen och att det inte finns några brandväggsregler eller Azure NSG:er som blockerar inkommande eller utgående trafik på den konfigurerade porten.
• Om du använder Azure klassiska virtuella datorer eller molntjänst med ett FQDN eller en offentlig IP-adress ska du se till att du öppnar motsvarande endpoint.
• Om du konfigurerar den virtuella datorn med hjälp av Azure Resource Manager (ARM) och den ligger utanför det virtuella nätverk där programgatewayen distribueras konfigurerar du en NSG för att tillåta åtkomst på önskad port.

Mer information finns i Konfiguration av Application Gateway-infrastruktur.

Ogiltig eller felaktig konfiguration av anpassade hälsoavsökningar

Orsak

Anpassade hälsoavsökningar ger dig mer flexibilitet än standardbeteendet för avsökning. När du använder anpassade sonder kan du ange sondintervallet, URL:en, sökvägen som ska testas och hur många misslyckade svar som kan accepteras innan du markerar back-end-poolinstansen som ohälsosam.

I följande tabell beskrivs de ytterligare egenskaper som du kan ange.

Lösning

Kontrollera att du har konfigurerat den anpassade hälsokontrollen korrekt, enligt tabellen ovan. Utöver föregående felsökningsvägledning följer du även den här vägledningen.

• Se till att du specificerar proben korrekt enligt guiden.
• Om du konfigurerar programgatewayen för en enskild plats anger du standardvärdnamnet som 127.0.0.1, om du inte konfigurerar detta på annat sätt i den anpassade avsökningen.
• Kontrollera att ett anrop till http://<host>:<port><path> returnerar en HTTP-resultatkod på 200.
• Kontrollera att Intervalvärdena , Timeoutoch UnhealthyThreshold ligger inom de godkända intervallen.
• Om du använder en HTTPS-avsökning i v2 SKU skickar Application Gateway även avsökningens värdnamn som SNI-värde. Kontrollera att värdnamnet matchar serverdelscertifikatets alternativa namn (SAN) eller dess gemensamma namn (CN) om certifikatet inte har något SAN, enligt beskrivningen i RFC 6125. Application Gateway skickar inte SNI när värdnamnet är en IP-adress, inklusive standardvärdet 127.0.0.1. Anvisningar för hur du jämför värdnamnet för avsökningen med certifikatet finns i Lösning F i Felsöka HTTP 502-fel i Azure Application Gateway. Om du inte kan ändra serverdelscertifikatet justerar du https-valideringsinställningarna för serverdelen så att det använder ett specifikt SNI-värde eller hoppar över valideringen av ämnesnamn.

Tidsgränsen för backend-begäran har överskridits

Orsak

När programgatewayen tar emot en användarbegäran tillämpar den de konfigurerade reglerna på begäran och dirigerar den till en serverdelspoolinstans. Den väntar på ett konfigurerbart tidsintervall för ett svar från serverdelsinstansen. Som standard är det här intervallet 20 sekunder. Om programgatewayen inte får något svar från serverdelsprogrammet inom det här intervallet i Application Gateway v1 får användarbegäran ett 502-fel. Om programgatewayen inte får något svar från serverdelsprogrammet inom det här intervallet i Application Gateway v2, prövas begäran mot en andra medlem i serverdelspoolen. Om den andra begäran också misslyckas får användarbegäran ett 504-fel i stället. Om användarna får 504-fel i stället för 502-fel läser du Felsöka HTTP 504-fel i Azure Application Gateway.

Om ditt serverdelsprogram rutinmässigt tar längre tid än det konfigurerade intervallet för att svara (till exempel en tidskrävande fråga eller rapport) ökar du tidsgränsen för begäran för serverdelens HTTP-inställning som används av serverdelspoolen.

Lösning

Tidsgränsen för begäran är en egenskap för HTTP-inställningen för serverdelen, så olika serverdelspooler kan ha olika tidsgränsvärden för begäranden. Öka den med hjälp av Azure-portalen, Azure CLI eller Azure PowerShell. Det godkända intervallet är 1 till 86400 sekunder. Mer information finns i Tidsgräns för begäran.

Azure portal

Följ de här stegen:

1. I Azure-portalen går du till din programgateway.
2. Under Inställningar väljer du Serverdelsinställningar.
3. Välj den serverdelsinställning som används av den berörda serverdelspoolen.
4. Öka värdet för tidsgränsen för begäran (sekunder) för att ge mer tid för serverdelen att svara.
5. Välj Spara.

Azure CLI

Kör följande kommando i Azure CLI:

az network application-gateway http-settings update \
  --gateway-name <application-gateway-name> \
  --resource-group <resource-group-name> \
  --name <backend-http-settings-name> \
  --timeout <time-out-in-seconds>

Azure PowerShell

Kör följande kommando i Azure PowerShell:

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

Application Gateways serverdelspool är inte konfigurerad eller tom

Orsak

Om programgatewayen inte har några virtuella datorer eller någon virtuella dator-skalningsuppsättning konfigurerad i serverdelsadresspoolen, kan den inte dirigera någon kundförfrågan och returnerar ett "bad gateway"-fel.

Lösning

Kontrollera att serverdelsadresspoolen inte är tom. Du kan kontrollera det här villkoret via Azure PowerShell, Azure CLI eller portalen. Se följande exempel för att kontrollera serverdelsadresspoolen via Azure PowerShell.

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

Utdata från föregående cmdlet ska innehålla en icke-tom backendadresspool. I följande exempel visas två returnerade pooler som har konfigurerats med ett FQDN eller IP-adresser för backend-VM:erna. Etableringsstatus för BackendAddressPool måste vara Succeeded.

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

Felaktiga instanser i BackendAddressPool

Orsak

Om alla instanser av BackendAddressPool är ohälsosamma har applikationsgatewayen ingen backend att dirigera användarförfrågningar till. Det här villkoret kan också inträffa när backend-instanser fungerar korrekt men inte har det nödvändiga programmet distribuerat.

Lösning

Kontrollera att instanserna är felfria och att programmet är korrekt konfigurerat. Kontrollera om serverdelsinstanserna kan svara på en ping från en annan virtuell dator i samma virtuella nätverk. Om du konfigurerar en offentlig slutpunkt kontrollerar du att en webbläsarbegäran till webbprogrammet är användbar.

Det överordnade SSL-certifikatet matchar inte

Orsak

TLS-certifikatet (Transport Layer Security) som är installerat på backendservrarna stämmer inte överens med det värdnamn som tas emot i HTTP-värdbegäranshuvudet.

I scenarier där TLS från slutpunkt till slutpunkt är aktiverat uppnår du konfigurationen genom att redigera lämpliga HTTP-inställningar för serverdelen . Ändra konfigurationen för inställningen serverdelsprotokoll till HTTPS vid behov. Kontrollera att DNS NAME för TLS-certifikatet som är installerat på backendservrarna överensstämmer med värdnamnet som skickas till backendservern i HTTP-värdhuvudet.

När du slutför det här steget krypteras den andra delen av kommunikationen mellan Application Gateway och serverdelens servrar med TLS.

Som standard skickar Application Gateway samma HTTP-värdhuvud till serverdelen som den tar emot från klienten. Kontrollera att TLS-certifikatet som är installerat på serverdelsservern har utfärdats med ett DNS NAME som matchar värdnamnet som tas emot av serverdelsservern i HTTP-värdhuvudet. Det här värdnamnet ska vara samma som det som tas emot från klienten.

Lösning

Anvisningar för hur du justerar avsökningens värdnamn och SNI med certifikatets SAN eller CN finns i Lösning F i Felsöka HTTP 502-fel i Azure Application Gateway. Mer information om hur backendinställningarna Välj värdnamn från serverdelsmål och Åsidosätt med specifikt domännamn motsvarar det certifikatnamn som Application Gateway förväntar sig finns i Vanligt namn (CN) matchar inte.