Problemen met de back-Application Gateway

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 onderzocht en de statuscodes te vermelden die moeten worden geaccepteerd als In orde. Als de back-endserver in elk geval niet reageert, Application Gateway de server als Beschadigd en stopt het doorsturen van aanvragen naar de server. Nadat de server met succes reageert, Application Gateway het doorsturen van de aanvragen hervat.

De status van de back-en-ving controleren

Als u de status van uw back-endpool wilt controleren, kunt u de pagina Back-Azure Portal. U kunt ook Azure PowerShell, CLIof REST API.

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

• In orde

• Niet in orde

• Onbekend

Als de status van de back-Application Gateway voor een server In orde is, worden de aanvragen doorgestuurd naar die server. Maar als de back-end-status voor alle servers in een back-mailpool Niet in orde of onbekend is, kunnen er problemen ontstaan wanneer u toepassingen probeert te openen. In dit artikel worden de symptomen, de oorzaak en de oplossing voor elk van de weergegeven fouten beschreven.

Status van back-en-die: Niet in orde

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

Of als u een Azure PowerShell-, CLI- of Azure REST API-query gebruikt, krijgt u een antwoord dat er als volgt uit ziet:

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

Nadat u de status van de back-endserver met een slechte status hebt ontvangen voor alle servers in een back-endpool, worden aanvragen niet doorgestuurd naar de servers en retourneert Application Gateway de fout '502 Bad Gateway' naar de aanvragende client. Als u dit probleem wilt oplossen, controleert u de kolom Details op het tabblad Back-end-status.

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

Foutberichten

Time-out van back-en-mailserver

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

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

Resolutie: 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 veroorzaken. Als u op de hoogte bent van het gedrag van de toepassing en deze pas na de time-outwaarde moet reageren, 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 meer informatie over het configureren van een aangepaste test.

Volg deze stappen om de time-outwaarde te verhogen:

1. Ga rechtstreeks naar de back-endserver 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, met inbegrip van een browser met ontwikkelhulpprogramma's.

2. Nadat u de tijd hebt ingesteld die de toepassing nodig heeft om te reageren, 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-end-status nu in orde is.

DNS-resolutiefout

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

Oorzaak: Als de back-endpool van het type IP-adres/FQDN of App Service is, wordt Application Gateway omgegaan met het IP-adres van de FQDN die is ingevoerd via Domain Name System (DNS) (aangepast of standaard Azure) en wordt geprobeerd verbinding te maken met de server op de TCP-poort die wordt vermeld in de HTTP-Instellingen. Maar als dit bericht wordt weergegeven, wordt ervan uitgegaan Application Gateway het IP-adres van de ingevoerde FQDN niet kan worden opgelost.

Oplossing:

1. Controleer of de FQDN die is ingevoerd in de back-endpool juist is en of het een openbaar domein is en probeer het vervolgens op te lossen vanaf uw lokale computer.

2. Als u het IP-adres kunt oplossen, 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 het zo is, controleert u de DNS-server waarom deze niet kan worden opgelost met het IP-adres van de opgegeven FQDN.

4. Als u standaard-DNS van Azure gebruikt, moet u contact opnemen met uw domeinnaamregistrar om na te gaan of de juiste A-record- of CNAME-recordtoewijzing is voltooid.

5. Als het domein privé of intern is, probeert u het op te lossen vanaf een virtuele machine in hetzelfde virtuele netwerk. Als u dit kunt oplossen, start u de Application Gateway en controleert u het opnieuw. Als u Application Gateway opnieuw wilt starten, moet u stoppen en beginnen met behulp van de PowerShell-opdrachten die worden beschreven in deze gekoppelde resources.

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 is geconfigureerd in de back-mailpool, niet kan worden opgelost naar een IP-adres. Ga naar voor meer https://aka.ms/UnknownBackendHealth informatie.

Oorzaak: Application Gateway worden de DNS-vermeldingen voor de back-uppool tijdens het opstarten opgelost en worden ze niet dynamisch bijgewerkt tijdens het uitvoeren.

Oplossing:

Application Gateway moeten opnieuw worden opgestart na een wijziging in de DNS-vermeldingen van de back-endserver om de nieuwe IP-adressen te kunnen gebruiken. Deze bewerking kan worden voltooid via Azure PowerShell of Azure CLI.

Azure PowerShell

# Get Azure Application Gateway
$appgw=Get-AzApplicationGateway -Name <appgw_name> -ResourceGroupName <rg_name>
 
# Stop the Azure Application Gateway
Stop-AzApplicationGateway -ApplicationGateway $appgw
 
# Start the Azure Application Gateway
Start-AzApplicationGateway -ApplicationGateway $appgw

Azure CLI

# Stop the Azure Application Gateway
az network application-gateway stop -n <appgw_name> -g <rg_name>

# Start the Azure Application Gateway
az network application-gateway start -n <appgw_name> -g <rg_name>

TCP-verbindingsfout

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

Oorzaak: Na de DNS-resolutiefase 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 tot stand kan brengen op de opgegeven poort, wordt de test gemarkeerd als Beschadigd met dit bericht.

Oplossing: Als deze fout wordt weergegeven, volgt u deze stappen:

1. Controleer met behulp van een browser of PowerShell of u verbinding kunt maken met de back-endserver op de poort die wordt vermeld in de HTTP-instellingen. 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 verbinding te maken met de back-endserver

3. Als u ook vanaf uw lokale computer geen verbinding kunt maken op de poort, gaat u als volgende te werk:

   a. Controleer de instellingen van de netwerkbeveiligingsgroep (NSG) van de netwerkadapter en het subnet van de back-mailserver en of binnenkomende verbindingen met de geconfigureerde poort zijn toegestaan. Als dat niet zo 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 een verbinding kan worden gemaakt. Controleer de documentpagina die is opgegeven in stap 3a 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-eindgebruikerserver op eventuele routeringsafwijkingen. Zorg ervoor dat de UDR het verkeer niet weg leidt van het back-endsubnet. Controleer bijvoorbeeld op routes naar virtuele netwerkapparaten of standaardroutes die naar het Application Gateway subnet worden geadverteerd 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 dingen 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 poort die is geconfigureerd. Bijvoorbeeld:

           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 instellingen van uw webserver. Bijvoorbeeld: sitebindingen in IIS, serverblok in NGINX en virtuele host in Apache.

   d. Controleer de firewallinstellingen van uw besturingssysteem om te controleren of binnenkomend verkeer naar de poort is toegestaan.

HTTP-statuscode komt niet overeen

Bericht: De statuscode van het ' HTTP-antwoord van de back-end komt niet overeen met de testinstelling. Expected:{HTTPStatusCode0} Received:{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, wordt de standaardtest ingesteld op <protocol> ://127.0.0.1: /, en worden de responsstatuscodes in de <port> tussen 200 en 399 als in orde gezien. Als de server andere statuscodes retourneert, wordt deze gemarkeerd als Niet in orde met dit bericht.

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

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

Volg deze stappen om een aangepaste test te maken.

HTTP-antwoord body komt niet overeen

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

Oorzaak: Wanneer u een aangepaste test maakt, hebt u de mogelijkheid om een back-mailserver als In orde te markeren door een tekenreeks uit de antwoord body te koppelen. U kunt bijvoorbeeld configureren dat Application Gateway 'niet-geautoriseerd' accepteert als een tekenreeks die moet overeenkomen. Als het antwoord van de back-endserver voor de testaanvraag de tekenreeks niet geautoriseerd bevat, wordt deze gemarkeerd als In orde. Anders wordt dit bericht gemarkeerd als Niet in orde.

Oplossing: Volg deze stappen om dit probleem op te lossen:

1. Toegang tot de back-endserver lokaal of vanaf een clientmachine op het testpad en controleer de antwoord body.

2. Controleer of de antwoord body in Application Gateway configuratie van de aangepaste test overeenkomt met wat is geconfigureerd.

3. Als ze niet overeenkomen, wijzigt u de testconfiguratie zodat deze de juiste tekenreekswaarde heeft om te accepteren.

Meer informatie over Application Gateway test die overeenkomtmet .

Ongeldige CA voor back-endservercertificaat

Bericht: Het servercertificaat dat door de back-end wordt gebruikt, is niet ondertekend door een bekende certificeringsinstantie (CA). Sta de back-Application Gateway toe door het basiscertificaat te uploaden van het servercertificaat dat door de back-end wordt gebruikt.

Oorzaak: End-to-end SSL met Application Gateway v2 vereist dat het certificaat van de back-endserver wordt geverifieerd om de server in orde te achten. Een TLS/SSL-certificaat kan alleen worden vertrouwd als dat certificaat van de back-endserver wordt uitgegeven door een CERTIFICERINGsinstantie die is opgenomen in het vertrouwde Application Gateway. Als het certificaat niet is uitgegeven door een vertrouwde CERTIFICERINGsinstantie (bijvoorbeeld als er een zelf-ondertekend certificaat is gebruikt), moeten gebruikers het certificaat van de vergever uploaden naar Application Gateway.

Oplossing: Volg deze stappen om het vertrouwde basiscertificaat te exporteren en te uploaden naar Application Gateway. (Deze stappen zijn voor Windows clients.)

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 certmgr.msc in en selecteer Enter. U kunt ook zoeken naar Certificaatbeheer in het menu Start.

4. Zoek het certificaat, meestal in \Certificates - Current User\\Personal\\Certificates\ , en open het.

5. Selecteer het basiscertificaat en selecteer vervolgens Certificaat weergeven.

6. Selecteer in de eigenschappen van het certificaat het tabblad Details.

7. Selecteer op het tabblad Details de optie Kopiëren naar bestand en sla het bestand op in de met Base-64 gecodeerde X.509 (. CER-indeling.

8. Open de Application Gateway HTTP-Instellingen in de Azure Portal.

9. Open de HTTP-instellingen, selecteer Certificaat toevoegen en zoek het certificaatbestand dat u zojuist hebt opgeslagen.

10. Selecteer Opslaan om de HTTP-instellingen op te slaan.

U kunt het basiscertificaat ook exporteren vanaf een clientmachine door rechtstreeks toegang te krijgen tot de server (door Application Gateway te omzeilen) via de browser en het basiscertificaat vanuit de browser te exporteren.

Zie Vertrouwd basiscertificaat exporteren (voor v2 SKU)voor meer informatie over het extraheren en uploaden van vertrouwde basiscertificaten in Application Gateway.

Vertrouwd basiscertificaat komt niet overeen

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: End-to-end SSL met Application Gateway v2 vereist dat het certificaat van de back-endserver wordt geverifieerd om de server in orde te achten. Een TLS/SSL-certificaat kan alleen worden vertrouwd als het back-endservercertificaat wordt uitgegeven door een CERTIFICERINGsinstantie die is opgenomen in het vertrouwde opslag van Application Gateway. Als het certificaat niet is uitgegeven door een vertrouwde CERTIFICERINGsinstantie (bijvoorbeeld als er een zelf-ondertekend certificaat is gebruikt), moeten gebruikers het certificaat van de vergever uploaden naar Application Gateway.

Het certificaat dat is geüpload naar Application Gateway HTTP-instellingen moet overeenkomen met het basiscertificaat van het back-upservercertificaat.

Oplossing: Als u dit foutbericht ontvangt, is er een verschil tussen het certificaat dat is geüpload naar Application Gateway en het certificaat dat is geüpload naar de back-upserver.

Volg de stappen 1-11 in de vorige methode om het juiste vertrouwde basiscertificaat te uploaden naar Application Gateway.

Zie Vertrouwd basiscertificaat exporteren (voor v2 SKU)voor meer informatie over het extraheren en uploaden van vertrouwde basiscertificaten in Application Gateway.

Bijvoorbeeld:

OpenSSL> s_client -connect 10.0.0.4:443 -servername www.example.com -showcerts

Als in de uitvoer niet de volledige keten van het certificaat wordt geretourneerd wordt vermeld, exporteert u het certificaat opnieuw met de volledige keten, inclusief het basiscertificaat. Configureer dat certificaat op de back-endserver.

  CONNECTED(00000188)\
  depth=0 OU = Domain Control Validated, CN = \*.example.com\
  verify error:num=20:unable to get local issuer certificate\
  verify return:1\
  depth=0 OU = Domain Control Validated, CN = \*.example.com\
  verify error:num=21:unable to verify the first certificate\
  verify return:1\
  \-\-\-\
  Certificate chain\
   0 s:/OU=Domain Control Validated/CN=*.example.com\
     i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2\
  \-----BEGIN CERTIFICATE-----\
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\
  \-----END CERTIFICATE-----

Ongeldige algemene naam (CN) van back-certificaat

Bericht: De algemene naam (CN) van het back-endcertificaat komt niet overeen met de hostheader van de test.

Oorzaak: Application Gateway controleert of de hostnaam die is opgegeven in de HTTP-instellingen van de back-eind overeenkomt met die van de CN die wordt gepresenteerd door het TLS/SSL-certificaat van de back-ende server. Dit is Standard_v2 en WAF_v2 SKU-gedrag (V2). De standaard- en WAF-SKU's (v1) Servernaamindicatie (SNI) worden ingesteld als de FQDN in het adres van de back-endpool. Zie Overzicht van TLS-beëindiging en end-to-end-TLSmet Application Gateway voor meer informatie over SNI-gedrag en verschillen tussen v1 en v2 SKU.

Als er in de v2-SKU een standaardtest is (er is geen aangepaste test geconfigureerd en gekoppeld), wordt SNI ingesteld op de hostnaam die wordt vermeld in de HTTP-instellingen. Of als 'Hostnaam kiezen uit back-adres' wordt vermeld in de HTTP-instellingen, waarbij de back-adresgroep een geldige FQDN bevat, wordt deze instelling toegepast.

Als er een aangepaste test is gekoppeld aan de HTTP-instellingen, wordt SNI ingesteld op basis van de hostnaam die wordt vermeld in de configuratie van de aangepaste test. Of als Hostnaam kiezen uit de HTTP-instellingen van de back-mail is geselecteerd in de aangepaste test, wordt SNI ingesteld op basis van de hostnaam die wordt vermeld in de HTTP-instellingen.

Als Hostnaam kiezen uit back-adres is ingesteld in de HTTP-instellingen, moet de back-adresgroep een geldige FQDN bevatten.

Als u dit foutbericht ontvangt, komt de CN van het back-endcertificaat niet overeen met de hostnaam die is geconfigureerd in de aangepaste test of de HTTP-instellingen (als Hostnaam kiezen uit DE HTTP-instellingen van de back-ende is geselecteerd). Als u een standaardtest gebruikt, wordt de hostnaam ingesteld op 127.0.0.1. Als dat geen gewenste waarde is, moet u een aangepaste test maken en deze koppelen aan de HTTP-instellingen.

Oplossing:

Volg deze stappen om het probleem op te lossen.

Voor 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 certmgr.msc in en selecteer Enter. U kunt ook zoeken naar Certificaatbeheer in het menu Start.

4. Zoek het certificaat (meestal in \Certificates - Current User\\Personal\\Certificates ) en open het certificaat.

5. Controleer op het tabblad Details het certificaat Onderwerp.

6. Controleer de CN van het certificaat in de details en voer hetzelfde in het veld hostnaam van de aangepaste test of in de HTTP-instellingen in (als Hostnaam kiezen uit de HTTP-instellingen van de back-ende is geselecteerd). Als dit niet de gewenste hostnaam voor uw website is, moet u een certificaat voor dat domein verkrijgen of de juiste hostnaam invoeren in de configuratie van de aangepaste test of HTTP-instelling.

Voor Linux met OpenSSL:

1. Voer deze opdracht uit in OpenSSL:

   openssl x509 -in certificate.crt -text -noout
   

2. Zoek in de weergegeven eigenschappen de CN van het certificaat en voer hetzelfde in het veld hostnaam van de HTTP-instellingen in. Als dit niet de gewenste hostnaam voor uw website is, moet u een certificaat voor dat domein verkrijgen of de juiste hostnaam invoeren in de configuratie van de aangepaste test of HTTP-instelling.

Back-endcertificaat is ongeldig

Bericht: Het back-endcertificaat is ongeldig. De huidige datum valt niet binnen het " bereik Geldig van en Geldig tot heden op het " " " certificaat.

Oorzaak: Elk certificaat wordt geleverd met een geldigheidsbereik en de HTTPS-verbinding is niet beveiligd, tenzij het TLS/SSL-certificaat van de server geldig is. De huidige gegevens moeten binnen het geldige van en geldig zijn voor het bereik. Als dat niet het probleem is, wordt het certificaat als ongeldig beschouwd en wordt er een beveiligingsprobleem met de Application Gateway back-endserver als Beschadigd markeert.

Oplossing: Als uw TLS/SSL-certificaat is verlopen, vernieuwt u het certificaat bij uw leverancier en werkt u de serverinstellingen bij met het nieuwe certificaat. Als het een zelf-ondertekend certificaat is, moet u een geldig certificaat genereren en het basiscertificaat uploaden naar Application Gateway HTTP-instellingen. Voer hiervoor de volgende stappen uit:

1. Open uw Application Gateway HTTP-instellingen in de portal.

2. Selecteer de instelling met het verlopen certificaat, selecteer Certificaat toevoegen en open het nieuwe certificaatbestand.

3. Verwijder het oude certificaat met behulp van het pictogram Verwijderen naast het certificaat en selecteer opslaan.

Verificatie van certificaat is mislukt

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

Oorzaak: Deze fout treedt Application Gateway de geldigheid van het certificaat niet kan verifiëren.

Oplossing: U kunt dit probleem oplossen door te controleren of het certificaat op uw server correct is gemaakt. U kunt bijvoorbeeld OpenSSL gebruiken om het certificaat en de eigenschappen ervan te controleren en vervolgens proberen het certificaat opnieuw te uploaden naar Application Gateway HTTP-instellingen.

Status van back-en-die: onbekend

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

Dit gedrag kan een of meer van de volgende oorzaken hebben:

1. De NSG op het Application Gateway-subnet blokkeert de inkomende toegang tot de 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 is niet opgegeven als 'Internet'.
3. De standaardroute wordt geadverteerd door een ExpressRoute-/VPN-verbinding met een virtueel netwerk via BGP.
4. De aangepaste DNS-server is geconfigureerd in een virtueel netwerk dat geen openbare domeinnamen kan omzetten.
5. Application Gateway heeft de status Niet in orde.

Oplossing:

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

   a. Selecteer op Application Gateway tabblad Overzicht de koppeling Virtual Network/Subnet.

   b. Selecteer op het tabblad Subnetten van uw virtuele netwerk het subnet Application Gateway is geïmplementeerd.

   c. Controleer of er een NSG is geconfigureerd.

   d. Als er 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 binnenkomende verkeer een binnenkomende regel toe om het doelpoortbereik 65503-65534 toe te staan voor v1 SKU of 65200-65535 v2 SKU met de bron ingesteld op Any of Internet.

   f. Selecteer Opslaan en controleer of u de back-end kunt weergeven als In orde. U kunt dit ook doen via PowerShell/CLI.

2. Controleer of uw UDR een standaardroute heeft (0.0.0.0/0) en of de volgende hop niet is ingesteld op Internet:

   a. Volg stap 1a en 1b om uw subnet te bepalen.

   b. Controleer of er een UDR is geconfigureerd. Als dat zo is, zoekt u de resource op de zoekbalk of onder Alle resources.

   c. Controleer of er standaardroutes zijn (0.0.0.0/0) en of de volgende hop niet is ingesteld op Internet. Als de instelling Virtueel apparaat of Virtual Network-gateway is, moet u ervoor zorgen dat uw virtuele apparaat of het on-premises apparaat het pakket op de juiste manier naar het internetdoel kan terugrouteeren zonder het pakket te wijzigen.

   d. Anders wijzigt u de volgende hop in Internet, selecteert u Opslaan en controleert u de back-end-status.

3. Standaardroute die wordt geadverteerd door de ExpressRoute-/VPN-verbinding met het virtuele netwerk via BGP:

   a. Als u een ExpressRoute-/VPN-verbinding met het virtuele netwerk via BGP hebt en als u een standaardroute adverteert, moet u ervoor zorgen dat het pakket wordt teruggeleid naar de internetbestemming zonder deze te wijzigen. U kunt dit controleren met behulp van de optie Verbinding oplossen in Application Gateway portal.

   b. Kies de bestemming handmatig als een via internet routeerbaar IP-adres, zoals 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 server (of servers) openbare domeinen kan oplossen. Openbare domeinnaamoplossing kan vereist zijn in scenario's waarin Application Gateway externe domeinen, zoals OCSP-servers, moeten bereiken of de intrekkingsstatus van het certificaat moeten controleren.

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

Volgende stappen

Meer informatie over Application Gateway en logboekregistratie.