Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Nastavení back-endu umožňuje spravovat konfigurace pro back-endová připojení vytvořená z prostředku služby Application Gateway k serveru v back-endovém fondu. Konfiguraci nastavení back-endu je možné přidružit k jednomu nebo více pravidlu směrování.
Typy nastavení back-endu ve službě Application Gateway
Uživatelé portálu sice uvidí možnost Nastavení back-endu, ale uživatelé rozhraní API budou mít přístup ke dvěma typům nastavení. Musíte použít správnou konfiguraci podle protokolu.
- Nastavení HTTP back-endu – jedná se o konfigurace proxy serveru vrstvy 7, které podporují protokoly HTTP a HTTPS.
- Nastavení back-endu – jedná se o konfigurace proxy serveru vrstvy 4 (Preview), které podporují protokoly TLS a TCP.
Vazba na základě souborů cookie.
Aplikace Azure Application Gateway používá soubory cookie spravované bránou k údržbě uživatelských relací. Když uživatel odešle první požadavek do služby Application Gateway, nastaví v odpovědi soubor cookie spřažení s hodnotou hash, která obsahuje podrobnosti relace. Tento proces umožňuje následným požadavkům, které přenášejí soubor cookie spřažení, směrovat na stejný back-endový server, a tím zachovat odolnost.
Tato funkce je užitečná, když chcete zachovat uživatelskou relaci na stejném serveru a když je stav relace uložen místně na serveru pro uživatelskou relaci. Pokud aplikace nedokáže zpracovat spřažení na základě souborů cookie, nemůžete tuto funkci použít. Pokud ho chcete použít, ujistěte se, že klienti podporují soubory cookie.
Poznámka:
Některé bezpečnostní skeny můžou označit soubor cookie spřažení služby Application Gateway, protože nejsou nastavené příznaky Secure nebo HttpOnly. Tyto kontroly neberou v úvahu, že se data v souboru cookie generují pomocí jednosměrného hashování. Soubor cookie neobsahuje žádné informace o uživateli a používá se čistě pro směrování.
Aktualizace prohlížečeChromium v80 přinesla mandát, kde soubory cookie HTTP bez atributu SameSite musí být považovány za SameSite=Lax. V případě požadavků CORS (sdílení prostředků mezi zdroji) musí být cookie odeslána v kontextu třetí strany, musí mít atributy SameSite=None; Secure a mělo by se odesílat pouze přes HTTPS. Jinak, ve scénáři pouze s HTTP, prohlížeč neodesílá soubory cookie v kontextu třetí strany. Cílem této aktualizace z Chromu je zvýšit zabezpečení a vyhnout se útokům CSRF (Cross-Site Request Forgery).
Pro podporu této změny služba Application Gateway (všechny typy skladových položek) od 17. února 2020 kromě existujícího souboru cookie ApplicationGatewayAffinityCORS vloží další soubor cookie s názvem ApplicationGatewayAffinityCORS. Soubor cookie ApplicationGatewayAffinityCORS má dva další atributy ("SameSite=None; Secure"), aby trvalé relace byly zachovány i pro požadavky z různých zdrojů.
Výchozí název souboru cookie spřažení je ApplicationGatewayAffinity a můžete ho změnit. Pokud ve vaší síťové topologii nasazujete více aplikačních bran v pořadí za sebou, musíte pro každý prostředek nastavit jedinečné názvy cookies. Pokud používáte vlastní název cookie pro afinitu, přidá se další soubor cookie s příponou CORS. Příklad: CustomCookieNameCORS.
Poznámka:
Pokud je atribut SameSite=None nastavený, je povinné, že soubor cookie obsahuje také příznak Zabezpečení a musí být odeslán přes PROTOKOL HTTPS. Pokud se přes CORS vyžaduje spřažení relací, musíte svou úlohu migrovat na HTTPS. Projděte si dokumentaci k přesměrování zpracování protokolu TLS a kompletnímu šifrování TLS pro službu Application Gateway. Viz přehled PROTOKOLU SSL, konfigurace aplikační brány s ukončením protokolu TLS a konfigurace kompletního protokolu TLS.
Vyprázdnění připojení
Odvádění připojení pomáhá efektivně odebírat členy z back-endových poolů během plánovaných aktualizací služeb. Platí pro back-endové instance, které jsou explicitně odebrány z back-endového fondu.
Toto nastavení můžete použít u všech členů back-endového fondu tím, že v nastavení back-endu aktivujete Connection Draining. Zajišťuje, aby všechny odregistrované instance v back-endovém fondu neobdržely žádné nové požadavky ani spojení, a přitom si zachovaly stávající připojení, dokud nevyprší nakonfigurovaná hodnota časového limitu. Tento proces platí také pro připojení WebSocket.
| Typ konfigurace | Hodnota |
|---|---|
| Výchozí hodnota, pokud není v nastavení back-endu povolené vyprazdňování připojení | 30 sekund |
| Uživatelem definovaná hodnota při povolení vyprazdňování připojení v nastavení back-endu | 1 až 3600 sekund |
Jedinou výjimkou tohoto procesu jsou požadavky vázané na zrušení registrace instancí kvůli spřaženým relacím spravovaným bránou. Tyto požadavky se budou dál předávat do instancí zrušení registrace.
Poznámka:
Existuje omezení, kdy aktualizace konfigurace ukončí probíhající připojení po vypršení časového limitu vyprázdnění připojení. Pokud chcete toto omezení vyřešit, musíte zvýšit časový limit vyprázdnění připojení v nastavení back-endu na hodnotu vyšší než maximální očekávaná doba stahování klienta.
Protokol
Application Gateway podporuje požadavky na směrování na back-endové servery jak HTTP, tak HTTPS. Pokud zvolíte protokol HTTP, provoz na back-endové servery není zašifrovaný. Pokud není nešifrovaná komunikace přijatelná, zvolte HTTPS.
Toto nastavení v kombinaci s PROTOKOLem HTTPS v naslouchacím procesu podporuje kompletní TLS. To vám umožní bezpečně přenášet citlivá data zašifrovaná do back-endu. Každý back-endový server v back-endovém fondu, který má povolený kompletní protokol TLS, musí být nakonfigurovaný s certifikátem, který umožňuje zabezpečenou komunikaci.
Přístav
Toto nastavení určuje port, na kterém back-endové servery naslouchají provozu ze služby Application Gateway. Porty můžete nakonfigurovat od 1 do 65535.
Důvěryhodný kořenový certifikát
Při výběru protokolu HTTPS v nastavení back-endu využívá prostředek služby Application Gateway výchozí úložiště certifikátů důvěryhodné kořenové certifikační autority k ověření řetězu a pravosti certifikátu poskytovaného back-endovým serverem.
Prostředek služby Application Gateway ve výchozím nastavení obsahuje oblíbené certifikáty certifikační autority, což umožňuje bezproblémová připojení TLS back-endu, když je certifikát back-endového serveru vydaný veřejnou certifikační autoritou. Pokud ale máte v úmyslu používat privátní certifikační autoritu nebo certifikát vygenerovaný svým držitelem s úplným ověřením protokolu TLS, musíte v konfiguraci nastavení back-endu zadat odpovídající certifikát kořenové certifikační autority (.cer).
Nastavení ověřování HTTPS backendu
Pokud je v nastavení back-endu služby Azure Application Gateway vybraná možnost HTTPS, brána provede ověření handshake protokolu TLS při navazování zabezpečeného připojení k back-endovým serverům. Mezi tato ověření patří:
- Ověření řetězu certifikátů, aby se zajistilo, že je certifikát důvěryhodný.
- Ověření jména subjektu certifikátu proti indikaci názvu serveru (SNI) odeslanou službou Application Gateway.
- Ověřením vypršení platnosti certifikátu ověřte, jestli je certifikát stále platný.
Výchozí nastavení ověřování zajišťuje zabezpečenou komunikaci tls mezi bránou a back-endovými službami. V některých scénářích může být nutné upravit jedno nebo více těchto nastavení ověření. Aby služba Application Gateway vyhovovala různým požadavkům zákazníků, nabízí následující konfigurovatelné možnosti. Podle potřeby můžete použít jednu nebo obě možnosti.
| Vlastnosti | Hodnoty |
|---|---|
| validateCertChainAndExpiry | Typ: Booleovská hodnota (true nebo false). Výchozí nastavení je pravdivé. Tím ověříte nebo přeskočíte kontrolu řetězce certifikátů i ověření platnosti. |
| validateSNI | Typ: Booleovská hodnota (true nebo false). Výchozí nastavení je pravdivé. Ověří, jestli běžný název certifikátu poskytnutého back-endovým serverem odpovídá hodnotě SNI (Server Name Indication), kterou služba Application Gateway odeslala. |
| sniName | Typ: Řetězec. Tato vlastnost je vyžadována pouze v případě, že je vlastnost validateSNI nastavena jako true. Můžete zadat hodnotu SNI tak, aby odpovídala běžnému názvu certifikátu v back-endu. Ve výchozím nastavení používá aplikační brána jako SNI hlavičku hostitele příchozího požadavku. |
Poznámka:
- Doporučujeme ponechat všechna ověření povolená pro produkční prostředí. Zakázání některých nebo všech ověření se navrhuje jenom pro účely testování a vývoje, například při použití certifikátů podepsaných svým držitelem.
- Tato nastavení neplatí pro funkci testovací sondy při přidávání vlastní sondy stavu. V důsledku toho se při porovnávání s pravidelnými sondami stavu můžou zobrazit rozdíly ve výsledcích.
- V současné době se nepodporuje proxy protokol TLS.
- Brzy se bude podporovat PowerShell a rozhraní příkazového řádku.
Časový limit požadavku vypršel
Toto nastavení je počet sekund, po které aplikační brána čeká na přijetí odpovědi z back-endového serveru. Výchozí hodnota je 20 sekund. Toto nastavení ale můžete chtít upravit tak, aby odpovídalo potřebám vaší aplikace. Přijatelné hodnoty jsou od 1 sekundy do 86400 sekund (24 hodin).
Přepsat backendovou cestu
Toto nastavení umožňuje nakonfigurovat volitelnou vlastní cestu přesměrování, která se má použít při předání požadavku na back-end. Jakákoli část příchozí cesty, která odpovídá vlastní cestě v poli přepsání backendové cesty, se zkopíruje do předávací cesty. Následující tabulka ukazuje, jak tato funkce funguje:
Když je nastavení HTTP připojené k základnímu pravidlu směrování požadavků:
Původní žádost Přepsat backendovou cestu Požadavek přeposlaný na back-end /domov/ /přebít/ /override/home/ /home/secondhome/ /přebít/ /override/home/secondhome/ Když je nastavení HTTP připojené k pravidlu směrování požadavků na základě cesty:
Původní žádost Pravidlo cesty Přepsat backendovou cestu Požadavek přeposlaný na back-end /pathrule/home/ /pathrule* /přebít/ /override/home/ /pathrule/home/secondhome/ /pathrule* /přebít/ /override/home/secondhome/ /domov/ /pathrule* /přebít/ /override/home/ /home/secondhome/ /pathrule* /přebít/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /přebít/ /přebít/ /pathrule/home/secondhome/ /pathrule/home* /přebít/ /override/secondhome/ /pravidlocesty/ /pravidlocesty/ /přebít/ /přebít/
Použití vlastní sondy
Toto nastavení přidruží vlastní sondu k nastavení HTTP. K nastavení HTTP můžete přidružit pouze jednu vlastní sondu. Pokud explicitně nepřidružíte vlastní sondu, použije se výchozí sonda ke sledování stavu back-endu. Doporučujeme vytvořit vlastní sondu pro větší kontrolu nad monitorováním stavu back-endů.
Poznámka:
Vlastní sonda nemonitoruje stav back-endového poolu, pokud není odpovídající nastavení HTTP explicitně propojeno s posluchačem.
Konfigurace názvu hostitele
Služba Application Gateway umožňuje, aby při připojení k back-endu byl použit odlišný název hostitele než ten, který klient používá pro připojení ke službě Application Gateway. I když tato konfigurace může být užitečná v některých případech, buďte opatrní při přepisování názvu hostitele, protože se může lišit mezi aplikační bránou a klientem oproti cíli na back-endu.
V produkčních prostředích je osvědčeným postupem použít stejný název hostitele pro připojení klienta ke službě Application Gateway a službu Application Gateway k back-endovému cílovému připojení. Tento postup zabraňuje potenciálním problémům s absolutními URL adresami, přesměrovacími URL adresami a soubory cookie vázanými na hostitele.
Před nastavením služby Application Gateway, která se od této odchylky liší, si projděte důsledky takové konfigurace, jak je popsáno podrobněji v Centru architektury: Zachování původního názvu hostitele HTTP mezi reverzním proxy serverem a jeho back-endovou webovou aplikací
Existují dva aspekty nastavení HTTP, které ovlivňují hlavičku Host HTTP používanou službou Application Gateway pro připojení k back-endu:
- "Výběr názvu hostitele z back-endové adresy"
- Přepsání názvu hostitele
Výběr názvu hostitele z back-endové adresy
Tato funkce dynamicky nastavuje hlavičku host v požadavku na název hostitele backendového fondu. Používá IP adresu nebo plně kvalifikovaný název domény.
Tato funkce pomáhá, když se název domény serveru liší od názvu DNS aplikační brány a server spoléhá na konkrétní hlavičku hostitele, která slouží k vyřešení správného koncového bodu.
Příkladem jsou víceklientské služby jako zázemí. App Service je víceklientová služba, která používá sdílený prostor s jednou IP adresou. Služba App Service je tedy přístupná pouze prostřednictvím názvů hostitelů, které jsou nakonfigurované v nastavení vlastní domény.
Ve výchozím nastavení je vlastní název domény example.azurewebsites.net. Pokud chcete získat přístup ke službě App Service pomocí aplikační brány přes název hostitele, který není explicitně zaregistrovaný ve službě App Service, nebo pomocí plně kvalifikovaného názvu domény (FQDN) aplikační brány, můžete upravit název hostitele v původním požadavku na hostitelský název služby App Service. K tomu povolte nastavení získání názvu hostitele z backendové adresy.
U vlastní domény, jejíž existující vlastní název DNS je namapovaný na službu App Service, doporučená konfigurace neumožňuje výběr názvu hostitele z back-endové adresy.
Poznámka:
Toto nastavení se nevyžaduje pro službu App Service Environment, což je vyhrazené nasazení.
Přepsání jména hostitele
Tato funkce nahradí hlavičku host v příchozím požadavku na aplikační bráně zadaným názvem hostitele.
Pokud www.contoso.com je například zadán v nastavení Název hostitele , původní požadavek *https://appgw.eastus.cloudapp.azure.com/path1 se změní na *https://www.contoso.com/path1 při předání požadavku na back-endový server.
Vyhrazené back-endové připojení
Azure Application Gateway ve výchozím nastavení znovu používá nevyužitá backendová připojení, aby optimalizovala využití prostředků TCP připojení pro službu Application Gateway a backendový server. Azure Application Gateway V2 poskytuje vyhrazená připojení k back-endovým serverům, aby podporovala funkce zabezpečení v cestách zákaznických dat, které vyžadují jedinečná back-endová připojení na klienta.
Tato funkce vytváří přímé mapování 1:1 mezi front-endem a back-endovými připojeními a zajišťuje trvalé připojení pro každého jednotlivého klienta.
Poznámka:
Pokud chcete povolit ověřování průchodu protokolem NTLM nebo Kerberos, ujistěte se, že je zapnuté nastavení vyhrazeného back-endového připojení. Tato konfigurace udržuje mapování 1:1 mezi front-endovými a back-endovými připojeními, což je nezbytné pro zachování integrity relací vyžadované těmito ověřovacími protokoly.
Důležité
Vyhrazené back-endové připojení vede ke zvýšení počtu back-endových připojení, a proto může vyžadovat více prostředků pro podporu zvýšených souběžných připojení ve službě Application Gateway a back-endových serverech. Ve službě Application Gateway musíte zvážit zvýšení počtu instancí nebo povolení automatického škálování.
Pokud je back-end vzdáleným serverem, instance služby Application Gateway využívají pro každé připojení porty SNAT. S tím, jak každé připojení klienta vytváří vyhrazené back-endové připojení, se spotřeba portů SNAT odpovídajícím způsobem zvyšuje. Proto je důležité zohlednit potenciální vyčerpání portů SNAT. Pokyny najdete v osvědčených postupech architektury .
Vyhrazené back-endové připojení není podporováno s protokolem HTTP/2.