Delen via

Problemen met de back-endstatus oplossen in Application Gateway

  • Artikel

Overzicht

Standaard test Azure Application Gateway back-endservers om hun status te controleren en om te controleren of ze gereed zijn om aanvragen te verwerken. Gebruikers kunnen ook aangepaste tests maken om de hostnaam, het pad dat moet worden uitgevoerd en de statuscodes te vermelden die als In orde moeten worden geaccepteerd. Als de back-endserver niet reageert, markeert Application Gateway de server als Beschadigd en stopt het met het doorsturen van aanvragen naar de server. Nadat de server met succes reageert, hervat Application Gateway het doorsturen van de aanvragen.

De back-endstatus controleren

Als u de status van uw back-endpool wilt controleren, kunt u de pagina Back-endstatus op de Azure Portal gebruiken. U kunt ook Azure PowerShell, CLI of REST API gebruiken.

De status die door een van deze methoden wordt opgehaald, kan een van de volgende statussen zijn:

  • In orde
  • Niet in orde
  • Onbekend

Application Gateway stuurt een aanvraag door naar een server vanuit de back-endpool als de status in orde is. Als alle servers in een back-endpool beschadigd of onbekend zijn, kunnen de clients problemen ondervinden bij het openen van de back-endtoepassing. Lees verder om inzicht te hebben in de verschillende berichten die zijn gerapporteerd door de back-endstatus, de oorzaken en de oplossing ervan.

Notitie

Als uw gebruiker niet gemachtigd is om de status van de back-end weer te geven, wordt de uitvoer No results. weergegeven.

Status van back-end: niet in orde

Als de status van de back-end niet in orde is, lijkt de portalweergave op de volgende schermopname:

Back-endstatus van Application Gateway - Niet in orde

Als u een Azure PowerShell-, CLI- of Azure REST API-query gebruikt, krijgt u een antwoord dat lijkt op het volgende voorbeeld:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/aaaa0000-bb11-2222-33cc-444444dddddd/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/aaaa0000-bb11-2222-33cc-444444dddddd/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"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

Nadat je een beschadigde back-endserverstatus hebt ontvangen voor alle servers in een back-endpool, worden aanvragen niet doorgestuurd naar de servers en retourneert Application Gateway de fout '502 Ongeldige gateway' naar de aanvragende client. Als u dit probleem wilt oplossen, controleert u de kolom Details op het tabblad Back-endstatus .

Het bericht dat wordt weergegeven in de kolom Details biedt meer gedetailleerde inzichten over het probleem. Op basis van deze details kunt u beginnen met het oplossen van het probleem.

Notitie

De standaardtestaanvraag wordt verzonden in de indeling van <protocol>://127.0.0.1:<port>. Bijvoorbeeld http://127.0.0.1:80 voor een HTTP-test op poort 80. Alleen HTTP-statuscodes van 200 tot en met 399 worden als in orde beschouwd. Het protocol en de doelpoort worden overgenomen van de HTTP-instellingen. Als u wilt dat Application Gateway een test uitvoert op een ander protocol, de hostnaam of het pad en een andere statuscode als In orde wilt herkennen, configureert u een aangepaste test en koppelt u deze aan de HTTP-instellingen.

Foutberichten

Time-out van back-endserver

Bericht: De tijd die de back-end nodig heeft om te reageren op de statustest van de toepassingsgateway is meer dan de time-outdrempelwaarde in de testinstelling.

Oorzaak: Nadat Application Gateway een HTTP(S)-testaanvraag naar de back-endserver heeft verzonden, wacht deze gedurende een geconfigureerde periode op een antwoord van de back-endserver. Als de back-endserver niet binnen deze periode reageert (de time-outwaarde), wordt deze gemarkeerd als Beschadigd totdat deze binnen de geconfigureerde time-outperiode opnieuw reageert.

Oplossing: Controleer waarom de back-endserver of toepassing niet reageert binnen de geconfigureerde time-outperiode en controleer ook de toepassingsafhankelijkheden. Controleer bijvoorbeeld of de database problemen heeft die een vertraging in reactie kunnen activeren. Als u bekend bent met het gedrag van de toepassing en deze pas moet reageren na de time-outwaarde, verhoogt u de time-outwaarde van de aangepaste testinstellingen. U moet een aangepaste test hebben om de time-outwaarde te wijzigen. Zie de documentatiepagina voor informatie over het configureren van een aangepaste test.

Voer de volgende stappen uit om de time-outwaarde te verhogen:

  1. Open de back-endserver rechtstreeks en controleer de tijd die de server nodig heeft om op die pagina te reageren. U kunt elk hulpprogramma gebruiken om toegang te krijgen tot de back-endserver, inclusief een browser met behulp van ontwikkelhulpprogramma's.
  2. Nadat u hebt bepaald hoe lang het duurt voordat de toepassing reageert, selecteert u het tabblad Statustests en selecteert u vervolgens de test die is gekoppeld aan uw HTTP-instellingen.
  3. Voer in seconden een time-outwaarde in die groter is dan de reactietijd van de toepassing.
  4. Sla de aangepaste testinstellingen op en controleer of de back-endstatus nu in orde is.

DNS-omzettingsfout

Bericht: Application Gateway kan geen test maken voor deze back-end. Dit gebeurt meestal wanneer de FQDN van de back-end niet correct wordt ingevoerd. 

Oorzaak: Als de back-endpool van het type IP-adres, FQDN (fully qualified domain name) of App Service is, wordt Application Gateway omgezet in het IP-adres van de FQDN die is ingevoerd via DNS (aangepast of standaard azure). De toepassingsgateway probeert vervolgens verbinding te maken met de server op de TCP-poort die wordt vermeld in de HTTP-instellingen. Als dit bericht wordt weergegeven, wijst dit erop dat Application Gateway het IP-adres van de opgegeven FQDN niet heeft kunnen omzetten.

Oplossing:

  1. Controleer of de FQDN die is opgegeven in de back-endpool juist is en of het een openbaar domein is. Probeer het vervolgens om te zetten vanaf uw lokale computer.
  2. Als u het IP-adres kunt omzetten, is er mogelijk iets mis met de DNS-configuratie in het virtuele netwerk.
  3. Controleer of het virtuele netwerk is geconfigureerd met een aangepaste DNS-server. Als dat zo is, controleert u waarom de DNS-server deze niet kan omzetten naar het IP-adres van de opgegeven FQDN.
  4. Als u azure-standaard-DNS gebruikt, controleert u bij uw domeinnaamregistrar of de juiste A-record of CNAME-recordtoewijzing is voltooid.
  5. Als het domein privé of intern is, probeert u het om te zetten vanaf een VM in hetzelfde virtuele netwerk. Als u dit kunt omzetten, start u Application Gateway opnieuw en controleert u het opnieuw. Als u Application Gateway opnieuw wilt starten, moet u stoppen en starten met behulp van de PowerShell-opdrachten die in deze gekoppelde resources worden beschreven.

TCP-verbindingsfout

Bericht: Application Gateway kan geen verbinding maken met de back-end. Controleer of de back-end reageert op de poort die wordt gebruikt voor de test. Controleer ook of NSG/UDR/Firewall de toegang tot het IP-adres en de poort van deze back-end blokkeert.

Oorzaak: Na de DNS-omzettingsfase probeert Application Gateway verbinding te maken met de back-endserver op de TCP-poort die is geconfigureerd in de HTTP-instellingen. Als Application Gateway geen TCP-sessie op de opgegeven poort tot stand kan brengen, wordt de test gemarkeerd als Beschadigd met dit bericht.

Oplossing: Als u deze fout ontvangt, voert u de volgende stappen uit:

  1. Controleer of u verbinding kunt maken met de back-endserver op de poort die wordt vermeld in de HTTP-instellingen met behulp van een browser of PowerShell. Voer bijvoorbeeld de volgende opdracht uit: Test-NetConnection -ComputerName www.bing.com -Port 443.

  2. Als de vermelde poort niet de gewenste poort is, voert u het juiste poortnummer in voor Application Gateway om verbinding te maken met de back-endserver.

  3. Als u ook geen verbinding kunt maken op de poort vanaf uw lokale computer, doet u het volgende:

    a. Controleer de netwerkbeveiligingsgroepinstellingen (NSG) van de netwerkadapter en het subnet van de back-endserver en of binnenkomende verbindingen met de geconfigureerde poort zijn toegestaan. Als dat niet het is, maakt u een nieuwe regel om de verbindingen toe te staan. Zie de documentatiepagina voor meer informatie over het maken van NSG-regels.

    b. Controleer of de NSG-instellingen van het Application Gateway-subnet uitgaand openbaar en privéverkeer toestaan, zodat er verbinding kan worden gemaakt. Controleer de documentpagina die in stap 3a is opgegeven voor meer informatie over het maken van NSG-regels.

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

    c. Controleer de door de gebruiker gedefinieerde routes (UDR)-instellingen van Application Gateway en het subnet van de back-endserver op eventuele routeringsafwijkingen. Zorg ervoor dat de UDR het verkeer niet wegleidt van het back-endsubnet. Controleer bijvoorbeeld of routes naar virtuele netwerkapparaten of standaardroutes worden geadverteerd naar het Application Gateway-subnet via Azure ExpressRoute en/of VPN.

    d. Als u de effectieve routes en regels voor een netwerkadapter wilt controleren, kunt u de volgende PowerShell-opdrachten gebruiken:

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

  4. Als u geen problemen met NSG of UDR vindt, controleert u de back-endserver op toepassingsproblemen die verhinderen dat clients een TCP-sessie tot stand brengen op de geconfigureerde poorten. Enkele zaken die u moet controleren:

    a. Open een opdrachtprompt (Win+R -> cmd), voer netstat in en selecteer Enter.

    b. Controleer of de server luistert op de geconfigureerde poort. Voorbeeld:

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

    c. Als deze niet luistert op de geconfigureerde poort, controleert u de webserverinstellingen. Bijvoorbeeld: sitebindingen in IIS, serverblok in NGINX en virtuele host in Apache.

    d. Controleer de firewallinstellingen van het besturingssysteem om ervoor te zorgen dat binnenkomend verkeer naar de poort is toegestaan.

HTTP-statuscode komt niet overeen

Bericht: Statuscode van het HTTP-antwoord van de back-end komt niet overeen met de testinstelling. Verwacht:{HTTPStatusCode0} Ontvangen:{HTTPStatusCode1}.

Oorzaak: Nadat de TCP-verbinding tot stand is gebracht en er een TLS-handshake is uitgevoerd (als TLS is ingeschakeld), verzendt Application Gateway de test als een HTTP GET-aanvraag naar de back-endserver. Zoals eerder beschreven, is de standaardtest ingesteld op <protocol>://127.0.0.1:<port>/en wordt de responsstatuscodes in het bereik 200 tot en met 399 beschouwd als In orde. Als de server een andere statuscode retourneert, wordt deze gemarkeerd als Beschadigd met dit bericht.

Oplossing: Afhankelijk van de antwoordcode van de back-endserver, kunt u de volgende stappen uitvoeren. Hier worden enkele algemene statuscodes vermeld:

Fout Acties
Teststatuscode komt niet overeen: ontvangen 401 Controleer of de back-endserver verificatie vereist. Application Gateway-tests kunnen geen referenties doorgeven voor verificatie. Toestaan dat 'HTTP 401' in een teststatuscode overeenkomt of test naar een pad waar de server geen verificatie vereist.
Teststatuscode komt niet overeen: ontvangen 403 Toegang verboden. Controleer of toegang tot het pad is toegestaan op de back-endserver.
Teststatuscode komt niet overeen: Ontvangen 404 Pagina is niet gevonden. Controleer of het pad naar de hostnaam toegankelijk is op de back-endserver. Wijzig de hostnaam of padparameter in een toegankelijke waarde.
Teststatuscode komt niet overeen: Ontvangen 405 De testaanvragen voor Application Gateway gebruiken de HTTP GET-methode. Controleer of uw server deze methode toestaat.
Teststatuscode komt niet overeen: ontvangen 500 Interne serverfout. Controleer de status van de back-endserver en of de services worden uitgevoerd.
Teststatuscode komt niet overeen: ontvangen 503 Service niet beschikbaar. Controleer de status van de back-endserver en of de services worden uitgevoerd.

Als u denkt dat het antwoord legitiem is en u wilt dat Application Gateway andere statuscodes accepteert als In orde, kunt u een aangepaste test maken. Deze benadering is handig in situaties waarin de back-endwebsite verificatie nodig heeft. Omdat de testaanvragen geen gebruikersreferenties bevatten, mislukken ze en wordt een HTTP 401-statuscode geretourneerd door de back-endserver.

Volg deze stappen om een aangepaste test te maken.

Hoofdtekst van HTTP-antwoord komt niet overeen

Bericht: de hoofdtekst van het HTTP-antwoord van de back-end komt niet overeen met de testinstelling. De ontvangen hoofdtekst van het antwoord bevat geen {string}.

Oorzaak: wanneer je een aangepaste test maakt, kun je een back-endserver markeren als In orde door een tekenreeks uit de hoofdtekst van het antwoord te matchen. Je kunt bijvoorbeeld Application Gateway configureren om 'niet-geautoriseerd' te accepteren als een overeenkomende tekenreeks. Als het antwoord van de back-endserver voor de testaanvraag de tekenreeks niet geautoriseerd bevat, wordt deze gemarkeerd als In orde. Anders wordt het gemarkeerd als Beschadigd met het opgegeven bericht.

Oplossing: Voer de volgende stappen uit om dit probleem op te lossen:

  1. Open de back-endserver lokaal of vanaf een clientcomputer op het testpad en controleer de hoofdtekst van het antwoord.
  2. Controleer of de hoofdtekst van het antwoord in de aangepaste testconfiguratie van Application Gateway overeenkomt met wat is geconfigureerd.
  3. Als dit niet overeenkomt, wijzig je de configuratie van de test zodat deze de juiste tekenreekswaarde heeft voor acceptatie.

Meer informatie over het vergelijken van application Gateway-tests.

Notitie

Voor alle TLS-gerelateerde foutberichten raadpleegt u de TLS-overzichtspagina voor meer informatie over het SNI-gedrag en de verschillen tussen de V1- en v2-SKU.

Algemene naam (CN) komt niet overeen

Bericht: (voor V2) De algemene naam van het leaf-certificaat dat door de back-endserver wordt gepresenteerd, komt niet overeen met de hostnaam van de test- of back-endinstelling van de toepassingsgateway.
(Voor V1) De algemene naam (CN) van het back-endcertificaat komt niet overeen.

Oorzaak: (voor V2) Dit gebeurt wanneer u het HTTPS-protocol in de back-endinstelling selecteert en de hostnaam van de aangepaste test of back-endinstelling (in die volgorde) niet overeenkomt met de algemene naam (CN) van het certificaat van de back-endserver.
(Voor V1) De FQDN van het doel van de back-endpool komt niet overeen met de algemene naam (CN) van het certificaat van de back-endserver.

Oplossing: De hostnaamgegevens zijn essentieel voor de HTTPS-verbinding van de back-end, omdat deze waarde wordt gebruikt om de servernaamindicatie (SNI) in te stellen tijdens TLS-handshake. U kunt dit probleem op de volgende manieren oplossen op basis van de configuratie van uw gateway.

Voor V2,

  • Als u een standaardtest gebruikt, kunt u een hostnaam opgeven in de bijbehorende back-endinstelling van uw toepassingsgateway. U kunt 'Overschrijven met specifieke hostnaam' of 'Hostnaam kiezen uit back-enddoel' selecteren in de back-endinstelling.
  • Als u een aangepaste test gebruikt: voor aangepaste test kunt u het veld Host gebruiken om de algemene naam van het back-endservercertificaat op te geven. Als de back-endinstelling al is geconfigureerd met dezelfde hostnaam, kunt u ook hostnaam kiezen in de testinstellingen.

Controleer voor V1 of de FQDN van het back-endpooldoel gelijk is aan de algemene naam (CN).

Tips: Als u de algemene naam (CN) van het back-endservercertificaat wilt bepalen, kunt u een van deze methoden gebruiken. Let ook op: volgens RFC 6125 als er een SAN bestaat, wordt de SNI-verificatie alleen uitgevoerd op basis van dat veld. Het algemene naamveld wordt vergeleken als het certificaat geen SAN bevat.

  • Door de browser of een client te gebruiken: open de back-endserver rechtstreeks (niet via Application Gateway) en klik op de hangslot van het certificaat in de adresbalk om de certificaatgegevens weer te geven. U vindt deze onder de sectie Uitgegeven aan. Schermopname van certificaatdetails in een browser.

  • Door u aan te melden bij de back-endserver (Windows):

    1. Meld u aan bij de computer waarop uw toepassing wordt gehost.
    2. Selecteer Win+R of klik met de rechtermuisknop op de knop Start en selecteer Uitvoeren.
    3. Voer certlm.msc in en selecteer Enter. U kunt ook zoeken naar Certificaatbeheer op de Startmenu.
    4. Zoek het certificaat (meestal in Certificaten - Lokale computer\Persoonlijk\Certificaten) en open het certificaat.
    5. Controleer op het tabblad Details het certificaatonderwerp.

  • Door u aan te melden bij de back-endserver (Linux): Voer deze OpenSSL-opdracht uit door de juiste bestandsnaam van het certificaat op te geven openssl x509 -in certificate.crt -subject -noout

Back-endcertificaat is verlopen

Bericht: Back-endcertificaat is ongeldig. De huidige datum valt niet binnen het datumbereik Geldig van en Geldig tot op het certificaat.

Oorzaak: een verlopen certificaat wordt als onveilig beschouwd en daarom markeert de toepassingsgateway de back-endserver met een verlopen certificaat als beschadigd.

Oplossing: De oplossing is afhankelijk van welk deel van de certificaatketen is verlopen op de back-endserver.

Voor V2-SKU,

  • Verlopen Leaf-certificaat (ook wel bekend als domein of server): vernieuw het servercertificaat met de certificaatprovider en installeer het nieuwe certificaat op de back-endserver. Zorg ervoor dat u de volledige certificaatketen installeert die Leaf (topmost) > Intermediate(s) > Rootbestaat uit . Op basis van het type certificeringsinstantie (CA) kunt u de volgende acties uitvoeren op uw gateway.

    • Openbaar bekende CA: Als de certificaatverlener een bekende CA is, hoeft u geen actie te ondernemen op de toepassingsgateway.
    • Privé-CA: Als het leaf-certificaat wordt uitgegeven door een privé-CA, moet u controleren of het basis-CA-certificaat voor ondertekening is gewijzigd. In dergelijke gevallen moet u het nieuwe basis-CA-certificaat (. CER) naar de bijbehorende back-endinstelling van uw gateway.

  • Verlopen tussen- of basiscertificaat: deze certificaten hebben doorgaans relatief langere geldigheidsperioden (tien of twee). Wanneer het basis-/tussenliggende certificaat verloopt, wordt u aangeraden contact op te nemen met uw certificaatprovider voor de vernieuwde certificaatbestanden. Zorg ervoor dat u deze bijgewerkte en volledige certificaatketen installeert die bestaat Leaf (topmost) > Intermediate(s) > Root uit de back-endserver.

    • Als het basiscertificaat ongewijzigd blijft of als de verlener een bekende CA is, moet u geen actie ondernemen op de toepassingsgateway.
    • Wanneer u een privé-CA gebruikt en het basis-CA-certificaat zelf of de basis van het vernieuwde tussenliggende certificaat is gewijzigd, moet u het nieuwe basiscertificaat uploaden naar de back-endinstelling van de toepassingsgateway.

Voor V1-SKU,

  • Vernieuw het verlopen Leaf-certificaat (ook wel domein- of servercertificaat genoemd) met uw CA en upload hetzelfde leaf-certificaat (. CER) naar de bijbehorende back-endinstelling van uw toepassingsgateway.

Het tussenliggende certificaat is niet gevonden

Bericht: Het tussenliggende certificaat ontbreekt in de certificaatketen die wordt gepresenteerd door de back-endserver. Zorg ervoor dat de certificaatketen is voltooid en correct is geordend op de back-endserver.

Oorzaak: De tussenliggende certificaten zijn niet geïnstalleerd in de certificaatketen op de back-endserver.

Oplossing: Er wordt een tussenliggend certificaat gebruikt om het Leaf-certificaat te ondertekenen en is dus nodig om de keten te voltooien. Neem contact op met uw certificeringsinstantie (CA) voor de benodigde tussenliggende certificaten en installeer deze op uw back-endserver. De certificaatketen van de back-endserver moet beginnen met het leaf-certificaat, gevolgd door eventuele tussenliggende certificaten en ten slotte het CA-basiscertificaat. We raden u aan de volledige keten op de back-endserver te installeren, inclusief het basis-CA-certificaat. Bekijk ter referentie het voorbeeld van de certificaatketen onder leaf moet het bovenste in de keten zijn.

Notitie

Een zelfondertekend certificaat dat GEEN certificeringsinstantie is, resulteert ook in dezelfde fout. Dit komt doordat application gateway zo'n zelfondertekend certificaat beschouwt als 'Leaf'-certificaat en zoekt naar het tussenliggende certificaat voor ondertekening. U kunt dit artikel volgen om een zelfondertekend certificaat correct te genereren.

Deze afbeeldingen tonen het verschil tussen de zelfondertekende certificaten. Schermopname van het verschil tussen zelfondertekende certificaten.

Het leaf- of servercertificaat is niet gevonden

Bericht: Het Leaf-certificaat ontbreekt in de certificaatketen die wordt gepresenteerd door de back-endserver. Zorg ervoor dat de keten is voltooid en correct is gerangschikt op de back-endserver.

Oorzaak: Het leaf-certificaat (ook wel domein- of servercertificaat genoemd) ontbreekt in de certificaatketen op de back-endserver.

Oplossing: U kunt het leaf-certificaat ophalen van uw certificeringsinstantie (CA). Installeer dit leaf-certificaat en alle bijbehorende ondertekeningscertificaten (tussenliggende en basis-CA-certificaten) op de back-endserver. De certificaatketen van de back-endserver moet beginnen met het leaf-certificaat, gevolgd door het/de tussenliggende certifica(a)t(en) en ten slotte het basis-CA-certificaat. We raden u aan de volledige keten op de back-endserver te installeren, inclusief het basis-CA-certificaat. Bekijk ter referentie het voorbeeld van de certificaatketen onder leaf moet het bovenste in de keten zijn.

Servercertificaat wordt niet uitgegeven door een openbaar bekende CA

Bericht: Het back-endservercertificaat is niet ondertekend door een bekende certificeringsinstantie (CA). Als u onbekende CA-certificaten wilt gebruiken, moet het basiscertificaat worden geüpload naar de back-endinstelling van de toepassingsgateway.

Oorzaak: U hebt 'bekende CA-certificaat' gekozen in de back-endinstelling, maar het basiscertificaat dat door de back-endserver wordt gepresenteerd, is niet openbaar bekend.

Oplossing: Wanneer een Leaf-certificaat wordt uitgegeven door een persoonlijke certificeringsinstantie (CA), moet het certificaat van de basis-CA voor ondertekening worden geüpload naar de bijbehorende back-endinstelling van de toepassingsgateway. Hierdoor kan uw toepassingsgateway een vertrouwde verbinding met die back-endserver tot stand brengen. U lost dit op door naar de bijbehorende back-endinstelling te gaan. U kiest 'geen bekende CA' en uploadt vervolgens het CA-basiscertificaat (.CER). Als u het basiscertificaat wilt identificeren en downloaden, volgt u dezelfde stappen als beschreven onder Vertrouwd basiscertificaat komt niet overeen.

Het tussenliggende certificaat is NIET ondertekend door een openbaar bekende CA.

Bericht: Het tussenliggende certificaat is niet ondertekend door een bekende certificeringsinstantie (CA). Zorg ervoor dat de certificaatketen is voltooid en correct is geordend op de back-endserver.

Oorzaak: U hebt 'bekende CA-certificaat' gekozen in de back-endinstelling, maar het tussenliggende certificaat dat door de back-endserver wordt gepresenteerd, is niet ondertekend door een openbare CA.

Oplossing: Wanneer een certificaat wordt uitgegeven door een persoonlijke certificeringsinstantie (CA), moet het certificaat van de basis-CA voor ondertekening worden geüpload naar de bijbehorende back-endinstelling van de toepassingsgateway. Hierdoor kan uw toepassingsgateway een vertrouwde verbinding met die back-endserver tot stand brengen. Neem contact op met uw privé-CA om het juiste basis-CA-certificaat (. CER) en upload die . Cer-bestand naar de back-endinstelling van uw toepassingsgateway door 'geen bekende CA' te selecteren. Het wordt tevens aanbevolen de volledige keten op de back-endserver te installeren, inclusief het CA-basiscertificaat, voor eenvoudige verificatie.

Vertrouwd basiscertificaat komt niet overeen (geen basiscertificaat op de back-endserver)

Bericht: Het tussenliggende certificaat dat niet is ondertekend door basiscertificaten die zijn geüpload naar de toepassingsgateway. Zorg ervoor dat de certificaatketen is voltooid en correct is geordend op de back-endserver.

Oorzaak: voor geen van de CA-basiscertificaten die zijn geüpload naar de bijbehorende back-endinstelling is het tussenliggende certificaat ondertekend dat op de back-endserver is geïnstalleerd. Op de back-endserver zijn alleen bladknooppuntcertificaten en tussenliggende certificaten geïnstalleerd.

Oplossing: Een Leaf-certificaat wordt ondertekend door een tussenliggend certificaat, dat is ondertekend door een basis-CA-certificaat. Wanneer u een certificaat van een persoonlijke certificeringsinstantie (CA) gebruikt, moet u het bijbehorende CA-basiscertificaat uploaden naar de toepassingsgateway. Neem contact op met uw persoonlijke CA om het juiste CA-basiscertificaat (.CER) te verkrijgen en upload dat CER-bestand naar de back-endinstelling van uw toepassingsgateway.

Vertrouwd basiscertificaat komt niet overeen (basiscertificaat is beschikbaar op de back-endserver)

Bericht: het basiscertificaat van het servercertificaat dat door de back-end wordt gebruikt, komt niet overeen met het vertrouwde basiscertificaat dat is toegevoegd aan de toepassingsgateway. Zorg ervoor dat u het juiste basiscertificaat toevoegt om de back-end toe te staan.

Oorzaak: deze fout treedt op wanneer geen van de basiscertificaten die naar de back-endinstelling van uw toepassingsgateway zijn geüpload, overeenkomt met het basiscertificaat dat aanwezig is op de back-endserver.

Oplossing: Dit is van toepassing op een back-endservercertificaat dat is uitgegeven door een persoonlijke certificeringsinstantie (CA) of een zelfondertekend certificaat. Identificeer en upload het juiste CA-basiscertificaat naar de bijbehorende back-endinstelling.

Tips: Als u het basiscertificaat wilt identificeren en downloaden, kunt u een van deze methoden gebruiken.

  • Met behulp van een browser: Open de back-endserver rechtstreeks (niet via Application Gateway) en klik op het certificaatslot in de adresbalk om de certificaatgegevens weer te geven.

    1. Kies het basiscertificaat in de keten en klik op Exporteren. Dit is standaard een . CRT-bestand.
    2. Open dat. CRT-bestand.
    3. Ga naar het tabblad Details en klik op Kopiëren naar bestand.
    4. Klik op de pagina Wizard Certificaat exporteren op Volgende,
    5. Selecteer Base-64 gecodeerd x.509 (. CER) en klik op Volgende,
    6. Geef een nieuwe bestandsnaam en klik op Volgende,
    7. Klik op Voltooien om een . CER-bestand.
    8. Upload dit basiscertificaat (. CER) van uw privé-CA naar de back-endinstelling van de toepassingsgateway.

  • Door u aan te melden bij de back-endserver (Windows)

    1. Meld u aan bij de computer waarop uw toepassing wordt gehost.
    2. Selecteer Win+R of klik met de rechtermuisknop op de knop Start en selecteer Vervolgens Uitvoeren.
    3. Voer certlm.msc in en selecteer Enter. U kunt ook zoeken naar Certificaatbeheer op de Startmenu.
    4. Zoek het certificaat, meestal in Certificaten - Lokale computer\Persoonlijk\Certificaten en open het.
    5. Selecteer het basiscertificaat en selecteer vervolgens Certificaat weergeven.
    6. Selecteer in de eigenschappen van het certificaat het tabblad Details en klik op Kopiëren naar bestand.
    7. Klik op de pagina Wizard Certificaat exporteren op Volgende,
    8. Selecteer Base-64 gecodeerd x.509 (. CER) en klik op Volgende,
    9. Geef een nieuwe bestandsnaam en klik op Volgende,
    10. Klik op Voltooien om een . CER-bestand.
    11. Upload dit basiscertificaat (. CER) van uw privé-CA naar de back-endinstelling van de toepassingsgateway.

Blad moet boven in ketting staan.

Bericht: Het Leaf-certificaat is niet het bovenste certificaat in de keten die wordt gepresenteerd door de back-endserver. Zorg ervoor dat de certificaatketen correct is gerangschikt op de back-endserver.

Oorzaak: Het Leaf-certificaat (ook wel domein of server genoemd) is niet geïnstalleerd in de juiste volgorde op de back-endserver.

Oplossing: De installatie van het certificaat op de back-endserver moet een geordende lijst met certificaten bevatten die bestaan uit het certificaat en alle bijbehorende handtekeningcertificaten (tussen- en basis-CA-certificaten). De keten moet beginnen met het Leaf-certificaat, gevolgd door het/de tussenliggende certifica(a)t(en) en ten slotte het basis-CA-certificaat. We raden u aan de volledige keten op de back-endserver te installeren, inclusief het basis-CA-certificaat.

Gegeven is een voorbeeld van een servercertificaatinstallatie, samen met de tussenliggende en basis-CA-certificaten, aangeduid als diepten (0, 1, 2, enzovoort) in OpenSSL. U kunt hetzelfde controleren voor het certificaat van uw back-endserver met behulp van de volgende OpenSSL-opdrachten.
s_client -connect <FQDN>:443 -showcerts
OF
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Schermopname van een typische keten van certificaten.

Certificaatverificatie is mislukt

Bericht: De geldigheid van het back-endcertificaat kan niet worden geverifieerd. Als u de reden wilt achterhalen, controleert u openSSL-diagnose voor het bericht dat is gekoppeld aan foutcode {errorCode}

Oorzaak: Deze fout treedt op wanneer Application Gateway de geldigheid van het certificaat niet kan controleren.

Oplossing: Controleer of het certificaat op de server correct is gemaakt om dit probleem op te lossen. Je kunt bijvoorbeeld OpenSSL gebruiken om het certificaat en de eigenschappen te verifiëren en te proberen het certificaat opnieuw te uploaden naar de HTTP-instellingen van de Application Gateway.

Status van back-end: onbekend

Updates voor de DNS-vermeldingen van de back-endpool

Bericht: De status van de back-end kan niet worden opgehaald. Dit gebeurt wanneer een NSG/UDR/Firewall op het subnet van de toepassingsgateway verkeer blokkeert op poorten 65503-65534 in het geval van v1 SKU en poorten 65200-65535 in het geval van de v2-SKU of als de FQDN die in de back-endpool is geconfigureerd, niet kan worden omgezet in een IP-adres. Ga voor meer informatie naar - https://aka.ms/UnknownBackendHealth.

Oorzaak: Voor FQDN-doelen (Fully Qualified Domain Name)-gebaseerde back-enddoelen, slaat de Application Gateway caches op en gebruikt het laatst bekende goede IP-adres als het geen antwoord krijgt voor de volgende DNS-zoekactie. Een PUT-bewerking op een gateway met deze status wist de DNS-cache helemaal. Als gevolg hiervan is er geen doeladres waarnaar de gateway kan bereiken.

Oplossing: Controleer en corrigeer de DNS-servers om ervoor te zorgen dat deze een antwoord biedt voor de DNS-zoekactie van de opgegeven FDQN. U moet ook controleren of de DNS-servers bereikbaar zijn via het virtuele netwerk van uw toepassingsgateway.

Andere redenen

Als de back-endstatus wordt weergegeven als Onbekend, lijkt de portalweergave op de volgende schermopname:

Back-endstatus van Application Gateway - Onbekend

Dit gedrag kan een van de volgende oorzaken hebben:

  1. De NSG op het Subnet van Application Gateway blokkeert binnenkomende toegang tot poorten 65503-65534 (v1 SKU) of 65200-65535 (v2 SKU) van internet.
  2. De UDR op het Application Gateway-subnet is ingesteld op de standaardroute (0.0.0.0/0) en de volgende hop wordt niet opgegeven als 'Internet'.
  3. De standaardroute wordt via BGP geadverteerd door een ExpressRoute/VPN-verbinding met een virtuele netwerk.
  4. De aangepaste DNS-server is geconfigureerd in een virtueel netwerk dat geen openbare domeinnamen kan omzetten.
  5. Toepassingsgateway bevindt zich in een foutstatus.

Oplossing:

  1. Controleer of de NSG de toegang tot de poorten 65503-65534 (v1 SKU) of 65200-65535 (v2 SKU) vanaf internet blokkeert:

    a. Selecteer op het tabblad Overzicht van Application Gateway de koppeling Virtueel netwerk/subnet. b. Selecteer op het tabblad Subnetten van uw virtuele netwerk het subnet waarin Application Gateway is geïmplementeerd. c. Controleer of een NSG is geconfigureerd. d. Als een NSG is geconfigureerd, zoekt u naar die NSG-resource op het tabblad Zoeken of onder Alle resources. e. Voeg in de sectie Regels voor binnenkomend verkeer een regel toe om doelpoortbereik 65503-65534 voor v1 SKU of 65200-65535 v2 SKU met de bronset als gatewaymanagerservicetag toe te staan. f. Selecteer Opslaan en controleer of u de back-end als In orde kunt bekijken. U kunt dit ook doen via PowerShell/CLI.

  2. Controleer of uw UDR een standaardroute heeft (0.0.0.0/0) waarbij de volgende hop niet is ingesteld als internet:

    a. Volg stap 1a en 1b om uw subnet te bepalen. b. Controleer of een UDR is geconfigureerd. Als dat zo is, zoekt u naar de resource op de zoekbalk of onder Alle resources. c. Controleer of er standaardroutes zijn (0.0.0.0/0) waarbij de volgende hop niet is ingesteld als internet. Als de instelling een virtueel apparaat of virtuele netwerkgateway is, moet u ervoor zorgen dat uw virtuele apparaat of het on-premises apparaat het pakket naar de internetbestemming kan routeren zonder het pakket te wijzigen. Als tests worden gerouteerd via een virtueel apparaat en gewijzigd, geeft de back-endresource een statuscode van 200 weer en kan de status van Application Gateway worden weergegeven als Onbekend. Dit geeft geen fout aan. Verkeer moet nog steeds zonder probleem worden gerouteerd via de Application Gateway. d. Wijzig anders de volgende hop naar internet, selecteer Opslaan en controleer de back-endstatus.

  3. Standaardroute geadverteerd door de ExpressRoute/VPN-verbinding met het virtuele netwerk via BGP (Border Gateway Protocol):

    a. Als u een ExpressRoute-/VPN-verbinding hebt met het virtuele netwerk via BGP en als u een standaardroute adverteert, moet u ervoor zorgen dat het pakket terug wordt gerouteerd naar de internetbestemming zonder dit te wijzigen. U kunt dit controleren met behulp van de optie Verbindingsproblemen oplossen in de Application Gateway-portal. b. Kies het doel handmatig als een internetrouteerbaar IP-adres, zoals 1.1.1.1. 1. Stel de doelpoort in als alles en controleer de connectiviteit. c. Als de volgende hop een virtuele netwerkgateway is, is er mogelijk een standaardroute die wordt geadverteerd via ExpressRoute of VPN.

  4. Als er een aangepaste DNS-server is geconfigureerd in het virtuele netwerk, controleert u of de servers openbare domeinen kunnen omzetten. In scenario's waarin Application Gateway verbinding moet maken met externe domeinen zoals OCSP-servers (Online Certificate Status Protocol) of om de intrekkingsstatus van het certificaat te controleren, is mogelijk vereist.

  5. Als u wilt controleren of Application Gateway in orde is en wordt uitgevoerd, gaat u naar de optie Resource Health in de portal en controleert u of de status In orde is. Als u de status Beschadigd of Beschadigd ziet, neemt u contact op met de ondersteuning.

  6. Als internet- en privéverkeer via een Azure Firewall worden gehost in een beveiligde virtuele hub (met behulp van Azure Virtual WAN Hub):

    a. Om ervoor te zorgen dat de toepassingsgateway verkeer rechtstreeks naar internet kan verzenden, configureert u de volgende door de gebruiker gedefinieerde route:

    Adresvoorvoegsel: 0.0.0.0/0
    Volgende hop: Internet

    b. Om ervoor te zorgen dat de toepassingsgateway verkeer naar de back-endpool kan verzenden via een Azure Firewall in de Virtual WAN-hub, configureert u de volgende door de gebruiker gedefinieerde route:

    Adresvoorvoegsel: subnet van back-endpool
    Volgende hop: privé-IP-adres van Azure Firewall

Notitie

Als de toepassingsgateway geen toegang heeft tot de CRL-eindpunten, wordt de status van de back-end mogelijk gemarkeerd als 'onbekend'. Als u deze problemen wilt voorkomen, controleert u of uw subnet van de toepassingsgateway toegang heeft tot crl.microsoft.com en crl3.digicert.com. U kunt dit doen door uw netwerkbeveiligingsgroepen te configureren om verkeer naar de CRL-eindpunten te verzenden.

Volgende stappen

Meer informatie over diagnostische gegevens en logboekregistratie van Application Gateway.