Felsöka problem med hälsotillstånd i serverdelen i Application Gateway

  • Artikel

Översikt

Azure Application Gateway pingar som standard servrar i serverdelen för att kontrollera deras hälsostatus och att de är redo att hantera förfrågningar. Användare kan också skapa anpassade avsökningar för att nämna värdnamnet, sökvägen som ska avsökas och statuskoderna som ska godkännas som Felfri. Om backend-servern inte svarar korrekt markerar Application Gateway servern som Inte felfri och slutar vidarebefordra begäranden till servern. När servern har börjat svara återupptar Application Gateway vidarebefordran av begäranden.

Så här kontrollerar du serverdelshälsan

Om du vill kontrollera hälsotillståndet för serverdelspoolen kan du använda sidan Hälsotillstånd för serverdelen på Azure Portal. Du kan också använda Azure PowerShell, CLI eller REST API.

Statusen som hämtas av någon av dessa metoder kan vara något av följande tillstånd:

  • Felfri
  • Ohälsosamt
  • Okänt

Application Gateway vidarebefordrar en begäran till en server från serverdelspoolen om dess status är felfri. Om alla servrar i en serverdelspool är felfria eller okända kan klienterna stöta på problem med att komma åt serverdelsprogrammet. Läs vidare för att förstå de olika meddelanden som rapporterats av Backend Health, deras orsaker och deras lösning.

Kommentar

Om användaren inte har behörighet att se status för No results. serverdelens hälsotillstånd visas.

Hälsotillstånd för serverdelen: Inte felfri

Om serverdelens hälsostatus är Inte felfri liknar portalvyn följande skärmbild:

Application Gateway backend health - Unhealthy

Om du använder en Azure PowerShell-, CLI- eller Azure REST API-fråga får du ett svar som liknar följande exempel:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

När du får en serverstatus som inte är felfri för alla servrar i en serverdelspool vidarebefordras inte begäranden till servrarna och Application Gateway returnerar felet "502 Felaktig gateway" till den begärande klienten. Om du vill felsöka det här problemet kontrollerar du kolumnen Information på fliken Hälsotillstånd för serverdelen.

Meddelandet som visas i kolumnen Information ger mer detaljerade insikter om problemet, och baserat på den informationen kan du börja felsöka problemet.

Kommentar

Standardavsökningsbegäran skickas i formatet <protocol>://127.0.0.1:<port>. Till exempel http://127.0.0.1:80 för en HTTP-avsökning på port 80. Endast HTTP-statuskoder på 200 till 399 anses vara felfria. Protokollet och målporten ärvs från HTTP-inställningarna. Om du vill att Application Gateway ska avsöka ett annat protokoll, värdnamn eller sökväg och identifiera en annan statuskod som Felfri konfigurerar du en anpassad avsökning och associerar den med HTTP-inställningarna.

Felmeddelanden

Tidsgräns för serverdelsserver

Meddelande: Den tid det tar för serverdelen att svara på programgatewayens hälsoavsökning överstiger tröskelvärdet för timeout i avsökningsinställningen.

Orsak: När Application Gateway skickar en HTTP(S)-avsökningsförfrågan till serverdelen inväntas ett svar från serverdelen under en konfigurerad tidsperiod. Om serverdelen inte svarar inom den konfigurerade tidsperioden (tidsgränsvärdet) markeras den som felaktig tills den börjar svara inom den konfigurerade tidsperioden igen.

Lösning: Kontrollera varför serverdelen eller programmet inte svarar inom den konfigurerade tidsgränsen och kontrollera även programberoendena. Kontrollera till exempel om databasen har några problem som kan utlösa en fördröjning i svaret. Om du är medveten om programmets beteende och det bör svara först efter timeout-värdet ökar du timeout-värdet från de anpassade avsökningsinställningarna. Du måste ha en anpassad avsökning för att ändra timeout-värdet. Information om hur du konfigurerar en anpassad avsökning finns på dokumentationssidan.

Följ dessa steg för att öka timeout-värdet:

  1. Öppna serverdelsservern direkt och kontrollera den tid det tar för servern att svara på den sidan. Du kan använda valfritt verktyg för att komma åt serverdelsservern, inklusive en webbläsare med hjälp av utvecklarverktyg.
  2. När du har listat ut hur mycket tid det tar för programmet att svara väljer du fliken Hälsoavsökningar och väljer sedan den avsökning som är associerad med dina HTTP-inställningar.
  3. Ange ett timeout-värde som är större än programmets svarstid i sekunder.
  4. Spara de anpassade avsökningsinställningarna och kontrollera om serverdelshälsan visas som Felfri nu.

DNS-matchningsfel

Meddelande: Application Gateway kunde inte skapa någon avsökning för den här serverdelen. Detta inträffar vanligtvis när det fullständiga domännamnet (FQDN) för serverdelen inte har angetts på korrekt sätt. 

Orsak: Om serverdelspoolen är av typen IP-adress, FQDN (fullständigt domännamn) eller App Service matchar Application Gateway IP-adressen för det fullständiga domännamn som angetts via DNS (anpassad eller Azure-standard). Application Gateway försöker sedan ansluta till servern på den TCP-port som anges i HTTP-inställningarna. Om det här meddelandet visas tyder det dock på att programgateway inte kunde matcha IP-adressen för serverdelens FQDN.

Lösning:

  1. Kontrollera att FQDN som angetts i serverdelspoolen är korrekt och att det är en offentlig domän och försök sedan matcha det från den lokala datorn.
  2. Om du kan matcha IP-adressen kan det vara något fel på DNS-konfigurationen i det virtuella nätverket.
  3. Kontrollera om det virtuella nätverket har konfigurerats med en anpassad DNS-server. Om så är fallet kontrollerar du DNS-servern om varför den inte kan matcha IP-adressen för angivna FQDN.
  4. Om du använder Azures standard-DNS kontrollerar du med domännamnsregistratorn om korrekt mappning av en post eller CNAME-post har slutförts.
  5. Om domänen är privat eller intern kan du försöka lösa den från en virtuell dator i samma virtuella nätverk. Om du kan lösa det startar du om programgateway och kontrollerar igen. Om du vill starta om programgateway måste du stoppa och starta med hjälp av PowerShell-kommandona som beskrivs i dessa länkade resurser.

TCP-anslutningsfel

Meddelande: Application Gateway kunde inte ansluta till serverdelen. Kontrollera att serverdelen svarar på den port som används för avsökningen. Kontrollera också om NSG/UDR/Firewall blockerar åtkomsten till IP-adressen och porten för den här serverdelen.

Orsak: Efter DNS-matchningsfasen försöker Application Gateway ansluta till serverdelen på den TCP-port som konfigureras i HTTP-inställningarna. Om Application Gateway inte kan upprätta en TCP-session på den angivna porten markeras avsökningen som Inte felfri med det här meddelandet.

Lösning: Följ dessa steg om du får det här felet:

  1. Kontrollera om du kan ansluta till serverdelsservern på den port som anges i HTTP-inställningarna med hjälp av en webbläsare eller PowerShell. Kör till exempel följande kommando: Test-NetConnection -ComputerName www.bing.com -Port 443.

  2. Om porten som nämns inte är önskad port anger du rätt portnummer för Att Application Gateway ska ansluta till serverdelsservern.

  3. Om du inte kan ansluta på porten från den lokala datorn också:

    a. Kontrollera nätverkssäkerhetsgruppens inställningar (NSG) för serverdelsserverns nätverkskort och undernät och om inkommande anslutningar till den konfigurerade porten är tillåtna. Om de inte är det skapar du en ny regel för att tillåta anslutningarna. Information om hur du skapar NSG-regler finns på dokumentationssidan.

    b. Kontrollera om NSG-inställningarna för Application Gateway-undernätet tillåter utgående offentlig och privat trafik, så att en anslutning kan upprättas. Kontrollera dokumentsidan som finns i steg 3a för att lära dig mer om hur du skapar NSG-regler.

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

    c. Kontrollera inställningarna för användardefinierade vägar (UDR) för Application Gateway och serverdelsserverns undernät för eventuella routningsavvikelser. Kontrollera att UDR inte dirigerar trafiken bort från serverdelsundernätet. Kontrollera till exempel vägar till virtuella nätverksenheter eller standardvägar som annonseras till Application Gateway-undernätet via Azure ExpressRoute och/eller VPN.

    d. Om du vill kontrollera de effektiva vägarna och reglerna för ett nätverkskort kan du använda följande PowerShell-kommandon:

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

  4. Om du inte hittar några problem med NSG eller UDR kontrollerar du om det finns programrelaterade problem på serverdelsservern som hindrar klienter från att upprätta en TCP-session på de portar som konfigurerats. Några saker att kontrollera:

    a. Öppna en kommandotolk (Win+R –> cmd), ange netstat och välj Retur.

    b. Kontrollera om servern lyssnar på den port som är konfigurerad. Till exempel:

            Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4

    c. Om den inte lyssnar på den konfigurerade porten kontrollerar du inställningarna för webbservern. Till exempel: platsbindningar i IIS, serverblock i NGINX och virtuell värd i Apache.

    d. Kontrollera inställningarna för operativsystemets brandvägg för att se till att inkommande trafik till porten tillåts.

HTTP-statuskod matchar inte

Meddelande: Statuskoden för serverdelens HTTP-svar matchade inte avsökningsinställningen. Förväntat:{HTTPStatusCode0} mottaget:{HTTPStatusCode1}.

Orsak: När TCP-anslutningen har upprättats och TLS-handskakningen är klar (om TLS är aktiverat) skickar Application Gateway avsökningen som en HTTP GET-begäran till serverdelen. Som tidigare beskrivits är standardavsökningen till , och den tar hänsyn till <protocol>://127.0.0.1:<port>/svarsstatuskoder i intervallet 200 till 399 som Felfri. Om servern returnerar någon annan statuskod markeras den som Inte felfri med det här meddelandet.

Lösning: Beroende på serverdelsserverns svarskod kan du utföra följande steg. Några av de vanliga statuskoderna visas här:

Fel Åtgärder
Matchningsfel för avsökningsstatuskod: Mottagen 401 Kontrollera om serverdelsservern kräver autentisering. Application Gateway-avsökningar kan inte skicka autentiseringsuppgifter för autentisering. Tillåt antingen "HTTP 401" i en avsökningsstatuskodmatchning eller avsökning till en sökväg där servern inte kräver autentisering.
Matchningsfel för avsökningsstatuskod: Mottagen 403 Åtkomst förbjuden. Kontrollera om åtkomst till sökvägen tillåts på serverdelsservern.
Matchningsfel för avsökningsstatuskod: Mottagen 404 Det går inte att hitta sidan. Kontrollera om sökvägen till värdnamnet är tillgänglig på serverdelsservern. Ändra värdnamnet eller sökvägsparametern till ett tillgängligt värde.
Matchningsfel för avsökningsstatuskod: Mottagna 405 Avsökningsbegäranden för Application Gateway använder HTTP GET-metoden. Kontrollera om servern tillåter den här metoden.
Matchningsfel för avsökningsstatuskod: Mottagna 500 Internt serverfel. Kontrollera serverdelens hälsotillstånd och om tjänsterna körs.
Matchningsfel för avsökningsstatuskod: Mottagna 503 Tjänsten är inte tillgänglig. Kontrollera serverdelens hälsotillstånd och om tjänsterna körs.

Eller om du anser att svaret är legitimt och du vill att Application Gateway ska acceptera andra statuskoder som Felfri, kan du skapa en anpassad avsökning. Den här metoden är användbar i situationer där serverdelswebbplatsen behöver autentisering. Eftersom avsökningsbegäranden inte har några användarautentiseringsuppgifter misslyckas de och en HTTP 401-statuskod returneras av serverdelsservern.

Följ dessa steg för att skapa en anpassad avsökning.

HTTP-svarstexten matchar inte

Meddelande: Brödtexten i serverdelens HTTP-svar matchade inte avsökningsinställningen. Mottagna svarstexter innehåller inte {string}.

Orsak: När du skapar en anpassad avsökning kan du markera en serverdelsserver som Felfri genom att matcha en sträng från svarstexten. Du kan till exempel konfigurera Application Gateway att acceptera "obehörig" som en sträng som ska matchas. Om serverdelsserversvaret för avsökningsbegäran innehåller strängen obehörig markeras den som Felfri. Annars markeras den som Inte felfri med det angivna meddelandet.

Lösning: Lös problemet genom att följa dessa steg:

  1. Öppna serverdelsservern lokalt eller från en klientdator på avsökningssökvägen och kontrollera svarstexten.
  2. Kontrollera att svarstexten i den anpassade avsökningskonfigurationen för Application Gateway matchar det som har konfigurerats.
  3. Om de inte matchar ändrar du avsökningskonfigurationen så att den har rätt strängvärde att acceptera.

Läs mer om matchning av Application Gateway-avsökningar.

Kommentar

För alla TLS-relaterade felmeddelanden kan du läsa mer om SNI-beteende och skillnader mellan SKU:n v1 och v2 genom att gå till TLS-översiktssidan.

Eget namn (CN) matchar inte

Meddelande: (För V2) Det gemensamma namnet på lövcertifikatet som visas av serverdelsservern matchar inte värdnamnet för avsöknings- eller serverdelsinställningen för programgatewayen.
(För V1) Det gemensamma namnet (CN) för serverdelscertifikatet matchar inte.

Orsak: (För V2) Detta inträffar när du har valt HTTPS-protokoll i serverdelsinställningen och varken värdnamnet för den anpassade avsökningen eller serverdelsinställningen (i den ordningen) matchar det egna namnet (CN) för serverdelsserverns certifikat.
(För V1) FQDN för serverdelspoolens mål matchar inte det gemensamma namnet (CN) för serverdelsserverns certifikat.

Lösning: Värdnamnsinformationen är viktig för HTTPS-anslutningen för serverdelen eftersom det värdet används för att ange servernamnindikationen (SNI) under TLS-handskakningen. Du kan åtgärda det här problemet på följande sätt baserat på gatewayens konfiguration.

För V2,

  • Om du använder en standardavsökning – Du kan ange ett värdnamn i den associerade serverdelsinställningen för din programgateway. Du kan välja "Åsidosätt med specifikt värdnamn" eller "Välj värdnamn från serverdelsmål" i serverdelsinställningen.
  • Om du använder en anpassad avsökning – För anpassad avsökning kan du använda fältet "värd" för att ange det gemensamma namnet på serverdelsservercertifikatet. Om serverdelsinställningen redan har konfigurerats med samma värdnamn kan du också välja "Välj värdnamn från serverdelsinställningen" i avsökningsinställningarna.

För V1 kontrollerar du att mål-FQDN för serverdelspoolen är samma som det gemensamma namnet (CN).

Tips: Om du vill fastställa det gemensamma namnet (CN) för serverdelsserverns certifikat kan du använda någon av dessa metoder. Observera också att enligt RFC 6125 om det finns ett SAN görs SNI-verifieringen endast mot det fältet. Det gemensamma namnfältet matchas om det inte finns något SAN i certifikatet.

  • Genom att använda webbläsaren eller någon klient: Få åtkomst till serverdelsservern direkt (inte via Application Gateway) och klicka på certifikatblocket i adressfältet för att visa certifikatinformationen. Du hittar den under avsnittet "Utfärdat till". Screenshot that shows certificate details in a browser.

  • Genom att logga in på serverdelsservern (Windows):

    1. Logga in på den dator där programmet finns.
    2. Välj Win+R eller högerklicka på startknappen och välj Kör.
    3. Ange certlm.msc och välj Retur. Du kan också söka efter Certifikathanteraren på Start-menyn.
    4. Leta upp certifikatet (vanligtvis i Certifikat – Lokal dator\Personligt\Certifikat) och öppna certifikatet.
    5. På fliken Information kontrollerar du certifikatmottagaren.

  • Genom att logga in på serverdelsservern (Linux): Kör det här OpenSSL-kommandot genom att ange rätt certifikatfilnamn openssl x509 -in certificate.crt -subject -noout

Serverdelscertifikatet har upphört att gälla

Meddelande: Serverdelscertifikatet är ogiltigt. Aktuellt datum ligger inte inom datumintervallet "Giltig från" och "Giltig till" på certifikatet.

Orsak: Ett inaktuellt certifikat anses vara osäkert och därför markerar programgatewayen serverdelen som inte felfri med ett utgånget certifikat.

Lösning: Lösningen beror på vilken del av certifikatkedjan som har upphört att gälla på serverdelsservern.

För V2 SKU,

  • Leaf-certifikatet (även kallat Domän eller Server) har upphört att gälla – Förnya servercertifikatet med certifikatprovidern och installera det nya certifikatet på serverdelsservern. Kontrollera att du har installerat den fullständiga certifikatkedjan bestående av Leaf (topmost) > Intermediate(s) > Root. Baserat på typen av certifikatutfärdare (CA) kan du vidta följande åtgärder på din gateway.

    • Offentligt känd certifikatutfärdare: Om certifikatutfärdaren är en välkänd certifikatutfärdare behöver du inte vidta några åtgärder på programgatewayen.
    • Privat certifikatutfärdare: Om lövcertifikatet utfärdas av en privat certifikatutfärdare måste du kontrollera om rotcertifikatutfärdarcertifikatutfärdarcertifikatet har ändrats. I sådana fall måste du ladda upp det nya rotcertifikatutfärdarcertifikatet (. CER) till den associerade serverdelsinställningen för din gateway.

  • Mellanliggande certifikat eller rotcertifikat har upphört att gälla – vanligtvis har dessa certifikat relativt utökade giltighetsperioder (ett decennium eller två). När rot-/mellanliggande certifikat upphör att gälla rekommenderar vi att du kontrollerar de förnyade certifikatfilerna med certifikatprovidern. Se till att du har installerat den här uppdaterade och fullständiga certifikatkedjan som består av Leaf (topmost) > Intermediate(s) > Root på serverdelsservern.

    • Om rotcertifikatet förblir oförändrat eller om utfärdaren är en välkänd certifikatutfärdare behöver du INTE vidta några åtgärder på programgatewayen.
    • Om rotcertifikatutfärdarcertifikatet eller roten för det förnyade mellanliggande certifikatet har ändrats när du använder en privat certifikatutfärdare måste du ladda upp det nya rotcertifikatet till programgatewayens serverdelsinställning.

För V1 SKU,

  • Förnya det utgångna Leaf-certifikatet (kallas även domän eller server) med certifikatutfärdare och ladda upp samma lövcertifikat (. CER) till den associerade serverdelsinställningen för din programgateway.

Det mellanliggande certifikatet hittades inte

Meddelande: Mellanliggande certifikat saknas i certifikatkedjan som visas av serverdelsservern. Kontrollera att certifikatkedjan är klar och korrekt sorterad på serverdelsservern.

Orsak: Mellanliggande certifikat är inte installerade i certifikatkedjan på serverdelsservern.

Lösning: Ett mellanliggande certifikat används för att signera Leaf-certifikatet och behövs därför för att slutföra kedjan. Kontakta certifikatutfärdaren (CA) om de mellanliggande certifikat som behövs och installera dem på servern. Certifikatkedjan måste börja med lövcertifikatet, sedan mellanliggande certifikat och slutligen rotcertifikatutfärdarcertifikatet. Vi rekommenderar att du installerar hela kedjan på serverdelsservern, inklusive rotcertifikatutfärdarcertifikatet. Som referens kan du titta på certifikatkedjans exempel under Löv måste vara längst upp i kedjan.

Kommentar

Ett självsignerat certifikat som INTE är en certifikatutfärdare resulterar också i samma fel. Det beror på att Application Gateway betraktar ett självsignerat certifikat som "Leaf"-certifikat och letar efter dess signering av mellanliggande certifikat. Du kan följa den här artikeln för att generera ett självsignerat certifikat korrekt.

Dessa bilder visar skillnaden mellan de självsignerade certifikaten. Screenshot showing difference between self-signed certificates.

Det gick inte att hitta löv- eller servercertifikatet

Meddelande:Lövcertifikatet saknas i certifikatkedjan som visas av serverdelsservern. Kontrollera att kedjan är klar och korrekt sorterad på serverdelsservern.

Orsak: Leaf-certifikatet (kallas även domän eller server) saknas i certifikatkedjan på serverdelsservern.

Lösning: Du kan hämta lövcertifikatet från certifikatutfärdare (CA). Installera det här lövcertifikatet och alla dess signeringscertifikat (mellanliggande certifikat och rotcertifikatutfärdarcertifikat) på serverdelsservern. Certifikatkedjan måste börja med lövcertifikatet, sedan mellanliggande certifikat och slutligen rotcertifikatutfärdarcertifikatet. Vi rekommenderar att du installerar hela kedjan på serverdelsservern, inklusive rotcertifikatutfärdarcertifikatet. Som referens kan du titta på certifikatkedjans exempel under Löv måste vara längst upp i kedjan.

Servercertifikatet utfärdas inte av en offentligt känd certifikatutfärdare

Meddelande: Serverdelsservercertifikatetär inte signerat av en välkänd certifikatutfärdare (CA). Om du vill använda okända CA-certifikat måste rotcertifikatet laddas upp till serverdelsinställningen för programgatewayen.

Orsak: Du har valt "välkänt CA-certifikat" i serverdelsinställningen, men rotcertifikatet som presenteras av serverdelsservern är inte offentligt känt.

Lösning: När ett Leaf-certifikat utfärdas av en privat certifikatutfärdare (CA) måste signeringen av rotcertifikatutfärdares certifikat laddas upp till programgatewayens associerade serverdelsinställning. På så vis kan programgatewayen upprätta en betrodd anslutning till serverdelen. Du kan åtgärda det här genom att gå till den tillhörande serverdelsinställningen, välja ”inte välkänd certifikatutfärdare” och ladda upp rotcertifikatutfärdarcertifikatet (. CER). Om du vill identifiera och ladda ned rotcertifikatet kan du följa stegen under Matchningsfel för betrott rotcertifikat.

Mellanliggande certifikat är INTE signerat av en offentligt känd certifikatutfärdare.

Meddelande: Mellanliggande certifikat är inte signerat av en välkänd certifikatutfärdare (CA). Kontrollera att certifikatkedjan är klar och korrekt sorterad på serverdelsservern.

Orsak: Du har valt "välkänt CA-certifikat" i serverdelsinställningen, men mellanliggande certifikat som presenteras av serverdelsservern är inte signerat av någon offentligt känd CA.

Lösning: När ett certifikat utfärdas av en privat certifikatutfärdare (CA) måste signeringen av rotcertifikatutfärdarcertifikatet laddas upp till programgatewayens associerade serverdelsinställning. På så vis kan programgatewayen upprätta en betrodd anslutning till serverdelen. Åtgärda detta genom att kontakta din privata certifikatutfärdare för att hämta rätt rotcertifikatutfärdarcertifikat (. CER) och ladda upp . CER-fil till serverdelsinställningen för din programgateway genom att välja "inte en välkänd certifikatutfärdare". Vi rekommenderar också att du installerar hela kedjan på backend-servern, inklusive rot-CA-certifikatet, för enkel verifiering.

Felmatchning av betrott rotcertifikat (inget rotcertifikat på serverdelsservern)

Meddelande: Mellanliggande certifikat som inte har signerats av rotcertifikat som laddats upp till programgatewayen. Kontrollera att certifikatkedjan är klar och korrekt sorterad på serverdelsservern.

Orsak: Inget av de rotcertifikatutfärdarcertifikat som laddats upp till den associerade serverdelsinställningen har signerat det mellanliggande certifikatet som är installerat på serverdelsservern. Serverdelen har endast löv- och mellanliggande certifikat installerade.

Lösning: Ett Lövcertifikat signeras av ett mellanliggande certifikat som är signerat av ett rotcertifikatutfärdarcertifikat. När du använder ett certifikat från en privat certifikatutfärdare (CA) måste du ladda upp motsvarande rotcertifikatutfärdarcertifikat till programgatewayen. Kontakta din privata certifikatutfärdare för att få rätt rotcertifikatutfärdarcertifikat (. CER) och ladda upp CER-filen till serverdelsinställningen för din programgateway.

Felmatchning av betrott rotcertifikat (rotcertifikat är tillgängligt på serverdelsservern)

Meddelande: Rotcertifikatet för servercertifikatet som används av serverdelen matchar inte det betrodda rotcertifikat som lagts till i programgatewayen. Se till att du lägger till rätt rotcertifikat för att tillåtalistning av serverdelen.

Orsak: Det här felet uppstår när inget av de rotcertifikat som laddats upp till programgatewayens serverdelsinställning matchar rotcertifikatet som finns på serverdelsservern.

Lösning: Detta gäller för ett serverdelsservercertifikat som utfärdats av en privat certifikatutfärdare (CA) eller är ett självsignerat certifikat. Identifiera och ladda upp rätt rotcertifikatutfärdarcertifikat till den associerade serverdelsinställningen.

Tips: Om du vill identifiera och ladda ned rotcertifikatet kan du använda någon av dessa metoder.

  • Använda en webbläsare: Öppna serverdelsservern direkt (inte via Application Gateway) och klicka på certifikatlåset i adressfältet för att visa certifikatinformationen.

    1. Välj rotcertifikatet i kedjan och klicka på Exportera. Som standard blir detta en . CRT-fil.
    2. Öppna den . CRT-fil.
    3. Gå till fliken Information och klicka på "Kopiera till fil"
    4. På sidan Exportera certifikat klickar du på Nästa,
    5. Välj "Base-64-kodad X.509 (. CER) och klicka på Nästa,
    6. Ge ett nytt filnamn och klicka på Nästa,
    7. Klicka på Slutför för att hämta en . CER-fil.
    8. Ladda upp rotcertifikatet (. CER) för din privata ca till programgatewayens serverdelsinställning.

  • Genom att logga in på serverdelsservern (Windows)

    1. Logga in på den dator där programmet finns.
    2. Välj Win+R eller högerklicka på knappen Start och välj sedan Kör.
    3. Ange certlm.msc och välj Retur. Du kan också söka efter Certifikathanteraren på Start-menyn.
    4. Leta upp certifikatet, vanligtvis i Certifikat – Lokal dator\Personliga\Certifikat, och öppna det.
    5. Välj rotcertifikatet och välj sedan Visa certifikat.
    6. I certifikategenskaperna väljer du fliken Information och klickar på "Kopiera till fil"
    7. På sidan Exportera certifikat klickar du på Nästa,
    8. Välj "Base-64-kodad X.509 (. CER) och klicka på Nästa,
    9. Ge ett nytt filnamn och klicka på Nästa,
    10. Klicka på Slutför för att hämta en . CER-fil.
    11. Ladda upp rotcertifikatet (. CER) för din privata ca till programgatewayens serverdelsinställning.

Löv måste vara längst upp i kedjan.

Meddelande: Lövcertifikatet är inte det översta certifikatet i kedjan som visas av serverdelsservern. Kontrollera att certifikatkedjan är korrekt ordnad på serverdelsservern.

Orsak: Leaf-certifikatet (även kallat domän eller server) är inte installerat i rätt ordning på serverdelsservern.

Lösning: Certifikatinstallationen på serverdelsservern måste innehålla en ordnad lista över certifikat som består av lövcertifikatet och alla dess signeringscertifikat (mellanliggande certifikat och rotcertifikatutfärdarcertifikat). Certifikatkedjan måste börja med lövcertifikatet, sedan mellanliggande certifikat och slutligen rotcertifikatutfärdarcertifikatet. Vi rekommenderar att du installerar hela kedjan på serverdelsservern, inklusive rotcertifikatutfärdarcertifikatet.

Angivet är ett exempel på en servercertifikatinstallation tillsammans med dess mellanliggande certifikat och rotcertifikatutfärdarcertifikat, som anges som djup (0, 1, 2 och så vidare) i OpenSSL. Du kan kontrollera samma sak för serverdelsserverns certifikat med hjälp av följande OpenSSL-kommandon.
s_client -connect <FQDN>:443 -showcerts
OR
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Screenshot showing typical chain of certificates.

Certifikatverifieringen misslyckades

Meddelande: Det gick inte att verifiera giltigheten för serverdelscertifikatet. Information om orsaken finns i OpenSSL-diagnostik för meddelandet som är associerat med felkoden {errorCode}

Orsak: Det här felet uppstår när Application Gateway inte kan verifiera certifikatets giltighet.

Lösning: Lös problemet genom att kontrollera att certifikatet på servern har skapats korrekt. Du kan till exempel använda OpenSSL för att verifiera certifikatet och dess egenskaper och sedan försöka ladda upp certifikatet till HTTP-inställningarna för Application Gateway.

Hälsotillstånd för serverdelen: Okänd

Uppdateringar till DNS-posterna i serverdelspoolen

Meddelande: Det gick inte att hämta serverdelens hälsostatus. Detta inträffar när en NSG/UDR/Firewall i programgatewayens undernät blockerar trafik på portarna 65503-65534 vid V1 SKU och portarna 65200-65535 vid V2 SKU eller om det FQDN som konfigurerats i serverdelspoolen inte kunde matchas till en IP-adress. Om du vill veta mer besök - https://aka.ms/UnknownBackendHealth.

Orsak: För FQDN-baserade serverdelsmål (fullständigt domännamn) cachelagrar Application Gateway och använder den senast kända IP-adressen om det inte går att få svar för efterföljande DNS-sökning. En PUT-åtgärd på en gateway i det här tillståndet skulle rensa dns-cachen helt och hållet. Därför finns det ingen måladress som gatewayen kan nå.

Lösning: Kontrollera och åtgärda DNS-servrarna för att säkerställa att de betjänar ett svar för det angivna FDQN:s DNS-sökning. Du måste också kontrollera om DNS-servrarna kan nås via programgatewayens virtuella nätverk.

Andra orsaker

Om serverdelshälsan visas som Okänd liknar portalvyn följande skärmbild:

Application Gateway backend health - Unknown

Beteendet kan uppstå på grund av en eller flera av följande orsaker:

  1. NSG:n i Application Gateway-undernätet blockerar inkommande åtkomst till portarna 65503-65534 (v1 SKU) eller 65200-65535 (v2 SKU) från "Internet".
  2. UDR i Application Gateway-undernätet är inställt på standardvägen (0.0.0.0/0) och nästa hopp anges inte som "Internet".
  3. Standardvägen annonseras av en ExpressRoute/VPN-anslutning till ett virtuellt nätverk via BGP.
  4. Den anpassade DNS-servern är konfigurerad i ett virtuellt nätverk som inte kan matcha offentliga domännamn.
  5. Application Gateway är i ett feltillstånd.

Lösning:

  1. Kontrollera om din NSG blockerar åtkomsten till portarna 65503-65534 (v1 SKU) eller 65200-65535 (v2 SKU) från Internet:

    a. På fliken Översikt för Application Gateway väljer du länken Virtuellt nätverk/undernät. b. På fliken Undernät i det virtuella nätverket väljer du det undernät där Application Gateway har distribuerats. c. Kontrollera om NSG har konfigurerats. d. Om en NSG har konfigurerats söker du efter den NSG-resursen på fliken Sök eller under Alla resurser. e. I avsnittet Inkommande regler lägger du till en inkommande regel för att tillåta målportintervallet 65503-65534 för v1 SKU eller 65200-65535 v2 SKU med källuppsättningen som GatewayManager-tjänsttagg. f. Välj Spara och kontrollera att du kan visa serverdelen som Felfri. Du kan också göra det via PowerShell/CLI.

  2. Kontrollera om din UDR har en standardväg (0.0.0.0/0) med nästa hopp inte inställt som Internet:

    a. Följ steg 1a och 1b för att fastställa ditt undernät. b. Kontrollera om en UDR har konfigurerats. Om det finns söker du efter resursen i sökfältet eller under Alla resurser. c. Kontrollera om det finns några standardvägar (0.0.0.0/0) med nästa hopp inte inställt som Internet. Om inställningen antingen är virtuell installation eller virtuell nätverksgateway måste du se till att den virtuella installationen eller den lokala enheten korrekt kan dirigera paketet tillbaka till Internetmålet utan att ändra paketet. Om avsökningar dirigeras via en virtuell installation och ändras visar serverdelsresursen en statuskod på 200 och statusen för Application Gateway-hälsotillståndet kan visas som Okänd. Detta tyder inte på något fel. Trafiken bör fortfarande dirigeras via Application Gateway utan problem. d. Annars ändrar du nästa hopp till Internet, väljer Spara och verifierar serverdelshälsan.

  3. Standardväg som annonseras av ExpressRoute/VPN-anslutningen till det virtuella nätverket via BGP (Border Gateway Protocol):

    a. Om du har en ExpressRoute-/VPN-anslutning till det virtuella nätverket via BGP, och om du annonserar en standardväg, måste du se till att paketet dirigeras tillbaka till internetmålet utan att ändra det. Du kan kontrollera med hjälp av felsökningsalternativet Anslut ion i Application Gateway-portalen. b. Välj målet manuellt som en internetroutningsbar IP-adress som 1.1.1.1. Ange målporten som vad som helst och verifiera anslutningen. c. Om nästa hopp är en virtuell nätverksgateway kan det finnas en standardväg som annonseras via ExpressRoute eller VPN.

  4. Om det finns en anpassad DNS-server konfigurerad i det virtuella nätverket kontrollerar du att servrarna kan matcha offentliga domäner. Offentlig domännamnsmatchning kan krävas i scenarier där Application Gateway måste kontakta externa domäner som OCSP-servrar (Online Certificate Status Protocol) eller för att kontrollera certifikatets återkallningsstatus.

  5. Om du vill kontrollera att Application Gateway är felfri och körs går du till alternativet Resource Health i portalen och kontrollerar att tillståndet är Felfritt. Kontakta supporten om du ser tillståndet Inte felfri eller Degraderad.

  6. Om Internet och privat trafik går via en Azure Firewall som finns i en säker virtuell hubb (med Azure Virtual WAN Hub):

    a. Konfigurera följande användardefinierade väg för att säkerställa att programgatewayen kan skicka trafik direkt till Internet:

    Adressprefix: 0.0.0.0/0
    Nästa hopp: Internet

    b. För att säkerställa att programgatewayen kan skicka trafik till serverdelspoolen via en Azure-brandvägg i Virtual WAN-hubben konfigurerar du följande användardefinierade väg:

    Adressprefix: Undernät för serverdelspool
    Nästa hopp: Privat IP-adress för Azure Firewall

Nästa steg

Läs mer om Application Gateway-diagnostik och loggning.