Dela via

Felsöka felaktig gateway i Application Gateway

  • Artikel

Lär dig hur du felsöker fel med felaktig gateway (502) som tas emot när du använder Azure Application Gateway.

Kommentar

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Information om hur du kommer igång finns i Installera Azure PowerShell. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Översikt

När du har konfigurerat en programgateway kan ett av de fel som visas vara Serverfel: 502 – Webbservern fick ett ogiltigt svar när den fungerade som en gateway eller proxyserver. Det här felet kan inträffa av följande huvudorsaker:

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

Orsak

Om åtkomsten till serverdelen blockeras på grund av en NSG, UDR eller anpassad DNS, kan programgatewayinstanser inte nå serverdelspoolen. Det här problemet orsakar avsökningsfel, vilket resulterar i 502 fel.

NSG/UDR kan finnas antingen i undernätet för programgatewayen eller i undernätet där de virtuella programdatorerna distribueras.

På samma sätt kan förekomsten av en anpassad DNS i det virtuella nätverket också orsaka problem. Ett FQDN som används för medlemmar i serverdelspoolen kanske inte matchar korrekt av den användarkonfigurerade DNS-servern för det virtuella nätverket.

Lösning

Verifiera NSG-, UDR- och DNS-konfiguration genom att gå igenom följande steg:

  1. Kontrollera NSG:er som är associerade med application gateway-undernätet. Kontrollera att kommunikationen till serverdelen inte är blockerad. Mer information finns i Nätverkssäkerhetsgrupper.

  2. Kontrollera UDR som är associerad med 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 programgatewayens undernät via ExpressRoute/VPN.

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

  3. Kontrollera effektiv NSG och dirigera med den virtuella serverdelsdatorn

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

  4. Kontrollera förekomsten av anpassad DNS i det virtuella nätverket. DNS kan kontrolleras genom att titta på information om VNet-egenskaperna i utdata.

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

  5. Om det finns ser du till att DNS-servern kan matcha serverdelspoolmedlemmens FQDN korrekt.

Problem med standardhälsoavsökning

Orsak

502-fel kan också vara vanliga indikatorer på att standardhälsoavsökningen inte kan nå virtuella serverdelsdatorer.

När en programgatewayinstans etableras konfigureras automatiskt en standardhälsoavsökning för varje BackendAddressPool med hjälp av egenskaperna för BackendHttpSetting. Inga användarindata krävs för att ställa in den här avsökningen. När en belastningsutjämningsregel konfigureras görs en association mellan en BackendHttpSetting och en BackendAddressPool. En standardavsökning konfigureras för var och en av dessa associationer och programgatewayen startar en regelbunden hälsokontrollanslutning till varje instans i BackendAddressPool vid den port som anges i elementet BackendHttpSetting.

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

Avsökningsegenskap Värde beskrivning
Avsöknings-URL http://127.0.0.1/ URL-sökväg
Intervall 30 Avsökningsintervall i sekunder
Timeout 30 Tidsgräns för avsökning i sekunder
Defekt tröskelvärde 3 Antal återförsök av avsökning. Serverdelsservern markeras nedåt efter att antalet på varandra följande avsökningsfel når tröskelvärdet för fel som inte är felfri.

Lösning

  • Värdvärdet för begäran anges till 127.0.0.1. Kontrollera att en standardwebbplats är konfigurerad och lyssnar på 127.0.0.1.
  • Protokollet för begäran bestäms av BackendHttpSetting-protokollet.
  • URI-sökvägen anges till /.
  • Om BackendHttpSetting anger en annan port än 80 ska standardplatsen konfigureras 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 Network Security Groups som blockerar inkommande eller utgående trafik på den konfigurerade porten.
  • Om klassiska Virtuella Azure-datorer eller Molntjänst används med ett FQDN eller en offentlig IP-adress kontrollerar du att motsvarande slutpunkt är öppen.
  • Om den virtuella datorn konfigureras via Azure Resource Manager och ligger utanför det virtuella nätverk där programgatewayen distribueras måste en nätverkssäkerhetsgrupp konfigureras för att tillåta åtkomst på önskad port.

Mer information finns i Konfiguration av Application Gateway-infrastruktur.

Problem med anpassad hälsoavsökning

Orsak

Anpassade hälsoavsökningar ger ytterligare flexibilitet för standardavsökningsbeteendet. När du använder anpassade avsökningar kan du konfigurera avsökningsintervallet, URL:en, sökvägen att testa och hur många misslyckade svar som kunde accepteras innan du markerade serverdelspoolinstansen som felaktig.

Följande ytterligare egenskaper läggs till:

Avsökningsegenskap beskrivning
Name Avsökningens namn. Det här namnet används för att referera till avsökningen i HTTP-inställningarna för serverdelen.
Protokoll Protokoll som används för att skicka avsökningen. Avsökningen använder protokollet som definierats i HTTP-inställningarna för serverdelen
Host Värdnamn för att skicka avsökningen. Gäller endast när flera platser har konfigurerats på programgatewayen. Detta skiljer sig från värdnamnet för den virtuella datorn.
Sökväg Avsökningens relativa sökväg. Den giltiga sökvägen börjar från '/'. Avsökningen skickas till <protocol>://<host>:<port><path>
Intervall Avsökningsintervall i sekunder. Det här är tidsintervallet mellan två på varandra följande avsökningar.
Timeout Tidsgräns för avsökning i sekunder. Om ett giltigt svar inte tas emot inom den här tidsgränsen markeras avsökningen som misslyckad.
Defekt tröskelvärde Antal återförsök av avsökning. Serverdelsservern markeras nedåt efter att antalet på varandra följande avsökningsfel når tröskelvärdet för fel som inte är felfri.

Lösning

Kontrollera att den anpassade hälsoavsökningen är korrekt konfigurerad enligt föregående tabell. Förutom de föregående felsökningsstegen kontrollerar du även följande:

  • Kontrollera att avsökningen har angetts korrekt enligt guiden.
  • Om programgatewayen har konfigurerats för en enda plats ska värdnamnet som standard anges som 127.0.0.1, om inget annat har konfigurerats i den anpassade avsökningen.
  • Kontrollera att ett anrop till http://< host>:<port-sökvägen><> returnerar en HTTP-resultatkod på 200.
  • Se till att Intervall, Timeout och UnhealtyThreshold ligger inom de godkända intervallen.
  • Om du använder en HTTPS-avsökning kontrollerar du att serverdelsservern inte kräver SNI genom att konfigurera ett återställningscertifikat på själva serverdelsservern.

Tidsgräns för begäran

Orsak

När en användarförfrågan tas emot tillämpar programgatewayen de konfigurerade reglerna på förfrågan och dirigerar den till en instans i serverdelspoolen. Den väntar på svar från serverdelsinstansen i ett konfigurerbart tidsintervall. Som standard är det här intervallet 20 sekunder. I Application Gateway v1 får användarförfrågan ett 502-fel om programgatewayen inte får något svar från programmet i serverdelen inom det här intervallet. I Application Gateway v2, om programgatewayen inte får något svar från serverdelsprogrammet i det här intervallet, kommer begäran att prövas mot en andra medlem i serverdelspoolen. Om den andra begäran misslyckas får användarbegäran ett 504-fel.

Lösning

Med Application Gateway kan du konfigurera den här inställningen via BackendHttpSetting, som sedan kan tillämpas på olika pooler. Olika serverdelspooler kan ha olika BackendHttpSetting och en annan tidsgräns för begäranden har konfigurerats.

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

Tom serverdelAddressPool

Orsak

Om programgatewayen inte har några virtuella datorer eller vm-skalningsuppsättningar konfigurerade i serverdelsadresspoolen kan den inte dirigera någon kundbegäran och skickar ett felaktigt gatewayfel.

Lösning

Kontrollera att serverdelsadresspoolen inte är tom. Detta kan göras antingen via PowerShell, CLI eller portalen.

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

Utdata från föregående cmdlet ska innehålla ingen serverdelsadresspool. I följande exempel visas två pooler som returneras som har konfigurerats med ett FQDN eller en IP-adress för de virtuella serverdelsdatorerna. Etableringstillståndet för BackendAddressPool måste vara "Lyckades".

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

Felaktiga instanser i BackendAddressPool

Orsak

Om alla instanser av BackendAddressPool inte är felfria har programgatewayen ingen serverdel att dirigera användarbegäran till. Detta kan också vara fallet när serverdelsinstanser är felfria men inte har det program som krävs 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 har konfigurerat med en offentlig slutpunkt kontrollerar du att en webbläsarbegäran till webbprogrammet är användbar.

Det överordnade SSL-certifikatet matchar inte

Orsak

TLS-certifikatet som är installerat på serverdelsservrarna matchar inte värdnamnet som tas emot i värdbegäranshuvudet.

I scenarier där TLS från slutpunkt till slutpunkt är aktiverat, en konfiguration som uppnås genom att redigera lämplig "Backend HTTP-Inställningar" och där ändra konfigurationen av inställningen "Backend protocol" till HTTPS, är det obligatoriskt att se till att CNAME för TLS-certifikatet som är installerat på serverdelsservrar matchar värdnamnet som kommer till serverdelen i BEGÄRAN om HTTP-värdhuvud.

Som en påminnelse är effekten av att aktivera alternativet "HTTP-Inställningar för serverdelen" alternativet protokoll-HTTPS i stället för HTTP, att den andra delen av kommunikationen som sker mellan instanserna av Application Gateway och serverdelsservrarna krypteras med TLS.

På grund av att Application Gateway som standard skickar samma HTTP-värdhuvud till serverdelen som den tar emot från klienten måste du se till att TLS-certifikatet som är installerat på serverdelsservern utfärdas med ett CNAME som matchar värdnamnet som tas emot av serverdelen i HTTP-värdhuvudet. Kom ihåg att om inget annat anges är värdnamnet detsamma som det som togs emot från klienten.

Till exempel:

Anta att du har en Application Gateway för att hantera https-begäranden för domän www.contoso.com. Du kan ha domänen contoso.com delegerad till en offentlig Azure DNS-zon och en DNS-post i den zonen som pekar www.contoso.com till den offentliga IP-adressen för den specifika Application Gateway som ska hantera begäranden.

På den Application Gateway ska du ha en lyssnare för värden www.contoso.com med en regel som har den "backade HTTP-inställningen" som tvingas använda protokoll-HTTPS (säkerställa TLS från slutpunkt till slutpunkt). Samma regel kunde ha konfigurerat en serverdelspool med två virtuella datorer som kör IIS som webbservrar.

Som vi vet gör aktivering av HTTPS i "Backed HTTP Setting" för regeln den andra delen av kommunikationen som sker mellan Application Gateway-instanserna och servrarna i serverdelen för att använda TLS.

Om serverdelsservrarna inte har något TLS-certifikat utfärdat för CNAME-www.contoso.com eller *.contoso.com misslyckas begäran med serverfel: 502 – Webbservern fick ett ogiltigt svar när det fungerade som en gateway eller proxyserver eftersom det överordnade SSL-certifikatet (certifikatet som installerats på serverdelsservrarna) inte matchar värdnamnet i värdhuvudet. och därför kommer TLS-förhandlingen att misslyckas.

www.contoso.com –> IP-adress för APP GW-klientdel –> Lyssnare med en regel som konfigurerar "HTTP-Inställningar för serverdelen" för att använda protokoll-HTTPS i stället för HTTP --> Serverdelspool –> Webbserver (måste ha ett TLS-certifikat installerat för www.contoso.com)

Lösning

det krävs att CNAME för TLS-certifikatet som är installerat på serverdelsservern matchar värdnamnet som konfigurerats i HTTP-serverdelsinställningarna, annars kommer den andra delen av slutpunkt-till-slutpunkt-kommunikationen som sker mellan instanserna av Application Gateway och serverdelen, att misslyckas med "Upstream SSL-certifikat matchar inte" och genererar ett serverfel: 502 – Webbservern fick ett ogiltigt svar när den fungerade som en gateway eller proxyserver

Nästa steg

Om föregående steg inte löser problemet öppnar du ett supportärende.