Řešení potíží se stavem back-endu ve službě Application Gateway

Přehled

Azure Application Gateway ve výchozím nastavení testuje stav back-endových serverů a kontroluje, jestli jsou připravené obsluhovat požadavky. Uživatelé také mohou vytvořit vlastní sondy, které by uváděly název hostitele, cestu k testování a stavové kódy, které budou přijaty jako v pořádku. V obou případech, pokud back-end server neodpoví úspěšně, Application Gateway označí Server jako špatný a přestane předávat požadavky na server. Po úspěšném spuštění serveru Application Gateway pokračuje v předávání požadavků.

Postup kontroly stavu back-endu

Pokud chcete zjistit stav back-endu, můžete na Azure Portal použít stránku stavu back-endu . nebo můžete použít Azure PowerShell, CLInebo REST API.

Stav načtený některou z těchto metod může být kterýkoli z následujících:

• V pořádku

• Není v pořádku

• Neznámý

Pokud je stav back-endu serveru pro server v pořádku, znamená to, že Application Gateway přepošle žádosti na tento server. Pokud ale stav back-endu pro všechny servery v back-end fondu není v pořádku nebo není známý, může dojít k problémům při pokusu o přístup k aplikacím. Tento článek popisuje příznaky, příčinu a řešení jednotlivých zobrazených chyb.

Stav back-endu: špatný stav

Pokud stav back-endu není v pořádku, zobrazení portálu bude vypadat jako na následujícím snímku obrazovky:

nebo pokud používáte dotaz REST API Azure PowerShell, CLI nebo Azure, dostanete odpověď, která bude vypadat přibližně takto:

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

Až obdržíte stav back-end serveru pro všechny servery ve fondu back-end, požadavky se nepředávají na servery a Application Gateway v žádajícím klientovi vrátí chybu "502 chybné brány". Pokud chcete tento problém vyřešit, Projděte si sloupec Podrobnosti na kartě stav back-endu .

Zpráva zobrazená ve sloupci Podrobnosti poskytuje podrobnější přehled o problému a na základě těchto informací můžete začít s řešením tohoto problému.

Chybové zprávy

Časový limit back-endu serveru

Zpráva: Doba, kterou back-end má reagovat na test stavu služby Application Gateway ' s, je větší než prahová hodnota časového limitu v nastavení sondy.

Příčina: Po Application Gateway odešle back-end serveru požadavek na test HTTP (S), čeká na odpověď serveru back-end po nakonfigurované období. Pokud back-end server nereaguje v rámci nakonfigurovaného období (hodnota časového limitu), označí se jako špatný, dokud znovu nezačne reagovat v nakonfigurovaném časovém limitu.

Řešení: Ověřte, proč back-end Server nebo aplikace nereaguje v nakonfigurovaném časovém limitu, a také ověřte závislosti aplikací. Například ověřte, zda má databáze nějaké problémy, které mohou aktivovat zpoždění v reakci. Pokud víte o chování aplikace a chcete odpovědět jenom po hodnotě časového limitu, zvyšte hodnotu časového limitu z nastavení vlastního testu paměti. Pokud chcete změnit hodnotu časového limitu, musíte mít vlastní test. Informace o tom, jak nakonfigurovat vlastní test paměti, najdete na stránce s dokumentací.

K zvýšení hodnoty časového limitu použijte následující postup:

1. Přihlaste se k back-end serveru přímo a ověřte čas potřebný k reakci serveru na této stránce. Pro přístup k back-end serveru, včetně prohlížeče pomocí vývojářských nástrojů, můžete použít libovolný nástroj.

2. Až zadáte čas potřebný k reakci aplikace, vyberte kartu sondy stavu a potom vyberte sondu, která je přidružená k nastavení http.

3. Zadejte libovolnou hodnotu časového limitu, která je větší než doba odezvy aplikace v sekundách.

4. Uložte vlastní nastavení sondy a ověřte, jestli stav back-endu je teď v pořádku.

Chyba rozlišení DNS

Zpráva: Application Gateway nemohl pro tento back-end vytvořit test paměti. K tomu obvykle dochází v případě nesprávně zadaného plně kvalifikovaného názvu domény back-endu.

Příčina: pokud je back-end fond typu IP adresa nebo plně kvalifikovaný název domény nebo App Service, Application Gateway se přeloží na IP adresu plně kvalifikovaného názvu domény zadaného pomocí DNS (Domain Name System) (vlastní nebo výchozí Azure) a pokusí se připojit k serveru na portu TCP zmíněném v Nastavení HTTP. Pokud se ale zobrazí tato zpráva, je navržena tak, že Application Gateway nedokázala úspěšně přeložit IP adresu zadaného plně kvalifikovaného názvu domény.

Řešení:

1. Ověřte, že plně kvalifikovaný název domény zadaný ve fondu back-end je správný a že se jedná o veřejnou doménu, a zkuste ho vyřešit z místního počítače.

2. Pokud IP adresu vyřešíte, může se stát, že v konfiguraci DNS ve virtuální síti dojde k nějakému problému.

3. Ověřte, jestli je virtuální síť nakonfigurovaná s vlastním serverem DNS. Pokud je, podívejte se na server DNS o tom, proč se nedá přeložit na IP adresu zadaného plně kvalifikovaného názvu domény.

4. Pokud používáte výchozí DNS Azure, zaregistrujte se od svého registrátora názvu domény, jestli je dokončený záznam nebo mapování záznamů CNAME.

5. Pokud je doména soukromá nebo interní, zkuste ji vyřešit z virtuálního počítače ve stejné virtuální síti. Pokud je můžete vyřešit, restartujte Application Gateway a znovu se vraťte. Pokud chcete restartovat Application Gateway, musíte zastavit a Spustit pomocí příkazů PowerShellu popsaných v těchto propojených prostředcích.

Aktualizace záznamů DNS fondu back-endu

Zpráva: Nepovedlo se načíst stav back-endu. K tomu dojde v případě, že NSG/UDR/firewall v podsíti služby Application Gateway blokuje provoz na portech 65503-65534 v případě SKU V1 a porty 65200-65535 v případě SKU verze 2 nebo pokud nebyl plně kvalifikovaný název domény nakonfigurovaný ve fondu back-end přeložen na IP adresu. Další informace najdete tady: https://aka.ms/UnknownBackendHealth .

Příčina: Application Gateway překládá položky DNS pro back-end fond v době spuštění a neaktualizuje je dynamicky při spuštění.

Řešení:

Application Gateway se musí restartovat po jakékoli změně položek DNS back-endu serveru, aby se začaly používat nové IP adresy. tuto operaci je možné dokončit prostřednictvím Azure PowerShell nebo pomocí 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>

Chyba připojení TCP

Zpráva: Application Gateway se nepovedlo připojit k back-endu. Zkontrolujte prosím, že back-end reaguje na port použitý pro test paměti. Také ověřte, zda jakákoli NSG/UDR/firewall blokuje přístup k IP adrese a portu tohoto back-endu.

Příčina: Po fázi překladu DNS se Application Gateway pokusí připojit k back-end serveru na portu TCP, který je nakonfigurovaný v nastavení HTTP. Pokud Application Gateway nemůže na zadaném portu vytvořit relaci TCP, sonda je označena jako poškozená s touto zprávou.

Řešení: Pokud se zobrazí tato chyba, postupujte následovně:

1. Ověřte, jestli se můžete připojit k back-end serveru na portu uvedeném v nastavení HTTP pomocí prohlížeče nebo PowerShellu. Například spusťte následující příkaz: Test-NetConnection -ComputerName www.bing.com -Port 443

2. Pokud uvedený port není požadovaným portem, zadejte správné číslo portu pro Application Gateway připojení k back-endu serveru.

3. Pokud se na portu nemůžete připojit i z místního počítače, pak:

   a. Ověřte nastavení skupiny zabezpečení sítě (NSG) síťového adaptéru a podsítě back-end serveru a zda jsou povolená příchozí připojení k nakonfigurovanému portu. Pokud ne, vytvořte nové pravidlo, které povolí připojení. Informace o tom, jak vytvořit pravidla NSG, najdete na stránce s dokumentací.

   b. Ověřte, zda nastavení NSG podsítě Application Gateway umožňují odchozí veřejné a soukromé přenosy, aby bylo možné vytvořit připojení. Další informace o vytváření pravidel NSG najdete na stránce dokumentu, která je k dispozici v kroku 3a.

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

   c. Ověřte nastavení trasy definované uživatelem (UDR) Application Gateway a podsíť back-end serveru pro všechny anomálie směrování. Ujistěte se, že UDR nesměruje provoz mimo podsíť back-endu. Můžete třeba vyhledat trasy k síťovým virtuálním zařízením nebo výchozí trasy inzerované do Application Gateway podsítě prostřednictvím Azure ExpressRoute a/nebo VPN.

   d. K ověření efektivních tras a pravidel pro síťový adaptér můžete použít následující příkazy PowerShellu:

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

4. Pokud nenajdete žádné problémy s NSG nebo UDR, Projděte si back-end Server pro problémy související s aplikacemi, které brání klientům v navázání relace TCP na portech nakonfigurovaných. Můžete kontrolovat několik věcí:

   a. Otevřete příkazový řádek (Win + R- > cmd), zadejte netstat a vyberte Enter.

   b. Ověřte, zda server naslouchá na portu, který je nakonfigurován. Například:

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

   c. Pokud nenaslouchá na konfigurovaném portu, ověřte nastavení svého webového serveru. Například: vazby webu ve službě IIS, server Block v NGINX a Virtual Host v Apache.

   d. Zkontrolujte nastavení brány firewall pro operační systém a ujistěte se, že je příchozí provoz na port povolen.

Neshoda stavového kódu HTTP

Zpráva: Stavový kód odpovědi HTTP back-end se ' neshoduje s nastavením testu paměti. Očekávalo se: {HTTPStatusCode0} přijatých: {HTTPStatusCode1}.

Příčina: Po navázání připojení TCP a provedení TLS handshake (Pokud je povolený protokol TLS) Application Gateway odešle test jako požadavek HTTP GET na back-end Server. Jak je popsáno výše, výchozí sonda bude <protocol> ://127.0.0.1: <port> /a považuje se za stavové kódy odpovědí ve formátu Rage 200 až 399 jako v pořádku. Pokud server vrátí jakýkoliv jiný stavový kód, bude tato zpráva označena jako poškozená.

Řešení: V závislosti na kódu odpovědi back-end serveru můžete provést následující kroky. Tady jsou uvedené některé běžné stavové kódy:

Pokud si myslíte, že odpověď je legitimní a chcete, aby Application Gateway přijímala další stavové kódy jako v pořádku, můžete vytvořit vlastní test. Tento přístup je užitečný v situacích, kdy back-end web potřebuje ověřování. Vzhledem k tomu, že požadavky sondy neobsahují žádné přihlašovací údaje uživatele, selžou, že back-end server vrátí stavový kód HTTP 401.

Pokud chcete vytvořit vlastní test paměti, postupujte podle těchto kroků.

Neshoda textu odpovědi HTTP

Zpráva: Tělo odpovědi HTTP back-end ' s neodpovídá nastavení testu paměti. Přijatý text odpovědi neobsahuje {String}.

Příčina: Když vytvoříte vlastní test, budete mít možnost označit back-end Server jako zdravý v závislosti na řetězci z těla odpovědi. Můžete například nakonfigurovat Application Gateway pro přijetí "neautorizovaného" jako řetězce, který se má shodovat. Pokud odpověď serveru back-end pro požadavek sondy obsahuje neoprávněný řetězec, bude označena jako v pořádku. V opačném případě bude tato zpráva označena jako poškozená.

Řešení: Chcete-li tento problém vyřešit, postupujte podle následujících kroků:

1. Přihlaste se k serveru back-end místně nebo z klientského počítače v cestě testu a ověřte tělo odpovědi.

2. Ověřte, že tělo odpovědi v Application Gateway konfiguraci vlastního testu paměti se shoduje s nakonfigurovaným nastavením.

3. Pokud se neshodují, změňte konfiguraci sondy tak, aby bylo možné přijmout správnou hodnotu řetězce.

Přečtěte si další informace o Application Gateway shodě.

Neplatná CA certifikátu back-end serveru

Zpráva: Certifikát serveru používaný back-end není podepsán známou certifikační autoritou (CA). Povolí back-end na Application Gateway tím, že se nahraje kořenový certifikát certifikátu serveru používaného back-endu.

Příčina: Komplexní protokol SSL s Application Gateway v2 vyžaduje ověření certifikátu back-end serveru, aby bylo možné považovat Server za v pořádku. Aby byl certifikát TLS/SSL důvěryhodný, musí být certifikát serveru back-end vydaný certifikační autoritou, která je součástí důvěryhodného úložiště Application Gateway. Pokud certifikát nebyl vydán důvěryhodnou certifikační autoritou (například při použití certifikátu podepsaného svým držitelem), musí uživatelé odeslat certifikát vystavitele do Application Gateway.

Řešení: Pomocí těchto kroků exportujte důvěryhodný kořenový certifikát a nahrajte ho do Application Gateway. (tyto kroky jsou pro klienty Windows.)

1. Přihlaste se k počítači, ve kterém je vaše aplikace hostovaná.

2. Vyberte Win + R nebo klikněte pravým tlačítkem na tlačítko Start a pak vyberte Spustit.

3. Zadejte certmgr.msc a vyberte Enter. Správce certifikátů můžete také vyhledat v nabídce Start .

4. Vyhledejte certifikát, obvykle v \Certificates - Current User\\Personal\\Certificates\ a otevřete ho.

5. Vyberte kořenový certifikát a pak vyberte Zobrazit certifikát.

6. Ve vlastnostech certifikátu vyberte kartu Podrobnosti .

7. Na kartě Podrobnosti vyberte možnost Kopírovat do souboru a uložte soubor v souboru X. 509 s kódováním Base-64 (. CER) formátu.

8. v Azure Portal otevřete stránku Application Gateway HTTP Nastavení .

9. Otevřete nastavení HTTP, vyberte Přidat certifikát a vyhledejte soubor certifikátu, který jste právě uložili.

10. Vyberte Uložit a uložte nastavení http.

Alternativně můžete exportovat kořenový certifikát z klientského počítače přímým přístupem k serveru (obejít Application Gateway) prostřednictvím prohlížeče a exportem kořenového certifikátu z prohlížeče.

Další informace o extrakci a nahrání důvěryhodných kořenových certifikátů v Application Gateway najdete v tématu Export důvěryhodného kořenového certifikátu (pro SKU verze 2).

Neshoda důvěryhodných kořenových certifikátů

Zpráva: Kořenový certifikát serveru, který používá back-end, se neshoduje s důvěryhodným kořenovým certifikátem přidaným do aplikační brány. Ujistěte se, že jste přidali správný kořenový certifikát pro povolenýchí back-endu.

Příčina: Komplexní protokol SSL s Application Gateway v2 vyžaduje ověření certifikátu back-end serveru, aby bylo možné považovat Server za v pořádku. Aby byl certifikát TLS/SSL důvěryhodný, musí být certifikát serveru back-end vydaný certifikační autoritou, která je součástí důvěryhodného úložiště Application Gateway. Pokud certifikát nebyl vydán důvěryhodnou certifikační autoritou (například byl použit certifikát podepsaný svým držitelem), musí uživatelé odeslat certifikát vystavitele do Application Gateway.

Certifikát, který byl nahrán do Application Gateway nastavení HTTP, se musí shodovat s kořenovým certifikátem certifikátu back-end serveru.

Řešení: Pokud se zobrazí tato chybová zpráva, dojde k neshodě mezi certifikátem, který byl nahrán do Application Gateway a ten, který byl nahrán na back-end Server.

Při nahrávání správného důvěryhodného kořenového certifikátu do Application Gateway postupujte podle kroků 1-11 v předchozí metodě.

Další informace o extrakci a nahrání důvěryhodných kořenových certifikátů v Application Gateway najdete v tématu Export důvěryhodného kořenového certifikátu (pro SKU verze 2).

Například:

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

Pokud výstup nezobrazuje úplný řetěz vráceného certifikátu, exportujte certifikát znovu s úplným řetězcem, včetně kořenového certifikátu. Nakonfigurujte tento certifikát na back-end serveru.

  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-----

Neplatný běžný název certifikátu back-endu (CN)

Zpráva: Běžný název (CN) certifikátu back-endu se neshoduje s hlavičkou hostitele sondy.

Příčina: Application Gateway ověří, jestli název hostitele zadaný v nastavení HTTP back-endu odpovídá hodnotě CN, kterou prezentuje certifikát TLS/SSL serveru back-end. Toto je Standard_v2 a chování WAF_v2 SKU (v2). Standard a WAF SKU (V1) Indikace názvu serveru (SNI) se nastaví jako plně kvalifikovaný název domény v adrese back-endu fondu. Další informace o chování SNI a rozdílech mezi systémem V1 a 2 SKU najdete v tématu Přehled ukončení protokolu TLS a koncového protokolu TLS s Application Gateway.

Pokud ve skladové položce v2 existuje výchozí sonda (není nakonfigurovaný a přidružený žádný vlastní test paměti), SNI se nastaví z názvu hostitele uvedeného v nastavení HTTP. Nebo, pokud je v nastavení HTTP uveden příkaz "vybrat název hostitele z back-endové adresy", bude použito toto nastavení.

Pokud je k nastavení HTTP přidružená vlastní sonda, SNI se nastaví z názvu hostitele uvedeného v konfiguraci vlastního testu. Nebo, pokud se ve vlastním testu vybere možnost Vybrat název hostitele z back-endu http , sni se nastaví z názvu hostitele uvedeného v nastavení http.

Pokud je v nastavení HTTP nastavená možnost Vybrat název hostitele z back-endu , musí fond adres pro back-end obsahovat platný plně kvalifikovaný název domény.

Pokud se zobrazí tato chybová zpráva, název certifikátu back-endu neodpovídá názvu hostitele nakonfigurovaného ve vlastní sondě nebo nastavení HTTP (pokud je vybraná možnost Vybrat název hostitele z nastavení HTTP back-endu). Pokud používáte výchozí sondu, název hostitele se nastaví na 127.0.0.1. Pokud to není požadovaná hodnota, měli byste vytvořit vlastní sondu a přidružit ji k nastavení HTTP.

Řešení:

Pokud chcete tento problém vyřešit, použijte následující postup.

Ve Windows:

1. Přihlaste se k počítači, kde je vaše aplikace hostovaná.

2. Vyberte Win+R nebo klikněte pravým tlačítkem na tlačítko Start a vyberte Spustit.

3. Zadejte certmgr.msc a stiskněte Enter. Správce certifikátů můžete vyhledat také v nabídce Start.

4. Vyhledejte certifikát (obvykle v \Certificates - Current User\\Personal\\Certificates souboru ) a otevřete ho.

5. Na kartě Podrobnosti zkontrolujte předmět certifikátu.

6. Ověřte název certifikátu z podrobností a do pole názvu hostitele vlastní sondy nebo v nastavení HTTP (pokud je vybraná možnost Vybrat název hostitele z nastavení HTTP back-endu). Pokud to není požadovaný název hostitele pro váš web, musíte získat certifikát pro doménu nebo zadat správný název hostitele ve vlastní konfiguraci sondy nebo nastavení HTTP.

Pro Linux s využitím OpenSSL:

1. V OpenSSL spusťte tento příkaz:

   openssl x509 -in certificate.crt -text -noout
   

2. Ze zobrazených vlastností vyhledejte cn certifikátu a zadejte stejný název do pole název hostitele v nastavení HTTP. Pokud to není požadovaný název hostitele pro váš web, musíte získat certifikát pro doménu nebo zadat správný název hostitele ve vlastní konfiguraci sondy nebo nastavení HTTP.

Certifikát back-endu je neplatný.

Zprávu: Back-endový certifikát je neplatný. Aktuální datum v certifikátu není " v rozsahu Platné od a Platné do " " " data.

Způsobit: Každý certifikát má rozsah platnosti a připojení HTTPS nebude zabezpečené, pokud není platný certifikát TLS/SSL serveru. Aktuální data musí být v rámci platné hodnoty od a platná do rozsahu. Pokud není, certifikát se považuje za neplatný a tím se vytvoří problém se zabezpečením, Application Gateway back-endový server označí jako Není v pořádku.

Řešení: Pokud vypršela platnost vašeho certifikátu TLS/SSL, obnovte certifikát u dodavatele a aktualizujte nastavení serveru novým certifikátem. Pokud se jedná o certifikát podepsaný svým držitelem, musíte vygenerovat platný certifikát a nahrát kořenový certifikát do Application Gateway HTTP. Provedete to podle těchto kroků:

1. Otevřete nastavení Application Gateway HTTP na portálu.

2. Vyberte nastavení s prošlým certifikátem, vyberte Přidat certifikát a otevřete nový soubor certifikátu.

3. Odeberte starý certifikát pomocí ikony Odstranit vedle certifikátu a pak vyberte Uložit.

Ověření certifikátu se nezdařilo.

Zprávu: Platnost certifikátu back-endu se nepokusí ověřit. Pokud chcete zjistit důvod, zkontrolujte diagnostiku OpenSSL a vyhledejte zprávu související s kódem chyby {errorCode}.

Způsobit: K této chybě Application Gateway když nemůžete ověřit platnost certifikátu.

Řešení: Pokud chcete tento problém vyřešit, ověřte, že se certifikát na vašem serveru vytvořil správně. Můžete například použít OpenSSL k ověření certifikátu a jeho vlastností a pak zkusit certifikát znovu nahrát do Application Gateway HTTP.

Stav back-endu: Neznámý

Pokud se stav back-endu zobrazuje jako Neznámý, bude zobrazení portálu vypadat podobně jako na následujícím snímku obrazovky:

K tomuto chování může dojít z jednoho nebo několika následujících důvodů:

1. NSG v podsíti Application Gateway blokuje příchozí přístup k portům 65503–65534 (skladová položku v1) nebo 65200–65535 (skladová položku v2) z internetu.
2. Trasa UDR v podsíti Application Gateway je nastavená na výchozí trasu (0.0.0.0/0) a další segment směrování není zadaný jako Internet.
3. Výchozí trasa je inzerována připojením ExpressRoute nebo VPN k virtuální síti přes protokol BGP.
4. Vlastní server DNS je nakonfigurovaný ve virtuální síti, která nemůže překládat názvy veřejných domén.
5. Application Gateway je ve stavu Není v pořádku.

Řešení:

1. Zkontrolujte, jestli vaše NSG neblokuje přístup k portům 65503–65534 (skladová položku v1) nebo 65200–65535 (skladová položku v2) z internetu:

   a. Na Application Gateway Přehled vyberte odkaz Virtual Network/Podsíť.

   b. Na kartě Podsítě vaší virtuální sítě vyberte podsíť, Application Gateway je nasazená.

   c. Zkontrolujte, jestli je nakonfigurovaná nějaká NSG.

   d. Pokud je nakonfigurovaná skupina zabezpečení sítě, vyhledejte tento prostředek NSG na kartě Vyhledávání nebo v části Všechny prostředky.

   e. V části Příchozí pravidla přidejte příchozí pravidlo, které povolí rozsah cílových portů 65503–65534 pro SKU v1 nebo 65200–65535 v2 se zdrojovou nastavenou na Libovolná nebo Internet.

   f. Vyberte Uložit a ověřte, že back-end můžete zobrazit jako V pořádku. Alternativně to můžete udělat pomocí PowerShellu nebo rozhraní příkazového řádku.

2. Zkontrolujte, jestli má trasa UDR výchozí trasu (0.0.0.0/0) s dalším segmentem směrování nastaveným na Internet:

   a. Podle kroků 1a a 1b určete podsíť.

   b. Zkontrolujte, jestli je nakonfigurovaná nějaká UDR. Pokud existuje, vyhledejte prostředek na panelu hledání nebo v části Všechny prostředky.

   c. Zkontrolujte, jestli existují nějaké výchozí trasy (0.0.0.0/0) s dalším segmentem směrování nastaveným na Internet. Pokud je toto nastavení buď Virtuální zařízení, nebo Virtual Network Gateway, musíte se ujistit, že virtuální zařízení nebo místní zařízení mohou správně směrovat paket zpět do internetového cíle beze změny paketu.

   d. Jinak změňte další segment směrování na Internet, vyberte Uložit a ověřte stav back-endu.

3. Výchozí trasa inzerovaná připojením ExpressRoute nebo VPN k virtuální síti přes protokol BGP:

   a. Pokud máte připojení ExpressRoute nebo VPN k virtuální síti přes protokol BGP a inzerujete výchozí trasu, musíte se ujistit, že se paket směruje zpět do internetového cíle, aniž byste ho museli upravovat. Můžete to ověřit pomocí možnosti Řešení potíží s připojením na Application Gateway Portal.

   b. Jako cíl zvolte ručně libovolnou IP adresu směrovatelná do internetu, například 1.1.1.1. Nastavte cílový port jako cokoli a ověřte připojení.

   c. Pokud je dalším segmentem směrování brána virtuální sítě, může být inzerovaná výchozí trasa přes ExpressRoute nebo VPN.

4. Pokud je ve virtuální síti nakonfigurovaný vlastní server DNS, ověřte, že server (nebo servery) dokáže přeložit veřejné domény. Překlad názvů veřejných domén může být nutný ve scénářích, kdy Application Gateway musí kontaktovat externí domény, jako jsou servery OCSP, nebo zkontrolovat stav odvolání certifikátu.

5. Pokud chcete ověřit Application Gateway je služba v pořádku a spuštěná, přejděte na Resource Health portálu a ověřte, že je stav V pořádku. Pokud se zobrazí stav Není v pořádku nebo Snížený výkon, kontaktujte podporu.

Další kroky

Další informace o Application Gateway a protokolování.