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

Článek
03/08/2024

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é mohou také vytvořit vlastní sondy, které zmíní název hostitele, cestu k proslovu a stavové kódy, které se mají přijmout jako v pořádku. Pokud ale v každém případě back-endový server nereaguje úspěšně, Application Gateway označí server tak, že „není v pořádku“ a přestane na server předávat požadavky. Jakmile server začne úspěšně reagovat, Application Gateway pokračuje v předávání požadavků.

Postup kontroly stavu back-endu

Ke kontrole stavu back-endového fondu můžete použít stránku Stav back-endu na Azure Portal. Nebo můžete použít Azure PowerShell, CLI nebo rozhraní REST API.

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

V pořádku
Není v pořádku
Neznámý

Služba Application Gateway předá požadavek ze serveru z back-endového fondu, pokud je jeho stav v pořádku. Pokud nejsou všechny servery v back-endovém fondu v pořádku nebo neznámé, klienti můžou narazit na problémy s přístupem k back-endové aplikaci. Přečtěte si další informace o různých zprávách hlášených stavem back-endu, jejich příčinách a jejich řešení.

Poznámka:

Pokud váš uživatel nemá oprávnění k zobrazení stavu back-endu, No results. zobrazí se.

Stav back-endu: Není v pořádku

Pokud stav back-endu není v pořádku, zobrazení portálu se podobá následujícímu snímku obrazovky:

V případě, že používáte dotaz azure PowerShellu, rozhraní příkazového řádku nebo azure REST API, získáte odpověď, která bude vypadat podobně jako v následujícím příkladu:

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

Jakmile se zobrazí stav back-endového serveru, který není v pořádku, pro všechny servery v back-endovém fondu, požadavky se serverům nepřesměrují a Application Gateway vrátí žádajícímu klientovi chybu „502 – chybná brána“. Pokud chcete tento problém vyřešit, zkontrolujte sloupec Podrobnosti na kartě Stav back-endu.

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

Poznámka:

Výchozí požadavek sondy se odešle ve formátu <protokolu>://127.0.0.1:<port>. Například http://127.0.0.1:80 pro sondu HTTP na portu 80. Stavové kódy HTTP 200 až 399 jsou považovány za zdravé. Protokol a cílový port se dědí z nastavení HTTP. Pokud chcete, aby služba Application Gateway testovat jiný protokol, název hostitele nebo cestu a rozpoznala jiný stavový kód jako V pořádku, nakonfigurujte vlastní sondu a přidružte ji k nastavení HTTP.

Chybové zprávy

Časový limit back-endového serveru

Zpráva: Doba odezvy back-endu na test stavu aplikační brány je delší než prahová hodnota časového limitu v nastavení testu.

Příčina: Jakmile služba Application Gateway odešle požadavek testu HTTP(S) na back-endový server, po nakonfigurovanou dobu počká na odpověď z back-endového serveru. Pokud back-endový server během nakonfigurovaného období (hodnota časového limitu) nereaguje, označí se příznakem Není v pořádku, dokud opět nezačne reagovat během nakonfigurovaného časového limitu.

Řešení: Zkontrolujte, proč back-endový server nebo aplikace nereaguje během nakonfigurovaného časového limitu, a také zkontrolujte závislosti aplikací. Zkontrolujte například, jestli databáze nemá nějaké problémy, které by mohly způsobit zpoždění v reakci. Pokud jste si vědomi chování aplikace a ta by měla reagovat až po uplynutí časového limitu, zvyšte hodnotu časového limitu z vlastního nastavení testu. Abyste mohli změnit hodnotu časového limitu, musíte mít vlastní test. Informace o tom, jak nakonfigurovat vlastní sondu, najdete na stránce dokumentace.

Pokud chcete zvýšit hodnotu časového limitu, postupujte takto:

Přejděte přímo k back-endovému serveru a zkontrolujte čas potřebný k tomu, aby server reagoval na této stránce. K přístupu k back-endovému serveru, včetně prohlížeče pomocí vývojářských nástrojů, můžete použít libovolný nástroj.
Jakmile zjistíte čas potřebný k tomu, aby aplikace reagovala, vyberte kartu Sondy stavu a pak vyberte sondu přidruženou k vašemu nastavení HTTP.
Zadejte libovolnou hodnotu časového limitu, která je větší než doba odezvy aplikace v sekundách.
Uložte vlastní nastavení sondy a zkontrolujte, jestli se stav back-endu zobrazuje jako v pořádku.

Chyba překladu DNS

Zpráva: Application Gateway nemohla vytvořit sondu pro tento back-end. 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-endový fond typu IP adresa, plně kvalifikovaný název domény (plně kvalifikovaný název domény) nebo App Service, služba Application Gateway se přeloží na IP adresu plně kvalifikovaného názvu domény zadaného prostřednictvím DNS (vlastní nebo výchozí nastavení Azure). Aplikační brána se pak pokusí připojit k serveru na portu TCP uvedeném v nastavení HTTP. Pokud se však zobrazí tato zpráva, znamená to, že služba Application Gateway nemohla úspěšně přeložit IP adresu zadaného FQDN.

Řešení:

Ověřte, že FQDN zadaný v back-endovém fondu je správný a že je to veřejná doména, a poté se pokuste jej vyřešit z místního počítače.
Pokud můžete IP adresu přeložit, může být něco v nepořádku s konfigurací DNS ve virtuální síti.
Zkontrolujte, jestli je virtuální síť nakonfigurovaná s vlastním serverem DNS. Pokud ano, zkontrolujte na serveru DNS, proč se nemůže přeložit IP adresu zadaného FQDN.
Pokud používáte výchozí DNS Azure, ověřte u svého registrátora názvu domény, jestli se dokončilo správné mapování záznamu A nebo CNAME.
Pokud je doména privátní nebo interní, zkuste ji přeložit z virtuálního počítače ve stejné virtuální síti. Pokud se vám to podaří vyřešit, restartujte Application Gateway a zkontrolujte to znovu. Pokud chcete Application Gateway restartovat, musíte ji zastavit a spustit pomocí příkazů PowerShellu popsaných v těchto připojených prostředcích.

Chyba připojení TCP

Zpráva: Služba Application Gateway se nemohla připojit k back-endu. Zkontrolujte, jestli back-end reaguje na portu použitém pro test. Zkontrolujte také, zda nějaká skupina zabezpečení sítě definovaná uživatelem nebo brána firewall neblokuje 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-endovému serveru na portu TCP, který je nakonfigurovaný v nastavení HTTP. Pokud Application Gateway nemůže navázat relaci TCP na zadaném portu, je test označen jako „není v pořádku“ s touto zprávou.

Řešení: Pokud se zobrazí tato chyba, postupujte takto:

Pomocí prohlížeče nebo PowerShellu zkontrolujte, jestli se můžete připojit k back-endovému serveru na portu uvedeném v nastavení HTTP. Spusťte například následující příkaz: Test-NetConnection -ComputerName www.bing.com -Port 443.
Pokud uvedený port není požadovaným portem, zadejte správné číslo portu pro připojení ke službě Application Gateway k back-endovému serveru.
Pokud se na portu nemůžete připojit i z místního počítače, postupujte takto:

a. Zkontrolujte nastavení skupiny zabezpečení sítě (NSG) síťového adaptéru a podsítě back-endového serveru a ověřte, jestli jsou povolená příchozí připojení k nakonfigurovaným portům. Pokud ne, vytvořte nové pravidlo, které povolí připojení. Informace o vytváření pravidel NSG najdete na stránce dokumentace.

b. Zkontrolujte, jestli nastavení skupiny zabezpečení sítě podsítě služby Application Gateway umožňuje odchozí veřejný a privátní provoz, aby bylo možné vytvořit připojení. Další informace o vytváření pravidel NSG najdete na stránce dokumentu uvedené v kroku 3a.
```
        $vnet = Get-AzVirtualNetwork -Name "vnetName" -ResourceGroupName "rgName"
        Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
```
c. Zkontrolujte nastavení tras definovaných uživatelem (UDR) služby Application Gateway a podsítě back-endového serveru, jestli neobsahují žádné anomálie směrování. Ujistěte se, že trasu definovanou uživatelem nesměruje provoz z back-endové podsítě. Zkontrolujte například trasy do síťových virtuálních zařízení nebo výchozích tras inzerovaných do podsítě služby Application Gateway přes Azure ExpressRoute nebo VPN.

d. Pokud chcete zkontrolovat efektivní trasy a pravidla 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"
```
Pokud nenajdete žádné problémy se skupinou zabezpečení sítě nebo trasou definovanou uživatelem, zkontrolujte, jestli váš back-endový server neobsahuje problémy související s aplikacemi, které klientům brání v navázání relace PROTOKOLU TCP na nakonfigurovaných portech. Několik věcí, které je potřeba zkontrolovat:

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

b. Zkontrolujte, jestli server naslouchá na nakonfigurovaném portu. Příklad:
```
        Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
```
c. Pokud na nakonfigurovaný port nenaslouchá, zkontrolujte nastavení webového serveru. Například: vazby lokality ve službě IIS, blok serveru v NGINX a virtuální hostitel v Apache.

d. Zkontrolujte nastavení brány firewall operačního systému a ujistěte se, že je povolený příchozí provoz do portu.

Neshoda stavových kódů HTTP

Zpráva: Stavový kód odpovědi HTTP back-endu neodpovídá nastavení sondy. Byl očekáváno:{HTTPStatusCode0} přijato:{HTTPStatusCode1}.

Příčina: Po navázání připojení TCP a provedení metody handshake protokolu TLS (pokud je povolený protokol TLS) služba Application Gateway odešle na back-endový server test jako požadavek HTTP GET. Jak je popsáno výše, výchozí sonda bude a <protocol>://127.0.0.1:<port>/považuje stavové kódy odpovědí v rozsahu 200 až 399 jako v pořádku. Pokud server vrátí jakýkoli jiný stavový kód, označí se jako není v pořádku s touto zprávou.

Řešení: V závislosti na kódu odpovědi back-endového serveru můžete provést následující kroky. Tady je několik běžných stavových kódů:

Chyba	Akce
Neshoda stavových kódů sondy: Přijato 401	Zkontrolujte, jestli back-endový server vyžaduje ověření. Sondy služby Application Gateway nemůžou předávat přihlašovací údaje pro ověřování. Buď povolte "HTTP 401" ve shodě stavového kódu sondy, nebo sondu na cestu, kde server nevyžaduje ověření.
Neshoda stavových kódů sondy: Přijato 403	Přístup je zakázaný. Zkontrolujte, jestli je na back-endovém serveru povolený přístup k této cestě.
Neshoda stavových kódů sondy: Přijato 404	Stránka nebyla nalezena. Zkontrolujte, jestli je cesta k názvu hostitele přístupná na back-endovém serveru. Změňte název hostitele nebo parametr cesty na přístupnou hodnotu.
Neshoda stavových kódů sondy: Přijato 405	Požadavky sondy pro službu Application Gateway používají metodu HTTP GET. Zkontrolujte, jestli váš server tuto metodu umožňuje.
Neshoda stavových kódů sondy: Přijato 500	Vnitřní chyba serveru. Zkontrolujte stav back-endového serveru a jestli jsou služby spuštěné.
Neshoda stavových kódů sondy: Přijato 503	Nedostupná služba. Zkontrolujte stav back-endového serveru a jestli jsou služby spuštěné.

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

Pokud chcete vytvořit vlastní sondu, postupujte takto.

Neshoda textu odpovědi HTTP

Zpráva: Text odpovědi HTTP back-endu neodpovídá nastavení sondy. Text přijaté odpovědi neobsahuje {string}.

Příčina: Když vytvoříte vlastní sondu, můžete back-endový server označit jako v pořádku tím, že se shoduje s řetězcem z textu odpovědi. Můžete například nakonfigurovat Application Gateway tak, aby jako řetězec, který se má shodovat, přijímal „neautorizováno“. Pokud odpověď back-endového serveru pro požadavek sondy obsahuje řetězec neautorizováno, označí ji jako V pořádku. V opačném případě se označí jako není v pořádku s danou zprávou.

Řešení: Pokud chcete tento problém vyřešit, postupujte takto:

Přístup k back-endovému serveru místně nebo z klientského počítače v cestě sondy a zkontrolujte text odpovědi.
Ověřte, že text odpovědi v konfiguraci vlastní sondy Application Gateway odpovídá nakonfigurované konfiguraci.
Pokud se neshodují, změňte konfiguraci sondy tak, aby v ní byla správná řetězcová hodnota, kterou lze přijmout.

Přečtěte si další informace o porovnávání sond služby Application Gateway.

Poznámka:

Pokud chcete získat další informace o chování SNI a rozdílech mezi skladovou jednotkou v1 a v2, podívejte se na stránku s přehledem protokolu TLS.

Běžný název se neshoduje

Zpráva: (Pro V2) Běžný název listového certifikátu prezentovaného back-endovým serverem neodpovídá názvu hostitele brány Application Gateway v nastavení sondy nebo back-endu.
(Pro V1) Běžný název (CN) back-endového certifikátu se neshoduje.

Příčina: (pro V2) K tomuto problému dochází v případě, že jste v nastavení back-endu vybrali protokol HTTPS, ale název hostitele ve vlastním testu ani v nastavení back-endu (v tomto pořadí) neodpovídá běžnému názvu certifikátu back-endového serveru.
(Pro V1) Plně kvalifikovaný název domény cíle back-endového fondu neodpovídá společnému názvu (CN) certifikátu back-endového serveru.

Řešení: Informace o názvu hostitele jsou důležité pro připojení HTTPS back-endu, protože tato hodnota se používá k nastavení indikace názvu serveru (SNI) během metody handshake protokolu TLS. Tento problém můžete vyřešit následujícími způsoby na základě konfigurace brány.

Pro V2,

Pokud používáte výchozí sondu – název hostitele můžete zadat v přidruženém nastavení back-endu vaší aplikační brány. V nastavení back-endu můžete vybrat možnost Přepsat konkrétním názvem hostitele nebo Vybrat název hostitele z cíle back-endu.
Pokud používáte vlastní sondu – pro vlastní sondu, můžete pomocí pole hostitel zadat běžný název certifikátu back-endového serveru. Pokud je nastavení back-endu už nakonfigurované se stejným názvem hostitele, můžete v nastavení sondy zvolit možnost Vybrat název hostitele z nastavení back-endu.

V případě V1 ověřte, že plně kvalifikovaný název domény cílového back-endového fondu je stejný jako běžný název (CN).

Tipy: Pokud chcete určit běžný název (CN) certifikátu back-endových serverů, můžete použít některou z těchto metod. Všimněte si také, že pokud existuje síť SAN, podle dokumentu RFC 6125 se ověření SNI provádí pouze u daného pole. Pole s běžným názvem se shoduje, pokud v certifikátu není žádná síť SAN.

Pomocí prohlížeče nebo libovolného klienta: Přejděte přímo k back-endovému serveru (ne přes Application Gateway) a kliknutím na zámek certifikátu na adresním řádku zobrazte podrobnosti o certifikátu. Najdete ho v části Vystaveno.
Přihlášením k back-endovému serveru (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 myši na tlačítko Start a vyberte Spustit.
3. Zadejte certlm.msc a vyberte Enter. Správce certifikátů můžete vyhledat také na nabídka Start.
4. Vyhledejte certifikát (obvykle v části Certifikáty – Místní počítač\Osobní\Certifikáty) a otevřete certifikát.
5. Na kartě Podrobnosti zkontrolujte předmět certifikátu.
Přihlášením k back-endovému serveru (Linux): Spuštěním tohoto příkazu OpenSSL zadejte správný název souboru certifikátu. openssl x509 -in certificate.crt -subject -noout

Platnost certifikátu back-endu vypršela

Zpráva: Certifikát back-endu je neplatný. Aktuální datum není v rozsahu dat Valid from a Valid to (Platné do) v certifikátu.

Příčina: Prošlý certifikát se považuje za nebezpečný, a proto aplikační brána označila back-endový server s prošlým certifikátem příznakem Není v pořádku.

Řešení: Řešení závisí na tom, která část řetězu certifikátů vypršela na back-endovém serveru.

Pro skladovou položku V2,

List s vypršenou platností (označovaný také jako doména nebo server) – Obnovte certifikát serveru u poskytovatele certifikátu a nainstalujte nový certifikát na back-endový server. Ujistěte se, že jste nainstalovali kompletní řetěz certifikátů složený z .Leaf (topmost) > Intermediate(s) > Root Na základě typu certifikační autority (CA) můžete u brány provést následující akce.
- Veřejně známá certifikační autorita: Pokud je vystavitel certifikátu dobře známou certifikační autoritou, nemusíte na aplikační bráně provádět žádnou akci.
- Privátní certifikační autorita: Pokud je listový certifikát vystavený privátní certifikační autoritou, musíte zkontrolovat, jestli se změnil podpisový certifikát kořenové certifikační autority. V takových případech musíte nahrát nový certifikát kořenové certifikační autority (. CER) do přidruženého nastavení back-endu vaší brány.
Zprostředkující nebo kořenový certifikát s vypršenou platností – tyto certifikáty mají obvykle relativně delší dobu platnosti (desetiletí nebo dvě). Po vypršení platnosti kořenového nebo zprostředkujícího certifikátu doporučujeme zkontrolovat u zprostředkovatele certifikátu obnovené soubory certifikátů. Ujistěte se, že jste nainstalovali aktualizovaný a úplný řetěz certifikátů skládající se Leaf (topmost) > Intermediate(s) > Root z back-endového serveru.
- Pokud kořenový certifikát zůstane beze změny nebo pokud je vystavitel dobře známou certifikační autoritou, nemusíte u aplikační brány provádět žádnou akci.
- Pokud se při použití privátní certifikační autority změnil certifikát kořenové certifikační autority nebo kořen obnoveného zprostředkujícího certifikátu, musíte nový kořenový certifikát nahrát do back-endového nastavení služby Application Gateway.

Pro skladovou položku V1,

Prodlužte platnost certifikátu typu List (označovaný také jako doména nebo server) s certifikační autoritou a nahrajte stejný listový certifikát (. CER) k přidruženému nastavení back-endu vaší aplikační brány.

Zprostředkující certifikát se nenašel

Zpráva: V řetězu certifikátů předaný back-endovým serverem chybí zprostředkující certifikát. Ujistěte se, že je řetěz certifikátů úplný a správně seřazený na back-endovém serveru.

Příčina: Zprostředkující certifikáty nejsou nainstalované v řetězu certifikátů na back-endovém serveru.

Řešení: K podepsání certifikátu List se používá zprostředkující certifikát, který je proto nutný k dokončení řetězu. Požádejte svou certifikační autoritu (CA) o potřebné zprostředkující certifikáty a nainstalujte je na back-endový server. Tento řetěz musí začínat koncovým certifikátem, pak musí následovat zprostředkovatelské certifikáty a nakonec kořenový certifikát CA. Doporučujeme na back-endový server nainstalovat kompletní řetěz, včetně kořenového certifikátu certifikační autority. Pro referenci se podívejte na příklad řetězu certifikátů v části List musí být nejvrchnější v řetězu.

Poznámka:

Certifikát podepsaný svým držitelem, který není certifikační autoritou, způsobí také stejnou chybu. Důvodem je to, že aplikační brána považuje takový certifikát podepsaný svým držitelem jako listový certifikát a hledá podpisový zprostředkující certifikát. Podle tohoto článku můžete správně vygenerovat certifikát podepsaný svým držitelem.

Tyto obrázky ukazují rozdíl mezi certifikáty podepsanými svým držitelem.

Certifikát typu list nebo server nebyl nalezen.

Zpráva: V řetězu certifikátů předaný back-endovým serverem chybí listový certifikát. Ujistěte se, že je řetěz dokončený a správně seřazený na back-endovém serveru.

Příčina: V řetězu certifikátů na back-endovém serveru chybí koncový certifikát (označovaný také jako doména nebo server).

Řešení: Listový certifikát můžete získat z certifikační autority (CA). Nainstalujte tento koncový certifikát (list) a všechny jeho podpisové certifikáty (zprostředkovatelské a kořenové certifikáty CA) na back-endový server. Tento řetěz musí začínat koncovým certifikátem, pak musí následovat zprostředkovatelské certifikáty a nakonec kořenový certifikát CA. Doporučujeme na back-endový server nainstalovat kompletní řetěz, včetně kořenového certifikátu certifikační autority. Pro referenci se podívejte na příklad řetězu certifikátů v části List musí být nejvrchnější v řetězu.

Certifikát serveru nevystavuje veřejně známá certifikační autorita.

Zpráva: Certifikát back-endového serveru není podepsaný známou certifikační autoritou (CA). Pokud chcete použít neznámé certifikáty certifikační autority, musí se jeho kořenový certifikát nahrát do nastavení back-endu aplikační brány.

Příčina: V nastavení back-endu jste zvolili "dobře známý certifikát certifikační autority", ale kořenový certifikát prezentovaný back-endovým serverem není veřejně známý.

Řešení: Pokud je listový certifikát vystavený privátní certifikační autoritou (CA), musí se podpisový certifikát kořenové certifikační autority nahrát do přidruženého back-endového nastavení služby Application Gateway. To vaší aplikační bráně umožní navázat důvěryhodné připojení k tomuto back-endovému serveru. Pokud chcete tento problém vyřešit, přejděte do přidruženého nastavení back-endu, zvolte „ne tak dobře známá certifikační autorita“ a nahrajte certifikát kořenové certifikační autority (.CER). Pokud chcete identifikovat a stáhnout kořenový certifikát, můžete postupovat stejně jako v části Neshoda důvěryhodných kořenových certifikátů.

Zprostředkující certifikát není podepsaný veřejně známou certifikační autoritou.

Zpráva:Zprostředkující certifikát není podepsaný známou certifikační autoritou (CA). Ujistěte se, že je řetěz certifikátů úplný a správně seřazený na back-endovém serveru.

Příčina: V nastavení back-endu jste zvolili "dobře známý certifikát certifikační autority", ale zprostředkující certifikát prezentovaný back-endovým serverem není podepsaný žádnou veřejně známou certifikační autoritou.

Řešení: Pokud certifikát vydá soukromá certifikační autorita (CA), musí se podpisový certifikát kořenové certifikační autority nahrát do přidruženého back-endového nastavení služby Application Gateway. To vaší aplikační bráně umožní navázat důvěryhodné připojení k tomuto back-endovému serveru. Pokud chcete tento problém vyřešit, obraťte se na privátní certifikační autoritu a požádejte o získání příslušného certifikátu kořenové certifikační autority (. CER) a nahrajte ho . Soubor CER do back-endového nastavení služby Application Gateway výběrem možnosti "Není dobře známá certifikační autorita". Z důvodu snadného ověření také doporučujeme na back-endový server nainstalovat kompletní řetěz, včetně kořenového certifikátu certifikační autority.

Neshoda důvěryhodných kořenových certifikátů (na back-endovém serveru není kořenový certifikát)

Zpráva: Zprostředkující certifikát není podepsaný žádnými kořenovými certifikáty nahranými do aplikační brány. Ujistěte se, že je řetěz certifikátů úplný a správně seřazený na back-endovém serveru.

Příčina: Žádný z certifikátů kořenové certifikační autority (CA) nahraných do přidruženého nastavení back-endu nepodepsal zprostředkovatelský certifikát nainstalovaný na back-endovém serveru. Back-endový server má nainstalované pouze koncové a zprostředkovatelské certifikáty.

Řešení: Listový certifikát je podepsaný zprostředkujícím certifikátem, který je podepsaný certifikátem kořenové certifikační autority. Při použití certifikátu od soukromé certifikační autority (CA) musíte nahrát odpovídající certifikát kořenové CA do aplikační brány. Požádejte svoji soukromou CA o příslušný certifikát kořenové CA (. CER) a nahrajte tento soubor CER do nastavení back-endu vaší aplikační brány.

Neshoda důvěryhodných kořenových certifikátů (kořenový certifikát je k dispozici na back-endovém serveru)

Zpráva: Kořenový certifikát certifikátu serveru používaného back-endem neodpovídá důvěryhodnému kořenovému certifikátu přidanému do aplikační brány. Ujistěte se, že jste přidali správný kořenový certifikát pro povolení back-endu.

Příčina: K této chybě dochází v případě, že žádný z kořenových certifikátů nahraných do nastavení back-endu vaší aplikační brány neodpovídá kořenovému certifikátu na back-endovém serveru.

Řešení: To platí pro certifikát back-endového serveru vystavený certifikační autoritou (CA) nebo se jedná o certifikát podepsaný svým držitelem. Identifikujte a nahrajte správný kořenový certifikát CA do nastavení přidruženého back-endu.

Tipy: K identifikaci a stažení kořenového certifikátu můžete použít některou z těchto metod.

Pomocí prohlížeče: Přejděte přímo k back-endovému serveru (ne přes Application Gateway) a kliknutím na zámek certifikátu na panelu Adresa zobrazte podrobnosti o certifikátu.
1. Zvolte kořenový certifikát v řetězu a klikněte na Exportovat. Ve výchozím nastavení to bude . CRT soubor.
2. Otevřete to . CRT soubor.
3. Přejděte na kartu Podrobnosti a klikněte na Kopírovat do souboru.
4. Na stránce Průvodce exportem certifikátu klikněte na tlačítko Další.
5. Vyberte Kód X.509 s kódováním Base-64 (. CER) a klepněte na tlačítko Další,
6. Zadejte nový název souboru a klikněte na Další.
7. Kliknutím na tlačítko Dokončit získáte položku . Soubor CER.
8. Nahrajte tento kořenový certifikát (. CER) vaší privátní certifikační autority do nastavení back-endu služby Application Gateway.
Přihlášením k back-endovému serveru (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 myši na tlačítko Start a pak vyberte Spustit.
3. Zadejte certlm.msc a vyberte Enter. Správce certifikátů můžete vyhledat také na nabídka Start.
4. Vyhledejte certifikát, obvykle v části Certifikáty – Místní počítač\Osobní\Certifikáty a otevřete ho.
5. Vyberte kořenový certifikát a pak vyberte Zobrazit certifikát.
6. Ve vlastnostech certifikátu vyberte kartu Podrobnosti a klikněte na Kopírovat do souboru.
7. Na stránce Průvodce exportem certifikátu klikněte na tlačítko Další.
8. Vyberte Kód X.509 s kódováním Base-64 (. CER) a klepněte na tlačítko Další,
9. Zadejte nový název souboru a klikněte na Další.
10. Kliknutím na tlačítko Dokončit získáte položku . Soubor CER.
11. Nahrajte tento kořenový certifikát (. CER) vaší privátní certifikační autority do nastavení back-endu služby Application Gateway.

List musí být nejvyšší v řetězci.

Zpráva: Listový certifikát není nejvyšší certifikát v řetězu prezentovaný back-endovým serverem. Ujistěte se, že je řetěz certifikátů správně seřazený na back-endovém serveru.

Příčina: List (označovaný také jako doména nebo server) není nainstalovaný ve správném pořadí na back-endovém serveru.

Řešení: Instalace certifikátu na back-endovém serveru musí obsahovat seřazený seznam certifikátů obsahujících listový certifikát a všechny podpisové certifikáty (zprostředkující a kořenové certifikační autority). Tento řetěz musí začínat certifikátem typu List, pak musí následovat zprostředkující certifikáty a nakonec kořenový certifikát CA. Doporučujeme na back-endový server nainstalovat kompletní řetěz, včetně kořenového certifikátu certifikační autority.

Je to příklad instalace certifikátu serveru spolu s jeho certifikáty zprostředkující a kořenové certifikační autority, označených jako hloubky (0, 1, 2 atd.) v OpenSSL. Stejný certifikát back-endového serveru můžete ověřit pomocí následujících příkazů OpenSSL.
s_client -connect <FQDN>:443 -showcerts
NEBO
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

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

Zpráva: Platnost back-endového certifikátu se nepodařilo ověřit. Pokud chcete zjistit důvod, projděte si diagnostiku OpenSSL pro zprávu přidruženou k chybě s kódem chyby {errorCode}.

Příčina: K této chybě dochází, když Application Gateway nemůže 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 správně vytvořil. K ověření certifikátu a jeho vlastností můžete použít například OpenSSL a pak zkuste certifikát znovu nahrát do nastavení HTTP služby Application Gateway.

Stav back-endu: Neznámý

Aktualizace položek DNS back-endového fondu

Zpráva: Stav back-endu nelze načíst. K tomu dochází v případě, že skupina zabezpečení sítě, UDR nebo brána firewall v podsíti služby Application Gateway blokuje provoz na portech 65503-65534 v případě skladové položky v1 a porty 65200-65535 v případě skladové položky v2 nebo pokud plně kvalifikovaný název domény nakonfigurovaný v back-endovém fondu nejde přeložit na IP adresu. Další informace naleznete - https://aka.ms/UnknownBackendHealth.

Příčina: U back-endových cílů založených na plně kvalifikovaném názvu domény (FQDN) služba Application Gateway ukládá do mezipaměti a používá poslední známou IP adresu, pokud se nepodaří získat odpověď pro následné vyhledávání DNS. Operace PUT na bráně v tomto stavu by úplně vymaže mezipaměť DNS. V důsledku toho nebude žádná cílová adresa, ke které se brána může připojit.

Řešení: Zkontrolujte a opravte servery DNS a ujistěte se, že obsluhuje odpověď pro dané vyhledávání DNS plně kvalifikovaného názvu domény. Musíte také zkontrolovat, jestli jsou servery DNS dostupné prostřednictvím virtuální sítě vaší aplikační brány.

Další důvody

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

Application Gateway backend health - Unknown

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

Skupina zabezpečení sítě v podsíti služby Application Gateway blokuje příchozí přístup k portům 65503-65534 (skladová položka v1) nebo 65200-65535 (skladová položka v2) z internetu.
Trasa definovaná uživatelem v podsíti služby Application Gateway je nastavená na výchozí trasu (0.0.0.0/0) a další segment směrování není zadaný jako internet.
Výchozí trasa se do virtuální sítě inzeruje přes protokol BGP a připojení ExpressRoute nebo VPN.
Vlastní server DNS je nakonfigurovaný ve virtuální síti, která nemůže překládat názvy veřejných domén.
Application Gateway je ve stavu Není v pořádku.

Řešení:

Zkontrolujte, jestli vaše skupina zabezpečení sítě blokuje přístup k portům 65503-65534 (skladová položka v1) nebo 65200-65535 (skladová položka v2) z internetu:

a. Na kartě Přehled služby Application Gateway vyberte odkaz Virtuální síť nebo podsíť. b. Na kartě Podsítě vaší virtuální sítě vyberte podsíť, do které je nasazená služba Application Gateway. c. Zkontrolujte, jestli je nakonfigurovaná nějaká skupina zabezpečení sítě. d. Pokud je skupina zabezpečení sítě nakonfigurovaná, vyhledejte tento prostředek NSG na kartě Hledá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 skladovou položku v1 nebo skladovou položku 65200-65535 v2 se značkou Zdroj nastavený jako značka služby GatewayManager. f. Vyberte Uložit a ověřte, že back-end můžete zobrazit jako v pořádku. Alternativně to můžete udělat prostřednictvím PowerShellu nebo rozhraní příkazového řádku.
Zkontrolujte, jestli vaše trasa definovaná uživatelem má výchozí trasu (0.0.0.0/0) s dalším segmentem směrování, který není nastavený jako internet:

a. Podle kroků 1a a 1b určete vaši podsíť. b. Zkontrolujte, jestli je nakonfigurovaná trasy definovaná uživatelem. Pokud je k dispozici, 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í, který není nastavený jako internet. Pokud je toto nastavení buď virtuální zařízení , nebo brána virtuální sítě, musíte se ujistit, že vaše virtuální zařízení nebo místní zařízení může správně směrovat paket zpět do cíle internetu beze změny paketu. Pokud se sondy směrují přes virtuální zařízení a upraví se, back-endový prostředek zobrazí stavový kód 200 a stav služby Application Gateway se může zobrazit jako Neznámý. To neznamená chybu. Provoz by se měl stále směrovat přes službu Application Gateway bez problému. d. V opačném případě změňte další segment směrování na internet, vyberte Uložit a ověřte stav back-endu.
Výchozí trasa inzerovaná připojením ExpressRoute/VPN k virtuální síti přes protokol BGP (Border Gateway Protocol):

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 zajistit, aby byl paket směrován zpět do cíle internetu, aniž byste ho museli upravovat. Ověření můžete provést pomocí možnosti Řešení potíží s Připojení na portálu služby Application Gateway. b. Vyberte cíl ručně jako libovolnou IP adresu směrovatelnou pro internet, 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 se inzerovat výchozí trasa přes ExpressRoute nebo VPN.
Pokud je ve virtuální síti nakonfigurovaný vlastní server DNS, ověřte, že servery můžou překládat veřejné domény. Překlad názvů veřejných domén může být vyžadován ve scénářích, kdy se služba Application Gateway musí spojit s externími doménami, jako jsou servery OCSP (Online Certificate Status Protocol), nebo zkontrolovat stav odvolání certifikátu.
Pokud chcete ověřit, že je služba Application Gateway v pořádku a spuštěná, přejděte na portálu na možnost Resource Health a ověřte, že je stav V pořádku. Pokud se zobrazí stav Není v pořádku nebo snížený výkon, obraťte se na podporu.
Pokud internet a privátní provoz procházejí bránou Azure Firewall hostovaným v zabezpečeném virtuálním centru (pomocí centra Azure Virtual WAN):

a. Pokud chcete zajistit, aby služba Application Gateway mohl odesílat provoz přímo do internetu, nakonfigurujte následující trasu definovanou uživatelem:

Předpona adresy: 0.0.0.0/0
Další segment směrování: Internet

b. Pokud chcete zajistit, aby služba Application Gateway mohl odesílat provoz do back-endového fondu přes bránu Azure Firewall v centru Virtual WAN, nakonfigurujte následující trasu definovanou uživatelem:

Předpona adresy: Podsíť back-endových fondů
Další segment směrování: Privátní IP adresa služby Azure Firewall

Další kroky

Přečtěte si další informace o diagnostice a protokolování služby Application Gateway.

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

Přehled

Postup kontroly stavu back-endu

Stav back-endu: Není v pořádku

Chybové zprávy

Časový limit back-endového serveru

Chyba překladu DNS

Chyba připojení TCP

Neshoda stavových kódů HTTP

Neshoda textu odpovědi HTTP

Běžný název se neshoduje

Platnost certifikátu back-endu vypršela

Zprostředkující certifikát se nenašel

Certifikát typu list nebo server nebyl nalezen.

Certifikát serveru nevystavuje veřejně známá certifikační autorita.

Zprostředkující certifikát není podepsaný veřejně známou certifikační autoritou.

Neshoda důvěryhodných kořenových certifikátů (na back-endovém serveru není kořenový certifikát)

Neshoda důvěryhodných kořenových certifikátů (kořenový certifikát je k dispozici na back-endovém serveru)

List musí být nejvyšší v řetězci.

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

Stav back-endu: Neznámý

Aktualizace položek DNS back-endového fondu

Další důvody

Další kroky

Další materiály