Nejčastější dotazy ke službě Application Gateway

Poznámka:

K interakci s Azure doporučujeme použít modul Azure Az PowerShell. Pokud chcete začít, přečtěte si téma Install Azure PowerShell. Informace o migraci do modulu Az PowerShell najdete v tématu Migrace Azure PowerShell z AzureRM do Az.

K Azure Application Gateway jsou kladeny následující běžné otázky.

Obecné

Co je Application Gateway?

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

Jaké funkce služba Application Gateway podporuje?

Application Gateway podporuje automatické škálování, odlehčení TLS a kompletní TLS, firewall webových aplikací (WAF), spřažení relací založené na cookies, směrování na základě cesty URL, hostování více webů a další funkce. Úplný seznam podporovaných funkcí najdete v tématu Úvod do služby Application Gateway.

Jak se služba Application Gateway a Azure Load Balancer liší?

Application Gateway je nástroj pro vyrovnávání zatížení vrstvy 7, což znamená, že funguje jenom 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 vyrovnávání zatížení. Zařízení Load Balancer vyrovnává zatížení provozu na vrstvě 4 (TCP nebo UDP).

Jaké protokoly služba Application Gateway podporuje?

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

Jak Služba Application Gateway podporuje protokol HTTP/2?

HTTP/2 je podporován pouze pro klienty, kteří se připojují k naslouchačům služby Application Gateway. Komunikace se skupinami backend serverů je vždy přes HTTP/1.1. Podpora HTTP/2 je ve výchozím nastavení zakázána, kromě případů, kdy vytvoříte Application Gateway v Azure portálu, kde je HTTP/2 ve výchozím nastavení povoleno. Nastavení můžete změnit během nasazení nebo po něm.

Pro konfigurační kroky viz podpora HTTP/2.

Jaké prostředky se podporují jako součást back-endového fondu?

Viz Podporované back-endové prostředky.

V jakých oblastech je služba Application Gateway dostupná?

Služba Application Gateway v1 (Standard a WAF) je vyřazená a od 28. dubna 2026 se nepodporuje. Dostupnost služby Application Gateway v2 (Standard_v2 a WAF_v2) najdete v tématu Podporované oblasti služby Application Gateway v2.

Je toto nasazení vyhrazené pro moje předplatné nebo se sdílí mezi zákazníky?

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

Podporuje Služba Application Gateway přesměrování HTTP-to-HTTPS?

Přesměrování se podporuje. Viz přehled přesměrování služby Application Gateway.

V jakém pořadí se posluchači zpracovávají?

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

Kde najdu IP adresu a DNS služby Application Gateway?

Pokud jako koncový bod používáte veřejnou IP adresu, informace o IP adrese a DNS jsou k dispozici na prostředku veřejné IP adresy. Nebo ho najdete na portálu Azure na stránce přehledu pro aplikační bránu. Pokud používáte interní IP adresy, vyhledejte informace na stránce přehledu. U typu produktu v1 nebudou mít brány vytvořené po 1. květnu 2023 DNS jméno ve výchozím nastavení automaticky přidružené k veřejné IP adrese. V případě skladové položky v2 otevřete prostředek veřejné IP adresy a vyberte Konfigurace. Pole Popisek názvu DNS (volitelné) je k dispozici ke konfiguraci názvu DNS.

Jaká jsou nastavení časového limitu Keep-Alive a časového limitu nečinnosti TCP?

Keep-Alive Časový limit určuje, jak dlouho aplikační brána čeká na odeslání dalšího požadavku HTTP na trvalé připojení před opětovným použitím nebo zavřením. Časový limit nečinnosti protokolu TCP určuje, jak dlouho je připojení TCP otevřené, pokud neexistuje žádná aktivita.

Pro připojení HTTP/1.1 je časový limit v Application Gateway verze 1 a SKU verze 2 120 sekund. U privátních IP adres je hodnota nekonfigurovatelná s časovým limitem nečinnosti PROTOKOLU TCP 5 minut. Časový limit nečinnosti protokolu TCP je ve výchozím nastavení 4 minuty na virtuální IP adrese (VIP) frontendu jak pro v1, tak pro v2 Application Gateway. Hodnotu časového limitu nečinnosti PROTOKOLU TCP můžete nakonfigurovat na instancích služby Application Gateway verze 1 a v2 tak, aby byly kdekoli mezi 4 minutami a 30 minutami. U instancí služby Application Gateway verze 1 i v2 musíte přejít na veřejnou IP adresu služby Application Gateway a změnit časový limit nečinnosti protokolu TCP v podokně Konfigurace veřejné IP adresy na portálu. Hodnotu časového limitu nečinnosti pro TCP veřejné IP adresy můžete nastavit pomocí PowerShell spuštěním následujících příkazů:

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

V případě připojení HTTP/2 k front-endové IP adrese v rámci konfigurace Application Gateway v2 SKU je časový limit nečinnosti nastaven na 180 sekund a nelze jej změnit.

Chcete-li zabránit konfliktům a neočekávanému chování, ujistěte se, že časový limit nečinnosti protokolu TCP je nastavený tak, aby byl stejný nebo delší než časový limit zachování.

Používá služba Application Gateway znovu připojení TCP, které je navázáno s back-endovým serverem?

Ano. Application Gateway znovu použije stávající připojení TCP s back-endovým serverem.

Můžu prostředek služby Application Gateway přejmenovat?

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

Existuje způsob, jak obnovit prostředek služby Application Gateway a jeho veřejnou IP adresu, pokud byl odstraněn?

Ne. Po odstranění není žádný způsob, jak obnovit prostředek služby Application Gateway nebo jeho veřejnou IP adresu. Musíte vytvořit nový prostředek.

Mění se ip adresa nebo název DNS po celou dobu životnosti aplikační brány?

V SKU Application Gateway v1 se VIP může změnit, pokud zastavíte a znovu spustíte službu Application Gateway. Název DNS přidružený ke službě Application Gateway se ale po celou dobu životnosti brány nezmění. Protože se název DNS nezmění, měli byste použít alias CNAME a nasměrovat ho na adresu DNS aplikační brány. V SKU služby Application Gateway v2 jsou IP adresy statické, takže se IP adresa a název DNS po celou dobu životnosti aplikační brány nezmění.

Podporuje Application Gateway statickou IP adresu?

Ano. Skladová položka služby Application Gateway v2 podporuje statické veřejné IP adresy a statické interní IP adresy. Skladová položka v1 podporuje statické interní IP adresy.

Podporuje Služba Application Gateway více veřejných IP adres v bráně?

Aplikační brána podporuje pouze jednu veřejnou IP adresu na protokol IP. Pokud je aplikační brána nakonfigurovaná jako DualStack, může podporovat dvě veřejné IP adresy, jednu pro IPv4 a druhou pro IPv6.

Jak velká by měla být podsíť pro službu Application Gateway?

Viz důležité informace o velikosti podsítě služby Application Gateway.

Můžu do jedné podsítě nasadit více než jeden prostředek služby Application Gateway?

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

Jedna podsíť nemůže podporovat skladové položky služby Application Gateway v2 i v1.

Podporuje Application Gateway v2 trasy definované uživatelem?

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

Podporuje Application Gateway hlavičky x-forwarded-for?

Ano. Viz Úpravy žádosti.

Jak dlouho trvá nasazení instance služby Application Gateway? Bude moje služba Application Gateway fungovat, když se aktualizuje?

Nasazení většiny služeb, které využívají v2 SKU, trvá přibližně 6 minut. Proces ale může trvat déle v závislosti na typu nasazení. Například nasazení napříč několika zónami dostupnosti s mnoha instancemi může trvat déle než 6 minut.

Můžu Exchange Server použít jako back-end se službou Application Gateway?

Application Gateway podporuje proxy protokolu TLS/TCP prostřednictvím proxy serveru vrstvy 4 ve verzi Preview.

Proxy server vrstvy 7 služby Application Gateway s protokoly HTTP(S) nebude podporovat e-mailové protokoly, jako jsou SMTP, IMAP a POP3. U některých podpůrných e-mailových služeb, jako je Outlook Web Access (OWA), ActiveSync a provoz AutoDiscovery, který používá protokoly HTTP(S), ale můžete použít proxy server vrstvy 7 a jejich provoz by měl protékat. (Poznámka: Vyloučení v pravidlech WAF můžou být vyžadována při použití skladové položky WAF).

Jsou k dispozici pokyny k migraci ze skladové položky v1 na skladovou položku v2?

Ano. Další informace viz Migrace Azure Application Gateway a Web Application Firewall z verze v1 na verzi v2.

Je podporováno SKU v1 pro Application Gateway?

Ne. Application Gateway v1 SKU byl vyřazen 28. dubna 2026 a již není podporován. Přesuňte se na v2 co nejdříve, protože začalo vyřazování zbývajících v1 bran. Pro migrační kroky viz Migrate Azure Application Gateway and Web Application Firewall from v1 to v2.

Jakékoli chování v1 popsané jinde v tomto článku platí pouze pro stávající v1 brány, které ještě nebyly migrovány. Nepoužívej ho k plánování nových nasazení.

Podporuje služba Application Gateway v2 proxy požadavek s autentizací pomocí NTLM nebo Kerberos?

Ano. Application Gateway v2 teď podporuje proxy požadavky s ověřováním NTLM nebo Kerberos. Další informace najdete v tématu Vyhrazené back-endové připojení.

Proč se při předávání požadavků do aplikace nezobrazují některé hodnoty hlaviček?

Názvy hlaviček požadavků můžou obsahovat alfanumerické znaky a pomlčky. Názvy hlaviček požadavků, které obsahují jiné znaky, se zahodí při odeslání požadavku do back-endového cíle. Názvy hlaviček odpovědí můžou obsahovat libovolné alfanumerické znaky a konkrétní symboly definované v dokumentu RFC 7230.

Podporuje soubor cookie spřažení služby Application Gateway atribut SameSite?

Ano. Aktualizace prohlížečeChromium v80 zavedla mandát pro soubory cookie HTTP bez atributu SameSite, který se má považovat za SameSite=Lax. To znamená, že afinitní cookie služby Application Gateway nebude prohlížečem odeslán v kontextu třetí strany.

Pro podporu tohoto scénáře služba Application Gateway vloží kromě existujícího ApplicationGatewayAffinityCORS souboru cookie další soubor cookieApplicationGatewayAffinity. Tyto soubory cookie jsou podobné, ale ApplicationGatewayAffinityCORS soubor cookie má dva další atributy: SameSite=None a Secure. Tyto atributy udržují trvalé relace i pro požadavky mezi doménami. Další informace najdete v části o spřažení na základě souborů cookie.

Co je aktivní naslouchací proces a neaktivní naslouchací proces?

Aktivní naslouchací proces je naslouchací proces, který je přidružený k pravidlu a odesílá provoz do back-endového fondu. Jakýkoliv posluchač, který pouze přesměruje provoz, není aktivní posluchač. Posluchače spojené s pravidly přesměrování se nepovažují za aktivní. Pokud je pravidlo přesměrování pravidlem založeným na cestě, všechny cesty v tomto pravidle přesměrování musí přesměrovat provoz, nebo je naslouchací proces považován za aktivní. Podrobnosti o limitu jednotlivých komponent najdete v tématu Azure limity, kvóty a omezení předplatného a služeb.

Proč služba Application Gateway zobrazuje "SKU family Generation_1", i když používám skladovou položku v2 (WAF_v2 nebo Standard_v2)?

To je očekávané chování a neznamená to, že vaše brána používá v1. Řada skladových položek a název skladové položky jsou dvě samostatné vlastnosti:

Vlastnost Co to znamená Example
Název skladové položky Vybraná úroveň produktu. Určuje funkce, výkon a chování. Standard_v2, WAF_v2
Skupina SKU Interní označení platformy Azure pro generaci podkladového hardwaru. Pouze informační. Generation_1
  • Pokud je Standard_v2 název vaší skladové položky nebo WAF_v2, používáte Application Gateway v2 se všemi možnostmi v2 – bez ohledu na to, jakou řadu skladových položek zobrazuje.
  • Rodina SKU je automaticky přiřazena službou Azure. Nemůžete to změnit v portálu, ARM, Bicepu ani CLI a ani to nemusíte měnit. Nemá žádný vliv na funkčnost, výkon, funkce ani fakturaci.

Výkon

Jak služba Application Gateway podporuje vysokou dostupnost a škálovatelnost?

Skladová položka v2 automaticky zajišťuje, že se nové instance rozdělí mezi domény poruch a domény aktualizace. Pokud zvolíte redundanci zón, nejnovější instance se také rozdělí mezi zóny dostupnosti a nabízejí odolnost proti zónovým selháním.

Jak dosáhnu plánu zotavení po katastrofě napříč datovými centry pomocí služby Application Gateway?

Pomocí Azure Traffic Manager distribuujte provoz mezi několik aplikačních bran v různých datacentrech.

Podporuje Služba Application Gateway vyprazdňování připojení?

Ano. Můžete nastavit odvodnění připojení, abyste měnili členy ve back-endové skupině bez přerušení. Další informace najdete v části Vyprazdňování připojení ve službě Application Gateway.

Podporuje Application Gateway automatické škálování?

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

Způsobuje ruční nebo automatické škálování nahoru nebo dolů výpadky systému?

Ne. Instance se distribuují napříč upgradovanými doménami a doménami selhání.

Můžu změnit ze standardní na skladovou položku WAF bez přerušení?

Ano.

Můžu změnit velikost instance ze střední na velkou bez přerušení?

Ano.

Maintenance

Jak služba Application Gateway zpracovává rutinní údržbu?

Aktualizace iniciované ve službě Application Gateway se použijí postupně po jedné aktualizační doméně. Vzhledem k tomu, že se aktualizují instance každé aktualizační domény, zbývající instance v jiných aktualizačních doménách budou dál obsluhovat provoz. Aktivní připojení se řádně vyprázdní z aktualizovaných instancí po dobu až 5 minut, aby bylo možné navázat připojení k instancím v jiné aktualizační doméně před zahájením aktualizace. Proces aktualizace pokračuje k další sadě instancí pouze v případě, že aktuální sada instancí byla úspěšně upgradována.

Azure Application Gateway také podporuje MaxSurge, funkce, která umožňuje zřizování nových instancí během postupného upgradu bez přechodu do režimu offline. Umožňuje zákazníkům přejít na novější verze brány bez jakéhokoli snížení kapacity. Služba MaxSurge je ve službě Application Gateway automaticky povolená a nevyžaduje žádnou konfiguraci.

Poznámka: K zajištění dočasných instancí používaných nástrojem MaxSurge je potřeba další IP prostor. Pokud během aktualizace není k dispozici dostatečný prostor IP adres, služba Application Gateway se vrátí k tradiční metodě upgradu, což může mít za následek snížení maximální kapacity na základě počtu instancí.

Konfigurace

Je služba Application Gateway vždy nasazená ve virtuální síti?

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

Může Služba Application Gateway komunikovat s instancemi mimo svou virtuální síť nebo mimo její předplatné?

Pokud máte připojení IP, služba Application Gateway může komunikovat s instancemi mimo virtuální síť, ve které je. Application Gateway může také komunikovat s instancemi mimo předplatné, ve které je. Pokud plánujete používat interní IP adresy jako členy back-endových poolů, použijte například peering virtuálních sítí nebo Službu Azure VPN Gateway.

Jak se aktualizuje IP adresa serveru s FQDN?

Stejně jako jakýkoli resolver DNS dodržuje prostředek služby Application Gateway hodnotu TTL (Time to Live) DNS záznamu backend serveru. Po vypršení platnosti hodnoty TTL brána provede vyhledávání, aby aktualizovala informace DNS. Pokud během tohoto vyhledávání narazí vaše aplikační brána na problém se získáním odpovědi (nebo se nenajde žádný záznam DNS), brána bude dál používat poslední známou dobrou hodnotu DNS pro obsluhu provozu. Další informace najdete v tématu Jak funguje aplikační brána.

Proč se mi po změně serverů DNS pro virtuální síť zobrazují chyby 502 nebo back-endové servery, které nejsou v pořádku?

Instance vaší aplikační brány používají konfiguraci DNS virtuální sítě pro rozlišení názvů. Po změně jakékoli konfigurace serveru DNS je potřeba restartovat (zastavit a spustit) aplikační bránu, aby se nové servery DNS přiřadily. Do té doby může selhat překlady ip adres založených na plně kvalifikovaném názvu domény pro odchozí připojení.

Podporuje Application Gateway krátké názvy nebo názvy domén s jedním popiskem?

Ano. Application Gateway umí rozpoznat krátké názvy (například server1 nebo backend) v backendových poolů, pokud je váš DNS server dokáže vyřešit. To funguje v libovolném nastavení sítě, včetně místních, Azure virtuálních sítí nebo hybridních prostředí.

Aby krátké jmenné rozlišení fungovalo:

  • Server DNS vaší virtuální sítě musí být schopný převést krátký název na IP adresu.
  • Krátké názvy fungují stejně jako plně kvalifikované názvy domén (FQDN) – brána požádá server DNS o IP adresu a použije ji.

Poznámka: Pokud používáte výchozí DNS Azure (168.63.129.16), může přeložit jenom krátké názvy prostředků ve stejné virtuální síti. Pokud chcete vyřešit krátké názvy v rámci místní sítě, nastavte vlastní DNS server, který je schopen zpracovat vaše interní názvy domén.

Další informace najdete v tématu Porozumění procesu překladu DNS v rámci služby Application Gateway.

Můžu v podsíti služby Application Gateway nasadit něco jiného?

Ne. V podsíti ale můžete nasadit další aplikační brány.

Můžu změnit virtuální síť nebo podsíť pro existující aplikační bránu?

Aplikační bránu můžete přesunout pouze mezi podsítěmi ve stejné virtuální síti. Je podporována verze v1 s veřejným a privátním frontendem (dynamické přidělování) a verze v2 pouze s veřejným frontendem. Aplikační bránu nemůžeme přesunout do jiné podsítě, pokud je staticky přidělená konfigurace privátní ip adresy front-endu. Aby se tato akce prováděla, měla by být aplikační brána ve stavu Zastaveno . Zastavení nebo spuštění verze 1 změní veřejnou IP adresu. Tuto operaci lze provést pouze pomocí Azure PowerShell a 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 naleznete 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>

Podporují se skupiny zabezpečení sítě v podsíti služby Application Gateway?

Viz skupiny zabezpečení sítě v podsíti služby Application Gateway.

Podporuje podsíť služby Application Gateway trasy definované uživatelem?

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

Jsou v podsíti služby Application Gateway podporovány zásady koncových bodů služby?

Ne. Zásady koncového bodu služby pro účty úložiště nejsou podporovány v podsíti Application Gateway a jejich konfigurace blokuje provoz infrastruktury Azure.

Jaká jsou omezení služby Application Gateway? Můžu tyto limity zvýšit?

Viz omezení služby Application Gateway.

Můžu službu Application Gateway používat současně pro externí i interní provoz?

Ano. Application Gateway podporuje jednu interní IP adresu a jednu externí IP adresu na aplikační bránu.

Podporuje Application Gateway propojení virtuálních sítí?

Ano. Propojení virtuálních sítí pomáhá rozkládat zatížení sítě v jiných virtuálních sítích.

Můžu komunikovat s místními servery, když jsou připojené pomocí tunelů Azure ExpressRoute nebo VPN?

Ano, pokud je povolený provoz.

Může jeden back-endový fond obsluhovat mnoho aplikací na různých portech?

Podporuje se architektura mikroslužeb. Pokud chcete testovat na různých portech, musíte nakonfigurovat několik nastavení back-endu.

Podporují vlastní sondy v datech odpovědi zástupné znaky nebo regulární výrazy?

Ne.

Jak se pravidla směrování zpracovávají ve službě Application Gateway?

Viz Pořadí pravidel zpracování.

Co znamená pole **Hostitel** u vlastních sond?

Pole Hostitel určuje název, na který se má sonda odeslat při konfiguraci více lokalit na službě Application Gateway. V opačném případě použijte 127.0.0.1. Tato hodnota se liší od názvu hostitele virtuálního počítače. Jeho formát je <protocol>://<host>:<port><path>.

Můžu službě Application Gateway povolit přístup jenom k několika zdrojovým IP adresám?

Ano. Viz Omezení přístupu ke konkrétním zdrojovým IP adresám.

Můžu použít stejný port pro veřejné a soukromé naslouchací porty?

Ano, pro souběžnou podporu veřejných a soukromých klientů můžete použít veřejné a soukromé naslouchací se stejným číslem portu. Pokud je skupina zabezpečení sítě (NSG) přidružená k podsíti vaší aplikační brány, může být v závislosti na konfiguraci potřeba konkrétní příchozí pravidlo. Více informací.

Podporuje Application Gateway protokol IPv6?

Application Gateway v2 podporuje front-endy IPv4 a IPv6. V současné době je podpora IPv6 dostupná jenom pro nové aplikační brány. Pro podporu protokolu IPv6 by měla být virtuální síť v duálním režimu. Application Gateway v1 nepodporuje dual-stack virtuální sítě.

Podporuje Služba Application Gateway FIPS?

Skladové položky služby Application Gateway se můžou spouštět v režimu schváleném fiPS 140-2, který se běžně označuje jako režim FIPS. Režim FIPS volá kryptografický modul ověřený standardem FIPS 140-2, který zajišťuje algoritmy kompatibilní se standardem FIPS pro šifrování, hashování a podepisování, pokud je povoleno. Pokud chcete zajistit, aby byl režim FIPS povolený, musí být nastavení FIPSMode nakonfigurované prostřednictvím portálu (pro V2), PowerShellu, Azure Resource Manager šablony nebo rozhraní REST API.

Kroky pro povolení FIPS módu v SKU verze V2: Viz Povolení FIPS módu pro Azure Application Gateway SKU verze V2.

Postup povolení režimu FIPS v SKU V1:

Krok 1: Zaregistrujte funkci AllowApplicationGatewayEnableFIPS pro registraci předplatného pro konfiguraci režimu FIPS.

Pokud se chcete zaregistrovat pomocí Azure PowerShell, otevřete Cloud Shell výzvu a zadejte následující:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Registrace pomocí portálu Azure:

  • Přihlaste se k portálu Azure a vyhledejte funkce Preview.
  • Do pole filtru zadejte AllowApplicationGatewayEnableFIPS . Vyberte Application Gateway V1 Povolit režim FIPS, a pak vyberte Zaregistrovat.

Step 2: Nastavte vlastnost enableFips na True pomocí PowerShellu, šablony Azure Resource Manager nebo rozhraní REST API.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

Změna režimu FIPS nemá vliv na celkovou dostupnost šifrovacích sad na branách V1. Pokud ale pro šifry používáte kryptografii eliptických křivek, když je režim FIPS zakázán, můžete použít curve25519, NistP256 a NistP384, zatímco při povoleném režimu FIPS jsou povoleny pouze NistP256 a NistP384 a curve25519 je zakázán. Vzhledem k tomu, že křivka25519 přestane být v režimu FIPS dostupná, ujistěte se, že vaši klienti podporují NistP256 nebo NistP384 pro zabezpečenou komunikaci před povolením FIPS.

Jak mohu používat Application Gateway v2 pouze s privátní IP adresou frontendu?

Služba Application Gateway v2 teď podporuje pouze konfiguraci front-endu privátní IP adresy. Další informace najdete v tématu Nasazení privátní služby Application Gateway.

Application Gateway v2 podporuje následující kombinace:

  • Privátní IP adresa a veřejná IP adresa
  • Pouze veřejná IP adresa
  • Pouze privátní IP adresa

Jak můžu službu Application Gateway zastavit a spustit?

K zastavení a spuštění služby Application Gateway můžete použít Azure PowerShell nebo Azure CLI. Když službu Application Gateway zastavíte a znovu spustíte, účtování se také zastaví a znovu spustí. Jakákoli operace PUT provedená na zastavené aplikační bráně (například přidání značky, sondy stavu nebo naslouchacího procesu) aktivuje spuštění. Po aktualizaci konfigurace doporučujeme službu Application Gateway zastavit.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Konfigurace: TLS

Jaké certifikáty služba Application Gateway podporuje?

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

Jaké šifrovací sady Služba Application Gateway podporuje?

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 (bezpečnostní protokol využívající šifrování AES s GCM a 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 protokolu TLS, najdete v tématu Konfigurace verzí zásad TLS a šifrovacích sad ve službě Application Gateway.

Podporuje Služba Application Gateway opětovné šifrování provozu do back-endu?

Ano. Application Gateway podporuje vyložení TLS a end-to-end TLS, což znovu zašifrovává provoz zpět na back end.

Můžu nakonfigurovat zásady PROTOKOLU TLS pro řízení verzí protokolu TLS?

Ano. Minimální verzi protokolu TLS můžete nastavit na protokol TLS 1.0, TLS 1.1, TLS 1.2 nebo TLS 1.3 (TLS 1.3 vyžaduje skladovou položku v2 a předdefinovanou zásadu 2022 nebo zásadu Customv2). Protokoly SSL 2.0 a 3.0 jsou ve výchozím nastavení zakázané a nedají se konfigurovat. Od 31. srpna 2025 se ve službě Application Gateway vyřadí protokol TLS 1.0 a TLS 1.1; použijte protokol TLS 1.2 nebo vyšší. Další informace najdete v tématu Přehled zásad TLS služby Application Gateway a Správa služby Application Gateway s vyřazeným protokolem TLS 1.0 a 1.1.

Můžu nakonfigurovat šifrovací sady a pořadí zásad?

Ano. Ve službě Application Gateway můžete nakonfigurovat šifrovací sady. Pokud chcete definovat vlastní zásadu, povolte alespoň 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 (bezpečnostní protokol využívající šifrování AES s GCM a 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á ke správě back-endu SHA256.

Kolik certifikátů TLS/SSL služba Application Gateway podporuje?

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

Podporuje služba Application Gateway OCSP a OCSP stapling?

Ano. Application Gateway podporuje certifikáty využívající OCSP (Online Certificate Status Protocol) a podporuje OCSP stapling serverových certifikátů. U certifikátů uložených v Azure Key Vault se ujistěte, že soubor PFX nebo PEM obsahuje soukromý klíč a kompletní řetězec certifikátů. Doporučuje se zahrnout root certifikát. Application Gateway musí být schopen přeložit a zpřístupnit adresu URL respondéru OCSP uvedenou v rozšíření Authority Information Access (AIA) certifikátu, aby mohl pro OCSP stapling získat informace o stavu odvolání.

Kolik ověřovacích certifikátů pro opětovné šifrování back-endu podporuje služba Application Gateway?

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

Integruje se služba Application Gateway nativně s Azure Key Vault?

Ano, skladová položka služby Application Gateway v2 podporuje Key Vault. Další informace najdete v tématu o ukončení služby TLS s certifikáty Key Vault.

Proč nemohu při konfiguraci TLS posluchače ve službě Application Gateway na portálu Azure vybrat klíčový trezor Azure z jiného předplatného?

Portál Azure aktuálně umožňuje výběr trezorů klíčů pouze ze stejného předplatného jako Služba Application Gateway. Jedná se o známé omezení portálu. Služba Application Gateway ale podporuje použití trezoru klíčů z jiného předplatného (ve stejném tenantovi Microsoft Entra ID) konfigurací certifikátu prostřednictvím Azure CLI nebo PowerShellu pomocí ID tajného klíče trezoru klíčů za předpokladu, že spravovaná identita služby Application Gateway má požadovaná oprávnění k trezoru klíčů.

Jak nakonfigurovat posluchače HTTPS pro weby .com a .NET?

U více doménových (hostitelských) směrování můžete vytvořit naslouchací procesy ve více lokalitách, nastavit naslouchací procesy, které jako protokol používají PROTOKOL HTTPS, a přidružit naslouchací procesy k pravidlům směrování. Další informace najdete v tématu Hostování více webů pomocí služby Application Gateway.

Můžu v hesle souboru .pfx použít speciální znaky?

Ne. V hesle k souboru .pfx používejte pouze alfanumerické znaky.

Certifikát EV vydává DigiCert a můj zprostředkující certifikát byl odvolán. Jak mohu obnovit svůj certifikát ve službě Application Gateway?

Požádejte o znovu vydaný certifikát od své certifikační autority a aktualizujte jej na každém místě, kde ho Application Gateway používá:

Kde je certifikát používán Action
Certifikát posluchače nahrán do Application Gateway Nahrajte znovu vydaný PFX soubor v nastavení posluchače.
Certifikát posluchače odkazující na Key Vault Importujte znovu vystavený certifikát do trezoru klíčů a potom jej vyberte v naslouchacím procesu.
Ověřovací certifikát back-endu (brány v1) Nahrajte znovu vydaný certifikát do nastavení HTTP backendu.
Důvěryhodný kořenový certifikát na backendu (v2 brány) Pokud důvěryhodný kořenový certifikát zůstává platný a nezměněn, není potřeba žádná změna Application Gateway. Pokud obnovený backendový certifikát používá novou privátní root CA, nahrajte nový důvěryhodný root certifikát do backendového nastavení.

Pro obnovu backendových certifikátů nainstalujte obnovený certifikátový řetězec na backend server.

Zbytek této odpovědi vysvětluje, proč byly certifikáty odebrány, a podrobně uvádí kroky pro každý případ.

Členové CA/Browser nedávno publikovali zprávy s podrobnostmi o několika certifikátech vydaných dodavateli CA, které používají naši zákazníci, Microsoft a širší technologická komunita, a které nebyly v souladu s oborovými standardy pro certifikační autority s veřejnou důvěrou. Zprávy týkající se nevyhovujících CA lze nalézt zde:

Podle požadavků na dodržování předpisů v oboru začali dodavatelé certifikačních autorit odvolat certifikační autority nesplňující předpisy a vydávat certifikační autority vyhovující předpisům, což vyžaduje, aby si zákazníci znovu prošli certifikáty. Microsoft úzce spolupracuje s těmito dodavateli, aby minimalizoval potenciální dopad na Azure služby. Vaše vlastní certifikáty nebo certifikáty používané ve scénářích BYOC (Bring Your Own Certificate) jsou ale stále ohroženy neočekávaně odvoláváním.

Pokud chcete zkontrolovat, jestli se odvolaly certifikáty využívané vaší aplikací, přečtěte si oznámení DigiCertu a sledování odvolání certifikátu. Pokud byly vaše certifikáty odvolány nebo budou odvolány, budete muset požádat o nové certifikáty od dodavatele certifikační autority využívané ve vašich aplikacích. Pokud se chcete vyhnout přerušení dostupnosti vaší aplikace kvůli neočekávaně odvolaným certifikátům nebo aktualizaci certifikátu, který byl odvolán, přečtěte si téma Revocation nevyhovujících certifikačních autorit, které potenciálně ovlivňují služby Azure zákazníka.

Informace týkající se služby Application Gateway:

Pokud používáte certifikát vystavený některou z odvolaných icA, může být dostupnost vaší aplikace přerušena. V závislosti na vaší aplikaci se můžou zobrazit různé chybové zprávy, mezi které patří mimo jiné:

  • Neplatný certifikát nebo odvolaný certifikát
  • Vypršel časový limit připojení
  • HTTP 502

Abyste se vyhnuli přerušení vaší aplikace z důvodu tohoto problému nebo aby se znovu zaregistrovala certifikační autorita, která byla odvolána, musíte provést následující akce:

  1. Obraťte se na poskytovatele certifikátů a zjistěte, jak znovu vytvořit certifikáty.
  2. Po jejich opětovném vydání aktualizujte certifikáty na službě Application Gateway/WAF s úplným řetězem důvěryhodnosti (listový, zprostředkující a kořenový certifikát). Na základě toho, kde certifikát používáte, aktualizujte certifikáty podle kroků uvedených v naslouchacím procesu nebo v nastavení HTTP služby Application Gateway. Další informace najdete na odkazech na dokumentaci.
  3. Aktualizujte back-endové aplikační servery tak, aby používaly znovu použitelný certifikát. Postup aktualizace certifikátu se může lišit v závislosti na používaném back-endovém serveru. Projděte si dokumentaci od dodavatele.

Chcete-li aktualizovat certifikát ve vašem posluchači:

  1. V portálu Azure otevřete prostředek Application Gateway.
  2. Otevřete nastavení posluchače, která jsou přidružená k certifikátu.
  3. Vyberte Obnovit nebo upravit vybraný certifikát.
  4. Nahrajte nový certifikát PFX pomocí hesla a vyberte Uložit.
  5. Přejděte na web a ověřte, jestli web funguje podle očekávání. Další informace najdete v tématu Obnovení certifikátů služby Application Gateway.

Pokud odkazujete na certifikáty z Key Vault v naslouchacím procesu služby Application Gateway, doporučujeme pro rychlou změnu provést následující kroky:

  1. Na portálu Azure přejděte na nastavení Key Vault, která jsou přidružená ke službě Application Gateway.
  2. Přidejte nebo naimportujte znovu vydaný certifikát ve vašem úložišti. Další informace najdete v tématu Quickstart: Vytvoření trezoru klíčů pomocí portálu Azure.
  3. Po importu certifikátu přejděte do nastavení naslouchacího procesu služby Application Gateway a v části Nastavte certifikát z Key Vault vyberte rozevírací seznam Certificate a vyberte nedávno přidaný certifikát.
  4. Zvolte Uložit. Další informace o ukončení protokolu TLS ve službě Application Gateway s certifikáty Key Vault najdete v tématu TLS ukončení s certifikáty Key Vault.

Aktualizace certifikátu v nastavení HTTP:

Pokud používáte verzi v1 SKU služby Application Gateway/WAF, musíte nahrát nový certifikát jako back-endový autentizační certifikát.

  1. V portálu Azure otevřete prostředek Application Gateway.
  2. Otevřete nastavení HTTP, která jsou přidružená k vašemu certifikátu.
  3. Vyberte Přidat certifikát, nahrajte znovu uložený certifikát a vyberte Uložit.
  4. Starý certifikát můžete později odebrat tak , že vyberete tlačítko možnosti ... vedle starého certifikátu. Vyberte Odstranit a pak vyberte Uložit. Další informace najdete v tématu Konfigurace kompletního protokolu TLS pomocí služby Application Gateway s portálem.

Pokud používáte skladovou položku V2 služby Application Gateway nebo WAF, nemusíte nový certifikát nahrávat v nastavení HTTP, protože skladová položka V2 používá důvěryhodné kořenové certifikáty a tady není potřeba provádět žádnou akci.

Konfigurace – proxy protokol TLS/TCP

Používá vrstva 7 a vrstva 4 služby Application Gateway stejné ip adresy front-endu?

Ano. Směrování vrstvy 7 i vrstvy 4 prostřednictvím aplikační brány používá stejnou konfiguraci front-endové IP adresy. Tímto způsobem můžete všechny klienty směrovat na jednu IP adresu (veřejnou nebo privátní) a stejný prostředek brány je bude směrovat na základě nakonfigurovaných protokolů naslouchacího procesu a portů.

Můžu pro provoz HTTP použít proxy protokol TCP nebo TLS?

I když se provoz HTTP(S) dá obsluhovat i přes proxy protokoly L4, nedoporučujeme to dělat. Řešení proxy serveru L7 služby Application Gateway nabízí větší kontrolu a zabezpečení protokolů HTTP(S) prostřednictvím pokročilých funkcí, jako jsou přepsání, spřažení relací, přesměrování, webSockets, WAF a další.

Jaké jsou názvy vlastností proxy vrstvy 4?

Vlastnosti prostředku pro funkce vrstvy 4 se odlišují od vlastností prostředků vrstvy 7. Proto při použití rozhraní REST API nebo rozhraní příkazového řádku musíte použít následující vlastnosti.

Vlastnost Účel
naslouchací proces Pro naslouchací programy využívající protokol TLS nebo TCP
pravidlo směrování Přidružení posluchače vrstvy 4 k nastavení back-endu vrstvy 4
sbírka nastavení backendu Nastavení back-endu založeného na protokolu TLS nebo TCP

Poznámka:

Pro nastavení protokolu HTTP nebo HTTPS nemůžete použít žádné vlastnosti vrstvy 4.

Můžu přiřadit naslouchání protokolu TCP/TLS k nastavení backendu protokolu HTTP(S)?

Ne. Vlastnosti vrstvy 4 a Vrstvy 7 nelze propojit. Směrovací pravidlo proto umožní propojit naslouchací proces typu Vrstva 4 pouze s nastavením koncového zařízení typu Vrstva 4.

Mohou vlastnosti L7 a L4 mít stejné názvy?

Pro L7 (httpListeners) a L4 (listeners) nemůžete použít stejný název. To platí také pro ostatní vlastnosti L4, jako je backendSettingsCollection a routingRules.

Můžu přidat privátní koncový bod do back-endového fondu při použití protokolů TCP nebo TLS (Layer 4)?

Jistě. Podobně jako proxy vrstvy 7 můžete do back-endového fondu služby Application Gateway přidat privátní koncový bod. Tento privátní koncový bod musí být nasazený v sousední podsíti stejné virtuální sítě vaší aplikační brány.

Používá služba Application Gateway pro backendové servery připojení typu keepalive?

Pro back-endová připojení nepoužívá keepalive. Pro každý příchozí požadavek na připojení front-endového naslouchacího procesu služba Application Gateway zahájí nové připojení na back-end, aby splnila tento požadavek.

Která IP adresa se back-endovému serveru zobrazí při navázání připojení ke službě Application Gateway?

Back-endový server uvidí IP adresu aplikační brány. V současné době nepodporujeme "zachování IP adresy klienta", prostřednictvím které si back-endová aplikace může být vědoma IP adresy původního klienta.

Jak nastavím zásadu TLS pro TLS posluchače?

Stejná konfigurace zásad TLS/SSL platí pro vrstvu 7 (HTTPS) i pro vrstvu 4 (TLS). Nyní můžete pro naslouchací procesy TLS použít profil SSL (pro politiku TLS specifickou pro nasluchače a oboustrannou autentizaci). V současné době ale můžete profil SSL přidružit k naslouchacímu procesu TLS prostřednictvím rozhraní příkazového řádku, PowerShellu nebo rozhraní REST API.

Podporuje služba Application Gateway spřažení relací pro směrování vrstvy 4?

Ne. Směrování klienta na stejný back-endový server se v tuto chvíli nepodporuje. Připojení budou distribuována metodou round-robin na servery v backendovém poolu.

Funguje funkce automatického škálování s proxy serverem vrstvy 4?

Ano, funkce automatického škálování bude fungovat také pro špičky a snížení provozu protokolu TLS nebo TCP.

Podporuje Web Application Firewall (WAF) pro provoz vrstvy 4?

Funkce Web Application Firewall (WAF) nebudou fungovat pro použití vrstvy 4.

Podporuje proxy server vrstvy 4 služby Application Gateway protokol UDP?

Ne. V tuto chvíli není dostupná podpora UDP.

Které porty jsou podporovány pro naslouchání TLS/TCP?

Stejný seznam povolených rozsahů portů a výjimek platí i pro proxy vrstvy 4.

Jak můžu použít stejné číslo portu pro naslouchací procesy veřejného a privátního proxy protokolu TLS/TCP?

Použití společného portu pro TLS/TCP listenery aktuálně není podporováno.

Konfigurace – kontroler příchozího přenosu dat pro AKS

Co je ingress controller?

Kubernetes umožňuje vytvářet prostředky deployment a service k vystavení skupiny podů interně v rámci clusteru. Pokud chcete zpřístupnit stejnou službu externě, je definován prostředek Ingress, který poskytuje vyrovnávání zatížení, ukončení protokolu TLS a virtuální hostování založené na jménu. Pro splnění tohoto Ingress prostředku je vyžadován ingresní kontroler, který naslouchá změnám Ingress prostředků a konfiguruje pravidla pro vyrovnávání zátěže.

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

Můžu službu Application Gateway nakonfigurovat přímo místo použití ingress controlleru?

Přímá konfigurace služby Application Gateway se nepodporuje.

Pokud je potřeba změnit nastavení ve službě Application Gateway, proveďte změnu pomocí vystavené konfigurace kontroleru příchozího přenosu dat nebo jiných objektů Kubernetes, jako je použití podporovaných poznámek. Po propojení služby Application Gateway s kontrolerem příchozího přenosu dat služby Application Gateway (AGIC) se téměř veškerá konfigurace této brány synchronizuje a bude řídit kontrolerem příchozího přenosu dat. Pokud se pokoušíte přímo nakonfigurovat službu Application Gateway imperativním způsobem nebo prostřednictvím infrastruktury jako kódu, tyto změny se nakonec přepíšou kontrolerem příchozího přenosu dat.

Může jedna instance kontroleru příchozího přenosu dat spravovat více aplikačních bran?

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

Proč můj cluster AKS s kubenetem nefunguje s AGIC?

AGIC se pokouší automaticky přidružit prostředek směrovací tabulky k podsíti služby Application Gateway, ale kvůli nedostatku oprávnění pro AGIC se to nemusí podařit. Pokud AGIC nemůže přidružit směrovací tabulku k podsíti služby Application Gateway, zobrazí se v protokolech AGIC chyba. V takovém případě musíte ručně přidružit směrovací tabulku vytvořenou clusterem AKS k podsíti služby Application Gateway. Další informace naleznete v tématu Podporované uživatelem definované trasy.

Můžu cluster AKS a aplikační bránu připojit v samostatných virtuálních sítích?

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

Jaké funkce nejsou podporované v doplňku AGIC?

Rozdíly mezi nasazením AGIC přes Helm a nasazením jako doplněk AKS najdete v tématu Rozdíl mezi nasazením přes Helm a doplňkem AKS.

Kdy mám použít add-on nebo nasazení Helmu?

Rozdíly mezi AGIC nasazenými prostřednictvím Helm a nasazenými jako doplněk AKS najdete v tématu Rozdíl mezi nasazením Helm a doplňkem AKS, zejména tabulky, které dokumentují, které scénáře jsou podporovány AGIC nasazené prostřednictvím Helm oproti nasazení jako doplněk AKS. Obecně platí, že nasazení prostřednictvím nástroje Helm umožňuje otestovat beta funkce a kandidáty na vydání verze před oficiální verzí.

Můžu určit, která verze AGIC se nasadí s doplňkem?

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

Můžu upgradovat cluster běžící s Kubenetem nebo Azure CNI na Azure CNI Overlay s nainstalovaným AGIC?

Ano, upgrade clusteru AKS z Kubenetu nebo CNI na CNI Overlay je automaticky detekován Application Gateway Ingress Controllerem. Doporučujeme naplánovat upgrade během časového období údržby, protože může dojít k přerušení provozu. Detekce a konfigurace podpory pro překrytí CNI může řadiči trvat několik minut po upgradu clusteru.

Konfigurace: Vzájemné ověřování

Co je vzájemné ověřování?

Vzájemné ověřování je obousměrné ověřování mezi klientem a serverem. Vzájemné ověřování se službou Application Gateway v současné době umožňuje bráně ověřit klienta odesílajícího požadavek, což je ověřování klienta. Klient je obvykle jediným klientem, který ověřuje aplikační bránu. Vzhledem k tomu, že služba Application Gateway teď může také ověřovat klienta, stává se vzájemným ověřováním, kdy se služba Application Gateway a klient vzájemně ověřuje.

Je k dispozici vzájemné ověřování mezi službou Application Gateway a jejími backendovými pooly?

Ne, vzájemné ověřování je aktuálně pouze mezi front-endovým klientem a aplikační bránou. Vzájemné ověřování back-endu se v současné době nepodporuje.

Diagnostika a protokolování

Jaké typy protokolů poskytuje služba Application Gateway?

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 bajty příchozí a odchozí. 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 informace patří propustnost v bajtech, celkový počet obsloužených požadavků, počet neúspěšných požadavků a počet instancí back-endu, které nejsou v pořádku. Protokol o výkonu je k dispozici pouze pro SKU v1. Pro skladovou položku v2 místo toho použijte metriky služby Application Gateway .
  • ApplicationGatewayFirewallLog: Pro aplikační brány, které konfigurujete s WAF, protokol brány firewall obsahuje požadavky, které se protokolují prostřednictvím režimu detekce nebo režimu 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 služby Application Gateway.

Jak zjistím, zda jsou členové backendu zdraví?

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

Jaké jsou zásady uchovávání informací pro diagnostické protokoly?

Diagnostické protokoly se přesouvají do úložiště zákazníka. Zákazníci můžou zásady uchovávání informací nastavit na základě svých preferencí. Diagnostické protokoly je možné také odesílat do centra událostí nebo do protokolů Azure Monitor. Další informace najdete v tématu Diagnostika služby Application Gateway.

Jak získám protokoly auditu pro Application Gateway?

Na portálu v podokně nabídek služby Application Gateway vyberte Protokol aktivit pro přístup k protokolu auditu.

Můžu nastavit upozornění se službou Application Gateway?

Ano. Ve službě Application Gateway se pro metriky konfigurují upozornění. Další informace najdete v části Metriky Application Gateway a Upozornění.

Jak analyzovat statistiky provozu pro službu Application Gateway?

Protokoly přístupu můžete zobrazit a analyzovat několika způsoby. Použijte Azure Monitor Logs, Excel, Power BI atd.

Můžete také použít šablonu Resource Manager, která nainstaluje a spustí oblíbenou GoAccess analyzátor protokolů pro protokoly přístupu ke službě Application Gateway. 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 v souboru Readme ve složce šablony Resource Manager.

Co může způsobit, že stav backendu je neznámý?

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

Podporují se protokoly toku NSG u skupin zabezpečení sítě přidružených k podsíti služby Application Gateway v2?

Vzhledem k aktuálním omezením platformy, pokud je ve vaší podsíti Application Gateway v2 (Standard_v2, WAF_v2) NSG a pokud jste povolili protokoly toku NSG, uvidíte chování, které nelze předem stanovit. Tento scénář se v současné době nepodporuje.

Kde služba Application Gateway ukládá zákaznická data?

Application Gateway nepřesouvají ani neukládají zákaznická data z oblasti, ve které jsou nasazená.

Další kroky

  • Last updated on