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

Aplikace Azure lication 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.

Application Gateway podporuje automatické škálování, přesměrování zpracování protokolu TLS a kompletní 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 lokalitách a další funkce. Úplný seznam podporovaných funkcí najdete v tématu Úvod do služby Application Gateway.

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í. Load Balancer vyrovnává provoz ve vrstvě 4 (TCP nebo UDP).

Application Gateway podporuje PROTOKOL 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 Microsoft Azure provozovaném společností 21Vianet a Azure Government.

Dostupnost služby Application Gateway v2 (Standard_v2 a WAF_v2) najdete v tématu Podporované oblasti služby Application Gateway v2.

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

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

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. Nebo ho najdete na webu Azure Portal 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 skladové položky v1 nebudou brány vytvořené po 1. květnu 2023 mít výchozí název DNS automaticky přidružený k prostředku veřejné IP adresy. 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.

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.

U připojení Keep-Alive HTTP/1.1 je časový limit ve službě Application Gateway verze 1 a skladové položky v2 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í 4minutové virtuální IP adresy (VIP) front-endu skladové položky služby Application Gateway v1 i v2. 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 protokolu TCP veřejné IP adresy můžete nastavit 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 na skladové po straně služby Application Gateway v2 je časový limit nečinnosti nastavený na 180 sekund a je nekonfigurovatelný.

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

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

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

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.

V SKU služby Application Gateway v1 se virtuální IP adresa může změnit, pokud službu Application Gateway zastavíte a spustíte. 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í.

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.

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.

Viz důležité informace o velikosti podsítě 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.

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

Ano. Viz Úpravy žádosti.

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

Zřízení většiny nasazení, která používají skladovou položku v2, 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.

Aktualizace iniciované ve službě Application Gateway se použijí 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. Během aktualizace služba Application Gateway dočasně běží s omezenou maximální kapacitou, která je určena počtem nakonfigurovaných instancí. Proces aktualizace pokračuje k další sadě instancí pouze v případě, že aktuální sada instancí byla úspěšně upgradována.

¹ Doporučujeme nakonfigurovat minimální počet instancí 2 pro nasazení skladové položky služby Application Gateway v1, aby se zajistilo, že alespoň jedna instance může obsluhovat provoz při použití aktualizací.

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

Ano. Další informace najdete v tématu Migrace brány Aplikace Azure lication Gateway a firewallu webových aplikací z v1 na v2.

Ano. Skladová položka služby Application Gateway v1 se nadále podporuje. Důrazně doporučujeme přejít na verzi 2, abyste mohli využívat aktualizace funkcí v této SKU. Další informace o rozdílech mezi funkcemi v1 a v2 najdete v tématu Automatické škálování a zónově redundantní služba Application Gateway v2. Nasazení skladových položek služby Application Gateway v1 v1 můžete ručně migrovat na verzi 2 podle našeho dokumentu migrace v1-v2.

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

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.

Ano. Aktualizace prohlížeče Chromium v80 zavedla mandát pro soubory cookie HTTP bez atributu SameSite, který se má považovat za SameSite=Lax. To znamená, že soubor cookie spřažení služby Application Gateway nebude v kontextu třetí strany odesílat prohlížeč.

Pro podporu tohoto scénáře služba Application Gateway vloží kromě existujícího ApplicationGatewayAffinity souboru cookie další soubor cookieApplicationGatewayAffinityCORS. Tyto soubory cookie jsou podobné, ale ApplicationGatewayAffinityCORS soubor cookie má dva další atributy: SameSite=None a Secure. Tyto atributy udržují rychlé relace i pro požadavky mezi zdroji. 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-endového fondu. Jakýkoli naslouchací proces, který přesměruje jenom provoz, není aktivním naslouchacím procesem. Naslouchací procesy přidružené k pravidlům 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ěrováovat provoz nebo jinak je naslouchací proces považován za aktivní. Podrobnosti o limitu jednotlivých komponent najdete v tématu Limity, kvóty a omezení předplatného a služeb Azure.

Skladová položka služby Application Gateway v1 podporuje scénáře s vysokou dostupností při nasazení dvou nebo více instancí. Azure tyto instance distribuuje napříč aktualizačními doménami a doménami selhání, aby se zajistilo, že všechny instance selžou ve stejnou dobu. Skladová položka v1 podporuje škálovatelnost přidáním více instancí stejné brány ke sdílení zatížení.

Skladová položka v2 automaticky zajišťuje, že se nové instance rozdělí mezi domény selhání a aktualizační domény. 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.

Pomocí Azure Traffic Manageru můžete distribuovat provoz mezi několik aplikačních bran v různých datacentrech.

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

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.

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

Ano.

Ano.

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íť.

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 fondů, použijte partnerský vztah virtuálních sítí nebo azure VPN Gateway.

Stejně jako jakýkoli překladač DNS bude prostředek služby Application Gateway respektovat hodnotu TTL (Time to Live) záznamu DNS back-endového 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.

Instance vaší aplikační brány používají konfiguraci DNS virtuální sítě pro překlad 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í.

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

Aplikační bránu můžete přesunout pouze mezi podsítěmi ve stejné virtuální síti. Podporuje se v1 s veřejným a privátním front-endem (dynamické přidělování) a v2 pouze s veřejným front-endem. 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 PowerShellu 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>

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

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

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

Viz omezení služby Application Gateway.

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

Ano. Partnerský vztah virtuálních sítí pomáhá vyrovnávat zatížení provozu v jiných virtuálních sítích.

Ano, pokud je povolený provoz.

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

Ne.

Viz Pořadí pravidel zpracování.

Pole Hostitel určuje název, na který se má sonda odeslat, když jste nakonfigurovali více lokalitách ve 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>.

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

Ano, pro souběžnou podporu veřejných a privátních klientů můžete použít veřejné a privátní naslouchací procesy 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í.

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íť duální zásobník. Application Gateway v1 nepodporuje virtuální sítě se dvěma zásobníky.

Skladové položky služby Application Gateway v1 se můžou spouštět v režimu schváleného provozu 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ý, FIPSMode musí být nastavení nakonfigurované prostřednictvím PowerShellu, šablony Azure Resource Manageru nebo rozhraní REST API po registraci předplatného, aby se povolila FIPSmodekonfigurace .

Poznámka: V rámci dodržování předpisů FedRAMP vláda USA vyžaduje, aby systémy fungovaly v režimu schváleném fips po srpnu 2024.

Postup povolení režimu FIPS ve skladové poště V1:

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

Pokud se chcete zaregistrovat pomocí Azure PowerShellu, otevřete příkazový řádek Cloud Shellu a zadejte následující:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Registrace pomocí webu Azure Portal:

• Přihlaste se k webu Azure Portal a vyhledejte funkce ve verzi Preview.
• Do pole filtru zadejte AllowApplicationGatewayEnableFIPS . Vyberte Application Gateway V1 Povolit režim FIPS a pak vyberte Zaregistrovat.

Krok 2: Nastavte vlastnost enableFips na true pomocí PowerShellu, šablony Azure Resource Manageru 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 se třemi tečkami, režim FIPS je zakázaný, můžete použít křivku 25519, NistP256 a NistP384, zatímco s povoleným režimem FIPS jsou povoleny pouze NistP256 a NistP384 a křivka25519 je zakázaná. 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.

Služba Application Gateway v2 v současné době podporuje pouze konfiguraci front-endu privátníCH IP adres (bez veřejné IP adresy) prostřednictvím verze Public Preview. Další informace najdete v tématu Nasazení privátní služby Application Gateway (Preview).

Pro aktuální podporu obecné dostupnosti služba Application Gateway v2 podporuje následující kombinace:

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

Pokud chcete omezit provoz jenom na privátní IP adresy s aktuálními funkcemi, postupujte takto:

1. Vytvořte aplikační bránu s veřejnou i privátní IP adresou front-endu.

2. Nevytvářit žádné naslouchací procesy pro veřejnou IP adresu front-endu. Application Gateway nebude naslouchat žádnému provozu na veřejné IP adrese, pokud pro ni nejsou vytvořeny žádné naslouchací procesy.

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

   1. Povolte provoz ze zdroje jako název služby GatewayManager, Destination as Any a cílový port jako 65200-65535. Tento rozsah portů se vyžaduje pro komunikaci s infrastrukturou Azure. Tyto porty jsou chráněné (uzamčené) ověřováním certifikátů. Externí entity, včetně správců uživatelů brány, nemůžou v těchto koncových bodech zahajovat změny bez příslušných certifikátů.

   2. Povolte provoz ze zdroje jako značku služby AzureLoadBalancer a cílový port jako Libovolný.

   3. Odepřít veškerý příchozí provoz ze zdroje jako značku služby Internet a cílový port jako Jakýkoli. Udělte tomuto pravidlu nejnižší prioritu v příchozích pravidlech.

   4. Ponechte výchozí pravidla, jako je AllowVNetInBound , aby přístup k privátní IP adrese nebyl blokovaný.

   5. Odchozí připojení k internetu není možné blokovat. V opačném případě se setkáte s problémy s protokolováním a metrikami.

Ukázková konfigurace skupiny zabezpečení sítě pro privátní přístup pouze s IP adresou:

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 spustíte, fakturace se zastaví a 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

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.

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 protokolu TLS, najdete v tématu Konfigurace verzí zásad TLS a šifrovacích sad ve službě Application Gateway.

Ano. Application Gateway podporuje přesměrování zpracování protokolu TLS a koncové šifrování TLS, které znovu zašifruje provoz do back-endu.

Ano. Službu Application Gateway můžete nakonfigurovat tak, aby odepřela protokoly TLS1.0, TLS1.1 a TLS1.2. Ve výchozím nastavení jsou protokoly SSL 2.0 a 3.0 už zakázané a nedají se konfigurovat.

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

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

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

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

Ano, skladová položka služby Application Gateway v2 podporuje službu 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 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.

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

Členové ca/Browser nedávno publikovali sestavy s podrobnostmi o několika certifikátech vydaných dodavateli certifikační autority, které používají naši zákazníci, Microsoft a vyšší technologická komunita, která nedodržovala oborové standardy pro veřejně důvěryhodné certifikační autority. Sestavy týkající se certifikačních autorit nesplňujících požadavky najdete tady:

• 1649951 chyb
• 1650910 chyby

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 služby Azure. 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 článek Odvolání nevyhovujících certifikačních autorit, které by mohly mít vliv na 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 opětovném spuštění aktualizujte certifikáty ve službě Application Gateway nebo WAF úplným řetězem důvěryhodnosti (list, 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.

Aktualizace certifikátu v naslouchacím procesu:

1. Na webu Azure Portal otevřete prostředek služby Application Gateway.
2. Otevřete nastavení naslouchacího procesu, která jsou přidružená k vašemu 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 v naslouchacím procesu služby Application Gateway odkazujete na certifikáty ze služby Key Vault, doporučujeme pro rychlou změnu provést následující kroky:

1. Na webu Azure Portal přejděte do nastavení služby Key Vault, která jsou přidružená ke službě Application Gateway.
2. Přidejte nebo naimportujte znovu použitelný certifikát v úložišti. Další informace najdete v tématu Rychlý start: Vytvoření trezoru klíčů pomocí webu Azure Portal.
3. Po importu certifikátu přejděte do nastavení naslouchacího procesu služby Application Gateway a v části Zvolte certifikát ze služby Key Vault vyberte rozevírací seznam Certifikát 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 služby Key Vault najdete v tématu Ukončení protokolu TLS s certifikáty služby Key Vault.

Aktualizace certifikátu v nastavení HTTP:

Pokud používáte skladovou položku v1 služby Application Gateway nebo WAF, musíte nový certifikát nahrát jako ověřovací certifikát back-endu.

1. Na webu Azure Portal otevřete prostředek služby 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.

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

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ší.

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

• REST API
• Rozhraní příkazového řádku

Ne. Vlastnosti vrstvy 4 a Vrstvy 7 nelze propojit. Pravidlo směrování proto umožní propojit naslouchací proces vrstvy 4 pouze s nastavením back-endu vrstvy 4.

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

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.

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

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.

Stejná konfigurace zásad TLS/SSL platí pro vrstvu 7 (HTTPS) i pro vrstvu 4 (TLS). Pro naslouchací procesy TLS (pro naslouchací procesy specifické pro naslouchací proces a vzájemné ověřování) teď můžete použít profil SSL. 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.

Ne. Směrování klienta na stejný back-endový server se v tuto chvíli nepodporuje. Připojení se distribuují kruhovým dotazem na servery v back-endovém fondu.

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

Možnosti firewallu webových aplikací (WAF) nebudou fungovat pro použití vrstvy 4.

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

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

Použití běžného portu pro naslouchací procesy TLS/TCP se v současné době nepodporuje.

Kubernetes umožňuje vytvářet deployment prostředky a service vytvářet skupiny podů interně v clusteru. Pokud chcete zpřístupnit stejnou službu externě, Ingress definuje se prostředek, který poskytuje vyrovnávání zatížení, ukončení protokolu TLS a hostování virtuálních hostitelů založených na názvu. Pro splnění tohoto Ingress prostředku se vyžaduje kontroler příchozího přenosu dat, který naslouchá všem změnám Ingress prostředků a konfiguruje zásady nástroje pro vyrovnávání zatížení.

Kontroler příchozího přenosu dat služby Application Gateway (AGIC) umožňuje službě Application Gateway používat jako příchozí přenos dat pro službu Azure Kubernetes Service, označovanou také jako cluster AKS.

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.

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.

AGIC se pokusí automaticky přidružit prostředek směrovací tabulky k podsíti služby Application Gateway, ale nemusí to udělat kvůli nedostatku oprávnění z AGIC. 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.

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 vygenerovanou službou AKS k podsíti služby Application Gateway.

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

Rozdíly mezi AGIC nasazenými prostřednictvím Nástroje 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é dokumenty podporují AGIC nasazené prostřednictvím nástroje Helm, a ne doplňku 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í.

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

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.

Ne, vzájemné ověřování je aktuálně pouze mezi front-endovým klientem a aplikační bránou. Back-end vzájemné ověřování 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 bajty v nebo mimo. Obsahuje jeden záznam na 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.
• 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.

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

Diagnostické protokoly proudí do účtu ú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 také možné odesílat do centra událostí nebo do protokolů služby Azure Monitor. Další informace najdete v tématu Diagnostika služby Application Gateway.

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

Ano. Ve službě Application Gateway se pro metriky konfigurují upozornění. Další informace najdete v tématu Metriky služby Application Gateway a příjem oznámení o upozorněních.

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

Můžete také použít šablonu Resource Manageru, která nainstaluje a spustí oblíbený analyzátor protokolů GoAccess 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 GitHubu v souboru Readme ve složce šablony Resource Manageru.

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.

Vzhledem k aktuálním omezením platformy platí, že pokud máte skupinu zabezpečení sítě v podsíti služby Application Gateway v2 (Standard_v2, WAF_v2) a pokud jste povolili protokoly toku NSG, uvidíte nedeterministické chování. Tento scénář se v současné době nepodporuje.

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

Další kroky

• Další informace o službě Application Gateway najdete v tématu Co je Aplikace Azure lication Gateway.
• Další informace o ukončení protokolu TLS a kompletním šifrování TLS se službou Application Gateway najdete v tématu Povolení kompletního protokolu TLS ve službě Aplikace Azure lication Gateway.