Nejčastější dotazy k Application Gateway

Azure Application Gateway poskytuje kontroler doručování aplikací (ADC) jako službu. Nabízí pro vaše aplikace různé možnosti vyrovnávání zatížení vrstvy 7. Tato služba je vysoce dostupná, škálovatelná a plně spravovaná v Azure.

Application Gateway podporuje automatické škálování, snižování zátěže protokolu TLS a koncové šifrování TLS, firewall webových aplikací (WAF), spřažení relací na základě souborů cookie, směrování na základě cest URL, hostování ve více lokalitech a další funkce. Úplný seznam podporovaných funkcí najdete v tématu Úvod do Application Gateway.

Application Gateway je nástroj pro vyrovnávání zatížení vrstvy 7, což znamená, že funguje pouze s webovým provozem (HTTP, HTTPS, WebSocket a HTTP/2). Podporuje funkce, jako je ukončení protokolu TLS, spřažení relací na základě souborů cookie a kruhové dotazování pro přenosy s vyrovnáváním zatížení. Load Balancer vyrovnávání zatížení provozu ve vrstvě 4 (TCP nebo UDP).

Application Gateway podporuje protokoly HTTP, HTTPS, HTTP/2 a WebSocket.

Viz podpora HTTP/2.

Viz podporované back-endové prostředky.

Application Gateway v1 (Standard a WAF) je k dispozici ve všech oblastech globálního Azure. Je také k dispozici v Azure China 21Vianet a Azure Government.

Informace Application Gateway v2 (Standard_v2 a WAF_v2) najdete v tématu podporované oblasti pro Application Gateway v2.

Application Gateway je vyhrazené nasazení ve vaší virtuální síti.

Přesměrování se podporuje. Viz Application Gateway přesměrování.

Podívejte se na pořadí zpracování naslouchacího procesu.

Pokud jako koncový bod používáte veřejnou IP adresu, najdete IP adresu a informace DNS o prostředku veřejné IP adresy. Případně ho najdete na portálu na stránce přehledu pro aplikační bránu. Pokud používáte interní IP adresy, vyhledejte informace na stránce přehledu.

Pro SKU v2 otevřete prostředek veřejné IP adresy a vyberte Konfigurace. Pole Popisek názvu DNS (volitelné) je k dispozici pro konfiguraci názvu DNS.

Časový limit keep-alive určuje, jak dlouho bude Application Gateway čekat, než klient odešle další požadavek HTTP na trvalé připojení, než ho znovu používá nebo zavře. Časový limit nečinnosti protokolu TCP určuje, jak dlouho je připojení TCP otevřené v případě, že žádná aktivita neexistuje.

Časový limit pro keep-alive ve SKU Application Gateway v1 je 120 sekund a ve SKU v2 je 75 sekund. Časový limit nečinnosti protokolu TCP je ve 4minutovém výchozím nastavení pro front-endovou virtuální IP adresu (VIP) skladové hodnoty v1 i v2 Application Gateway. Můžete nakonfigurovat hodnotu časového limitu nečinnosti protokolu TCP u bran Application Gateway v1 a v2 tak, aby byla mezi 4 minutami a 30 minutami. Pro služby Application Gateway v1 i v2 budete muset přejít na veřejnou IP adresu služby Application Gateway a změnit časový limit nečinnosti protokolu TCP v okně Konfigurace veřejné IP adresy na portálu. Změna hodnoty privátní IP adresy se nepodporuje. Hodnotu časového limitu nečinnosti protokolu TCP veřejné IP adresy můžete nastavit prostřednictvím PowerShellu spuštěním následujících příkazů:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

No. Neexistuje žádný způsob, jak přejmenovat Application Gateway prostředků. Musíte vytvořit nový prostředek s jiným názvem.

No. Neexistuje žádný způsob, jak obnovit prostředek Application Gateway jeho veřejnou IP adresu po odstranění. Musíte vytvořit nový prostředek.

V Application Gateway V1 se virtuální IP adresa může změnit, pokud zastavíte a spustíte aplikační bránu. Ale název DNS přidružený ke službě Application Gateway se po celou dobu životnosti brány nezmění. Vzhledem k tomu, že se název DNS nemění, měli byste použít alias CNAME a odkazovat na adresu DNS aplikační brány. V Application Gateway V2 můžete IP adresu nastavit jako statickou, takže se ip adresa a název DNS po celou dobu životnosti aplikační brány nezmění.

Ano, SKU Application Gateway v2 podporuje statické veřejné IP adresy a statické interní IP adresy. SKU v1 podporuje statické interní IP adresy.

Aplikační brána podporuje pouze jednu veřejnou IP adresu.

Viz Application Gateway velikost podsítě.

Ano. Kromě více instancí daného nasazení Application Gateway můžete zřídit další jedinečný prostředek Application Gateway pro existující podsíť, která obsahuje jiný prostředek Application Gateway prostředků.

Jedna podsíť nepodporuje skladové Application Gateway v2 ani v1.

Ano, ale jenom konkrétní scénáře. Další informace najdete v tématu Application Gateway infrastruktury.

Ano. Viz Úpravy požadavku.

Zřízení Application Gateway nových SKU v1 může trvat až 20 minut. Změny velikosti nebo počtu instancí nejsou rušivé a brána zůstane během této doby aktivní.

Zřízení většiny nasazení, která využívají SKU v2, bude trvat přibližně 6 minut. V závislosti na typu nasazení ale může trvat déle. Například nasazení ve více instancích Zóny dostupnosti s mnoha instancemi může trvat déle než 6 minut.

Aktualizace iniciované Application Gateway se používají po jedné aktualizační doméně mimo pracovní dobu pro oblast, ve které je brána nasazená. Z aktualizovaných instancí se řádně vyprázdní aktivní připojení. Zatímco aktualizace probíhá, Application Gateway se dočasně spustí při snížené kapacitě, která je určená množstvím nakonfigurovaných instancí. Proces aktualizace bude pokračovat k další sadě instancí pouze v případě, že byla aktuální sada instancí úspěšně upgradována.

No. Application Gateway nepodporuje e-mailové protokoly, jako jsou SMTP, IMAP a POP3.

Ano. Podrobnosti najdete v tématu Migrace Azure Application Gateway a Web Application Firewall z v1 na v2.

Ano. SKU Application Gateway v1 se bude dál podporovat. Důrazně ale doporučujeme přejít na v2, abyste využili výhod aktualizací funkcí v této SKU. Další informace najdete v tématu Automatické škálování a redundantní Application Gateway v2 pro zóny.

No. Application Gateway v2 nepodporuje proxy požadavky s ověřováním NTLM.

ano, Chromium aktualizace v80 v prohlížeči představila v souborech cookie protokolu HTTP pověření bez SameSite atributů, které by se mělo považovat za SameSite = Lax. To znamená, že prohlížeč nebude odesílat soubory cookie spřažení Application Gateway v kontextu třetí strany.

Pro podporu tohoto scénáře Application Gateway vloží další soubor cookie s názvem ApplicationGatewayAffinityCORS spolu s existujícím souborem cookie ApplicationGatewayAffinity . Tyto soubory cookie jsou podobné, ale soubor cookie ApplicationGatewayAffinityCORS má přidané dva další atributy: SameSite = None; Zabezpečení. Tyto atributy udržují rychlé relace i pro žádosti o více zdrojů. Další informace najdete v části spřažení na základě souborů cookie .

Aktivní naslouchací proces je naslouchací proces, který je přidružený k pravidlu a odesílá provoz do back-endu fondu. Jakýkoli naslouchací proces, který pouze přesměruje provoz, není aktivní naslouchací proces. Naslouchací procesy přidružené k pravidlům přesměrování nejsou považovány za aktivní. Pokud jsou pravidla přesměrování pravidla na základě cesty, pak všechny cesty v tomto pravidle přesměrování musí přesměrovat provoz, jinak se naslouchací proces považuje za aktivní. Podrobnosti o limitu jednotlivých komponent najdete v tématu limity, kvóty a omezení předplatného a služeb Azure .

SKU Application Gateway v1 podporuje scénáře s vysokou dostupností, pokud jste nasadili dvě nebo víc instancí. Azure distribuuje tyto instance napříč doménami aktualizace a selhání, aby se zajistilo, že se instance ve stejnou dobu nedaří. SKU v1 podporuje škálovatelnost přidáním více instancí stejné brány pro sdílení zatížení.

SKU v2 automaticky zajišťuje, že se nové instance rozprostře mezi doménami selhání a aktualizačními doménami. Pokud zvolíte redundanci zóny, nejnovější instance se také rozšíří napříč zónami dostupnosti, aby nabízely odolnost v oblasti selhání.

použijte Traffic Manager k distribuci provozu mezi několik aplikačních bran v různých datových centrech.

Ano, skladová položka Application Gateway v2 podporuje automatické škálování. Další informace najdete v tématu Automatické škálování a redundantní Application Gateway v zóně.

No. Instance se distribuují napříč doménami upgradu a doménami selhání.

Ano. Můžete nastavit vyprazdňování připojení pro změnu členů ve fondu back-end bez přerušení. Další informace najdete v části vyprazdňování připojení Application Gateway.

Ano.

Ano. Application Gateway je vždy nasazena v podsíti virtuální sítě. Tato podsíť může obsahovat jenom aplikační brány. Další informace najdete v tématu požadavky na virtuální síť a podsíť.

Pokud máte připojení IP, Application Gateway můžou komunikovat s instancemi mimo virtuální síť, ve které je. Application Gateway může také komunikovat s instancemi mimo předplatné, ve kterém je. Pokud máte v úmyslu používat jako členy fondu back-end interní IP adresy, použijte partnerský vztah virtuální sítě nebo Azure VPN Gateway.

No. V podsíti ale můžete nasadit i jiné aplikační brány.

Můžete přesunout Application Gateway mezi podsítěmi v rámci stejné virtuální sítě. Podporuje se s V1 s veřejným a soukromým front-end a v2 pouze s veřejným front-endu. Je také důležité si uvědomit, že Application Gateway by měl být v zastaveném stavu, aby bylo možné provést tuto akci. Mějte na paměti, že při zastavení/spuštění v1 dojde ke změně veřejné IP adresy. tuto operaci lze provést pouze pomocí Azure PowerShell a rozhraní příkazového řádku Azure CLI spuštěním následujících příkazů:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Další informace najdete v tématu set-AzApplicationGatewayIPConfiguration.

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Viz téma skupiny zabezpečení sítě v podsíti Application Gateway.

Viz trasy definované uživatelem podporované v Application Gateway podsíti.

No. Zásady koncového bodu služby pro účty úložiště nejsou podporované v Application Gateway podsíti a nakonfigurují se tak, že budou blokovat přenosy infrastruktury Azure.

Viz omezení Application Gateway.

Ano. Application Gateway podporuje jednu interní IP adresu a jednu externí IP adresu pro bránu aplikace.

Ano. Partnerské vztahy virtuálních sítí pomáhají vyrovnávat zatížení v jiných virtuálních sítích.

Ano, pokud je povolený provoz.

Architektura mikroslužeb je podporovaná. Chcete-li provést test na různých portech, je nutné nakonfigurovat více nastavení protokolu HTTP.

No.

Viz pořadí pravidel zpracování.

Pole hostitel Určuje název, do kterého se má odeslat sonda při konfiguraci nasazení ve více lokalitách na Application Gateway. Jinak použijte 127.0.0.1. Tato hodnota se liší od názvu hostitele virtuálního počítače. Formát je <protocol> :// <host> : <port> <path> .

Ano. Viz omezení přístupu na konkrétní zdrojové IP adresy.

No.

Application Gateway V2 v současné době nepodporuje protokol IPv6. Může pracovat ve virtuální síti s duálním zásobníkem jenom pomocí protokolu IPv4, ale podsíť brány musí být jenom IPv4. Application Gateway v1 nepodporuje duální virtuální sítě zásobníku.

Application Gateway V2 v současné době nepodporuje pouze režim privátních IP adres. Podporuje následující kombinace

• Privátní IP adresa a veřejná IP adresa
• Jenom veřejná IP adresa

Pokud ale chcete použít Application Gateway v2 jenom s privátní IP adresou, můžete postupovat podle následujícího postupu:

1. Vytvoření Application Gateway s IP adresou veřejného i privátního front-endu

2. Nevytvářejte žádné naslouchací procesy pro veřejnou IP adresu front-endu. Application Gateway nebude naslouchat jakémukoli provozu na veřejné IP adrese, pokud pro něj nebudou vytvořeny žádné naslouchací procesy.

3. Vytvořte a připojte skupinu zabezpečení sítě pro Application Gateway podsíť s následující konfigurací v pořadí podle priority:

   a. Povolte provoz ze zdroje jako značky služby GatewayManager a cíle jako libovolný a cílový port jako 65200-65535. Tento rozsah portů je nutný pro komunikaci s infrastrukturou Azure. Tyto porty jsou chráněné (jsou uzamčené) pomocí ověření certifikátu. Externí entity, včetně správců uživatelů brány, nemůžou iniciovat změny těchto koncových bodů bez příslušných certifikátů.

   b. Povolení provozu ze zdroje jako značky služby AzureLoadBalancer a cílového a cílového portu jako libovolného

   c. Zakažte veškerý příchozí provoz ze zdroje jako značky internetové služby a cílového a cílového portu . Dát tomuto pravidlu nejnižší prioritu pro příchozí pravidla

   d. Ponechte výchozí pravidla, jako je například povolování příchozího VirtualNetwork, aby přístup na privátní IP adrese není blokovaný.

   e. Odchozí připojení k Internetu nejde zablokovat. V opačném případě dojde k problémům s protokolováním, metrikami atd.

Ukázková konfigurace NSG jenom pro soukromý IP přístup:

Application Gateway podporuje certifikáty podepsané svým držitelem, certifikáty certifikační autority (CA), rozšířené ověřování (EV), certifikáty pro více domén (SAN) a certifikáty se zástupnými znaky.

Application Gateway podporuje následující šifrovací sady.

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Informace o tom, jak přizpůsobit možnosti TLS, najdete v tématu Konfigurace verzí zásad TLS a šifrovacích sad na Application Gateway.

Ano. Application Gateway podporuje snižování zátěže TLS a komplexní TLS, které přešifrují provoz na back-end.

Ano. Application Gateway můžete nakonfigurovat tak, aby odepřely protokol TLS 1.0, TLS 1.1 a TLS 1.2. Ve výchozím nastavení jsou SSL 2,0 a 3,0 už zakázané a nedají se konfigurovat.

Ano. V Application Gateway můžete nakonfigurovat šifrovací sady. Pokud chcete definovat vlastní zásadu, povolte aspoň jednu z následujících šifrovacích sad.

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway používá SHA256 ke správě back-endu.

Application Gateway podporuje až 100 certifikátů TLS/SSL.

Ano, Application Gateway podporuje certifikáty s rozšířeními protokolu OCSP a sešíváním protokolu OCSP pro certifikáty serveru.

Application Gateway podporuje až 100 ověřovacích certifikátů.

Ano, skladová položka Application Gateway v2 podporuje Key Vault. Další informace najdete v tématu Ukončení šifrování TLS s využitím certifikátů služby Key Vault.

U více směrování založených na doméně (hostitele) můžete vytvořit více než více lokalit, nastavit naslouchací procesy, které používají protokol HTTPS jako protokol, a přidružit naslouchací procesy k pravidlům směrování. Další informace najdete v tématu hostování více lokalit pomocí Application Gateway.

Ne, v heslech souboru. pfx použijte pouze alfanumerické znaky.

Prohlížeč certifikační autority (CA) Členové prohlížeče nedávno publikovali sestavy s podrobnostmi o více certifikátech vydaných dodavateli certifikačních autorit, kteří používají naši zákazníci, společnost Microsoft a vyšší technologická komunita, která byla nekompatibilní s oborovým standardem pro veřejně důvěryhodné certifikační autority.Sestavy týkající se certifikačních autorit, které nedodržují předpisy, najdete tady: 

• Chyba 1649951
• Chyba 1650910

Podle požadavků na dodržování předpisů v oboru můžou dodavatelé CA odvolat certifikační autority, které nedodržují předpisy, a vydávat odpovídající certifikační autority, které vyžadují, aby se jejich certifikáty znovu vystavily pro zákazníky.Společnost Microsoft úzce spolupracuje s těmito dodavateli, aby minimalizovala potenciální dopad na služby Azure, ale vaše vlastní certifikáty nebo certifikáty, které se používají ve scénářích "Přineste si vlastní certifikát" (BYOC), jsou stále ohroženy tím, že se neočekávaně odvolají.

Chcete-li zjistit, zda certifikáty využívané vaší aplikací byly odvolány z oznámení referenčního DigiCert a sledování odvolaných certifikátů. Pokud byly vaše certifikáty odvolána nebo budou odvolána, budete muset požádat o nové certifikáty od dodavatele certifikační autority, který je využívá ve vašich aplikacích. Pokud se chcete vyhnout přerušení dostupnosti vaší aplikace kvůli neočekávanému odvolání certifikátů nebo aktualizaci odvolaného certifikátu, projděte si náš příspěvek o aktualizacích Azure, kde najdete odkazy na nápravu různých služeb Azure, které podporují funkce BYOC: https://azure.microsoft.com/updates/certificateauthorityrevocation/

Konkrétní Application Gateway najdete níže–

Pokud používáte certifikát vydaný jedním z odvolaných certifikátů ICA, může dojít k přerušení dostupnosti vaší aplikace a v závislosti na vaší aplikaci se může zobrazit celá řada chybových zpráv, mimo jiné:

1. Neplatný certifikát nebo odvolaný certifikát
2. Vypršel časový limit připojení
3. HTTP 502

Pokud se chcete vyhnout přerušení aplikace z důvodu tohoto problému nebo znovu vydat odvolané certifikační autority, musíte udělat toto:

1. Informace o tom, jak certifikáty znovu vydat, vám požádejte poskytovatele certifikátů.
2. Po opětovném potvrzení aktualizujte certifikáty na Azure Application Gateway/WAF úplným řetězem důvěryhodnosti (list, zprostředkující, kořenový certifikát). V závislosti na tom, kde používáte certifikát, v naslouchacím procesu nebo v nastavení HTTP služby Application Gateway postupujte podle následujících kroků a aktualizujte certifikáty a podívejte se na odkazy na dokumentaci uvedené v části Další informace.
3. Aktualizujte své back-endové aplikační servery tak, aby se znovu vystavl certifikát. Postup aktualizace certifikátu se může lišit v závislosti na back-end serveru, který používáte. Projděte si dokumentaci od dodavatele.

Aktualizace certifikátu ve vašem naslouchacím procesu:

1. V Azure Portalotevřete prostředek Application Gateway.
2. Otevřete nastavení naslouchacího procesu přidruženého k vašemu certifikátu.
3. Klikněte na Obnovit nebo upravit vybraný certifikát.
4. Upload nový certifikát PFX heslem a klikněte na Uložit.
5. Přístup k webu a ověření, jestli web funguje podle očekávání. Další informace najdete v dokumentaci tady.

Pokud ve svém naslouchacím procesu služby Application Gateway odkazujete na certifikáty ze služby Azure KeyVault, doporučujeme pro rychlou změnu provést následující kroky:

1. V Azure Portalpřejděte do nastavení služby Azure KeyVault, která jsou přidružená k Application Gateway
2. Přidejte nebo importujte znovu vyděěný certifikát ve vašem obchodě. Další informace o návodech najdete tady v dokumentaci.
3. Po importu certifikátu přejděte do nastavení naslouchacího procesu Application Gateway a v části Zvolte certifikát z Key Vault klikněte na rozevírací seznam Certifikát a zvolte nedávno přidaný certifikát.
4. Klikněte na Uložit. Další informace o ukončení protokolu TLS v Application Gateway s Key Vault certifikáty najdete v dokumentaci tady.

Aktualizace certifikátu v souboru HTTP Nastavení:

Pokud používáte SKU V1 služby Application Gateway/WAF, budete muset nový certifikát nahrát jako ověřovací certifikát back-endu.

1. V Azure Portalotevřete prostředek Application Gateway.
2. Otevřete nastavení HTTP přidružené k vašemu certifikátu.
3. Klikněte na Přidat certifikát, nahrajte znovu vyděěný certifikát a klikněte na Uložit.
4. Starý certifikát můžete později odebrat kliknutím na ... vedle starého certifikátu, vyberte odstranit a klikněte na Uložit. Další informace najdete v dokumentaci tady.

Pokud používáte SKU V2 služby Application Gateway/WAF, nemusíte nahrávat nový certifikát v nastavení HTTP, protože SKU V2 používá "důvěryhodné kořenové certifikáty" a není potřeba tady nic provést.

Kubernetes umožňuje vytvoření prostředku a internímu vystavení skupiny deployment service podů v clusteru. Aby bylo možné stejnou službu zveřejnit externě, definuje se prostředek, který poskytuje vyrovnávání zatížení, ukončení protokolu TLS a Ingress virtuální hostování na základě názvů. K uspokojení tohoto prostředku se vyžaduje kontroler příchozího přenosu dat, který naslouchá změnám prostředků a konfiguruje Ingress zásady nástroje pro vyrovnávání Ingress zatížení.

Kontroler Application Gateway příchozího přenosu dat (AGIC) umožňuje Azure Application Gateway použít jako příchozí přenos dat pro Azure Kubernetes Service označovaný také jako cluster AKS.

V současné době může být jedna instance kontroleru příchozího přenosu dat přidružena pouze k Application Gateway.

AGIC se pokouší automaticky přidružit prostředek směrovací tabulky k podsíti Application Gateway, ale může to selhat kvůli chybějícím oprávněním z AGIC. Pokud AGIC nemůže přidružit směrovací tabulku k podsíti Application Gateway, v protokolech AGIC se zobrazí chyba s tímto dotazem. V takovém případě budete muset směrovací tabulku vytvořenou clusterem AKS ručně přidružit k podsíti Application Gateway. Další informace najdete v tématu Podporované trasy definované uživatelem.

Ano, pokud jsou virtuální sítě v partnerském vztahu a nemají překrývající se adresní prostory. Pokud používáte AKS s kubenetem, nezapomeňte přidružit směrovací tabulku vygenerovaou službou AKS k podsíti Application Gateway podsítě.

Rozdíly mezi AGIC nasazenou prostřednictvím Helmu a nasazenou jako doplněk AKS najdete tady.

Projděte si rozdíly mezi AGIC nasazenou prostřednictvím Helmu a nasazenou jako doplněk AKS, zejména tabulky dokumentující, které scénáře podporuje AGIC nasazené prostřednictvím Helmu, a nikoli doplněk AKS. Obecně platí, že nasazení prostřednictvím Helmu vám umožní otestovat funkce beta verze a kandidáty na vydání před oficiálním vydáním.

Ne, doplněk AGIC je spravovaná služba, což znamená, že Microsoft tento doplněk automaticky aktualizuje na nejnovější stabilní verzi.

Vzájemné ověřování je oboustranné ověřování mezi klientem a serverem. Vzájemné ověřování s Application Gateway aktuálně umožňuje bráně ověřit, jestli klient odesílá požadavek, což je ověření klienta. Klient je obvykle jediný, kdo ověřuje Application Gateway. Protože Application Gateway klient může také ověřit, stane se z něj vzájemné ověřování, kdy Application Gateway a klient se vzájemně ověřují.

Ne, vzájemné ověřování je v současné době pouze mezi front-end klientem a Application Gateway. Vzájemné ověřování back-endu se v současné době nepodporuje.

Application Gateway poskytuje tři protokoly:

• ApplicationGatewayAccessLog: Protokol přístupu obsahuje každý požadavek odeslaný do front-endu aplikační brány. Data zahrnují IP adresu volajícího, požadovanou adresu URL, latenci odpovědi, návratový kód a příchozí a odeslané bajty. Obsahuje jeden záznam pro každou aplikační bránu.
• ApplicationGatewayPerformanceLog: Protokol výkonu zaznamenává informace o výkonu pro každou aplikační bránu. Mezi tyto informace patří propustnost v bajtech, celkový počet obsluhovovaných požadavků, počet neúspěšných požadavků a počet instancí back-endu, které jsou v pořádku a není v pořádku.
• ApplicationGatewayFirewallLog: Pro aplikační brány, které konfigurujete pomocí WAF, obsahuje protokol brány firewall požadavky, které se protokoluly v režimu detekce nebo prevence.

Všechny protokoly se shromažďují každých 60 sekund. Další informace najdete v tématu Stav back-endu,diagnostické protokoly a metriky pro Application Gateway .

Pomocí rutiny PowerShellu nebo portálu ověřte Get-AzApplicationGatewayBackendHealth stav. Další informace najdete v tématu Application Gateway diagnostice.

Diagnostické protokoly proudí do účtu úložiště zákazníka. Zákazníci mohou nastavit zásady uchovávání informací podle svých preferencí. Diagnostické protokoly je také možné odeslat do centra událostí nebo Azure Monitor protokoly. Další informace najdete v tématu Application Gateway diagnostice.

Na portálu v okně nabídky aplikační brány vyberte Protokol aktivit, abyste získali přístup k protokolu auditu.

Ano. V Application Gateway jsou pro metriky nakonfigurovaná upozornění. Další informace najdete v tématu Application Gateway metriky a Příjem oznámení o upozorněních.

Protokoly přístupu můžete zobrazit a analyzovat několika způsoby. Používejte Azure Monitor protokoly, Excel, Power BI a tak dále.

Můžete také použít šablonu protokolu Resource Manager, která nainstaluje a spustí oblíbený analyzátor protokolů GoAccess pro Application Gateway protokolů přístupu. GoAccess poskytuje cenné statistiky provozu HTTP, jako jsou jedineční návštěvníci, požadované soubory, hostitelé, operační systémy, prohlížeče a stavové kódy HTTP. Další informace najdete v GitHub souboru Readme ve složce Resource Manager šablony.

Obvykle se zobrazí neznámý stav, když je přístup k back-endu blokovaný skupinou zabezpečení sítě (NSG), vlastním DNS nebo uživatelem definovaným směrováním (UDR) v podsíti aplikační brány. Další informace najdete v tématu Stav back-endu, protokolování diagnostikya metriky pro Application Gateway .

Pokud máte v podsíti Application Gateway v2 (Standard_v2, WAF_v2) NSG a pokud jste povolili protokoly toku NSG, z důvodu aktuálních omezení platformy se zobrazí nedeterministické chování a tento scénář se v současné době nepodporuje.

Application Gateway nepřesouvá ani neukládá zákaznická data mimo oblast, ve které je nasazená.

Další kroky

Další informace o Application Gateway najdete v tématu Co je Azure Application Gateway?.