Konfigurace posluchače služby Application Gateway

Poznámka:

Při práci s Azure doporučujeme používat modul Azure Az PowerShellu. Začněte tím, že si projdete téma Instalace Azure PowerShellu. Informace o tom, jak migrovat na modul Az PowerShell, najdete v tématu Migrace Azure PowerShellu z AzureRM na Az.

Naslouchadlo je entita, která kontroluje příchozí požadavky na připojení pomocí portu, protokolu, hostitele a IP adresy. Při konfiguraci naslouchacího musíte zadat hodnoty, které odpovídají odpovídajícím hodnotám v příchozím požadavku na bránu.

Když vytvoříte aplikační bránu pomocí webu Azure Portal, vytvoříte také výchozí naslouchací proces tak, že zvolíte protokol a port naslouchacího procesu. Můžete zvolit, jestli chcete povolit podporu HTTP2 v naslouchacím procesu. Po vytvoření aplikační brány můžete upravit nastavení tohoto výchozího naslouchacího procesu (appGatewayHttpListener) nebo vytvořit nové naslouchací procesy.

Typ posluchače

Při vytváření nového naslouchacího procesu si zvolíte mezi základním a vícestránkovým. Volba závisí na tom, zda směrování závisí na jménu hostitele v příchozím požadavku.

Směrování závisí na názvu hostitele Typ posluchače Chování
No Basic Přijímejte a přeposílejte všechny požadavky na jakoukoli doménu do backendových poolů. Zjistěte , jak vytvořit aplikační bránu se základní naslouchací komponentou.
Yes Více webů Přesměrujte požadavky do různých backendových poolů podle hlavičky hostitele nebo názvů hostitelů. Služba Application Gateway se při hostování více než jednoho webu na stejné veřejné IP adrese a portu spoléhá na hlavičky hostitele HTTP 1.1. Pro rozlišení požadavků na stejném portu musíte zadat název hostitele, který odpovídá příchozímu požadavku.

Pro více informací o multi-site listenerech viz hostování více webů pomocí Application Gateway.

Pořadí zpracování posluchačů

U varianty SKU v1 se požadavky shodují podle pořadí pravidel a typu nasluchače. Pokud je pravidlo se základním naslouchajícím prvním v pořadí, zpracuje se jako první a přijme všechny požadavky na tento port a kombinaci IP adresy. Abyste tomu předešli, nejprve nakonfigurujte pravidla pro vícestránkové naslouchací procesy a pravidlo se základním naslouchacím procesem posuňte na poslední místo v seznamu.

U SKU v2 definuje priorita pravidla pořadí, ve kterém se zpracovávají posluchače. Naslouchací procesy generické a základní by měly mít prioritu s vyšším číslem než naslouchací procesy specifické pro web a pro více webů, aby se zajistilo, že se procesy specifické pro web a více webů spustí před procesy generickými a základními.

Následující tabulka shrnuje, jak je v každém SKU určeno pořadí zpracování.

skladová jednotka (SKU) Co určuje pořadí Doporučená konfigurace
v1 Pořadí pravidel a typ posluchače. Pravidlo se základním naslouchačem, které je v pořadí první, zpracuje jako první a přijme jakýkoli požadavek pro danou kombinaci portu a IP adresy. Nejprve nakonfigurujte pravidla s listenery pro více webů a pravidlo se základním listenerem přesuňte na poslední místo v seznamu.
v2 Priorita pravidla Definujte zástupné a základní posluchače s číslem priority vyšším, než je číslo použité pro posluchače pro konkrétní web a pro více webů, aby se posluchače pro konkrétní web a pro více webů spustily jako první.

Front-endová IP adresa

Zvolte front-endovou IP adresu, kterou chcete přidružit k tomuto naslouchacímu procesu. Naslouchací proces bude naslouchat příchozím požadavkům na této IP adrese.

Vyberte veřejnou frontendovou IP adresu, když klienti přistupují k aplikaci za tímto posluchačem přes internet. Vyberte si soukromou frontendovou IP adresu pro interní endpoint, který není vystaven internetu, například interní aplikaci typu line-of-business nebo úroveň vícestupňové aplikace, která stále vyžaduje rozložení zátěže, přilnavost relace nebo ukončení TLS. Pro podporované kombinace viz Konfigurace frontendových IP adres.

Poznámka:

Front-end služby Application Gateway podporuje IP adresy se dvěma zásobníky. Můžete vytvořit až čtyři front-endové IP adresy: dvě IPv4 adresy (veřejné a soukromé) a dvě IPv6 adresy (veřejné a soukromé).

Front-endový port

Přidružte front-endový port. Můžete vybrat existující port nebo vytvořit nový. Zvolte libovolnou hodnotu z povoleného rozsahu portů. Můžete použít nejen dobře známé porty, například 80 a 443, ale všechny povolené vlastní porty, které jsou vhodné. Stejný port lze použít pro veřejné a soukromé posluchače.

Port 80 je typickou volbou pro HTTP listener a port 443 je typickou volbou pro HTTPS listener. Použijte vlastní port, když ho vaše aplikace vyžaduje, a ověřte, že hodnota spadá do povoleného rozsahu pro vaše SKU, protože podporovaný rozsah se liší mezi SKU v1 a v2.

Poznámka:

Pokud používáte privátní a veřejná naslouchací rozhraní se stejným číslem portu, vaše aplikační brána změní "cíl" příchozího toku na front-endové IP adresy vaší brány. V závislosti na konfiguraci vaší skupiny zabezpečení sítě proto možná budete potřebovat příchozí pravidlo s cílovými IP adresami jako veřejnými a privátními IP adresami vaší aplikační brány.

Příchozí pravidlo:

  • Zdroj: (podle vašeho požadavku)
  • Cílové IP adresy: Veřejné a privátní front-endové IP adresy vaší aplikační brány.
  • Cílový port: (podle nastavení posluchače)
  • Protokol: TCP

Odchozí pravidlo: (bez konkrétního požadavku)

Protokol

Vyberte HTTP nebo HTTPS. Zvolte HTTPS, když musí být provoz mezi klientem a aplikační bránou šifrován, což také umožňuje bráně odpojit šifrování a dešifrovací práci, takže vaše backendové servery nejsou zatíženy přetížením TLS výpočtů. Zvolte HTTP, pokud toto šifrování není potřeba pro provoz, který tento posluchač přijímá.

  • Pokud zvolíte PROTOKOL HTTP, provoz mezi klientem a aplikační bránou není zašifrovaný.

  • Zvolte HTTPS, pokud chcete šifrování TLS ukončit nebo kompletní šifrování TLS. Provoz mezi klientem a aplikační bránou se zašifruje a připojení TLS se ukončí ve službě Application Gateway. Pokud chcete šifrování TLS typu end-to-end do cíle back-endu, musíte zvolit protokol HTTPS i v nastavení HTTP back-endu. Tím se zajistí, že se provoz zašifruje, když služba Application Gateway zahájí připojení k back-endovému cíli.

Pokud chcete nakonfigurovat ukončení protokolu TLS, musí se do naslouchacího procesu přidat certifikát TLS/SSL. To umožňuje službě Application Gateway dešifrovat příchozí provoz a šifrovat provoz odpovědí klientovi. Certifikát poskytnutý službě Application Gateway musí být ve formátu PFX (Personal Information Exchange), který obsahuje privátní i veřejné klíče.

Poznámka:

Při použití certifikátu TLS ze služby Key Vault pro posluchač musíte zajistit, aby vaše služba Application Gateway vždy měla přístup k propojenému trezoru klíčů a objektu certifikátu v něm. To umožňuje bezproblémové operace funkce ukončení protokolu TLS a udržuje celkový stav vašeho prostředku brány. Pokud prostředek služby Application Gateway zjistí chybně nakonfigurovaný trezor klíčů, automaticky umístí přidružené naslouchací procesy HTTPS do zakázaného stavu. Další informace.

Podporované certifikáty

Přehled ukončení protokolu TLS a end-to-end TLS se službou Application Gateway

Další podpora protokolu

Podpora PROTOKOLU HTTP2

Podpora protokolu HTTP/2 je dostupná jenom klientům, kteří se připojují jenom k naslouchacím procesům aplikační brány. Komunikace se skupinami backend serverů je vždy přes HTTP/1.1. Ve výchozím nastavení je podpora HTTP/2 zakázaná. Následující fragment kódu Azure PowerShellu ukazuje, jak to povolit:

$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm

$gw.EnableHttp2 = $true

Set-AzApplicationGateway -ApplicationGateway $gw

Důležité

Při vytváření prostředku aplikační brány prostřednictvím webu Azure Portal je výchozí možnost pro HTTP2 nastavená jako povolená. Při vytváření můžete zvolit Možnost Zakázáno a opětovně povolenou podporu HTTP2 pomocí webu Azure Portal výběrem možnosti Povoleno v části HTTP2 v konfiguraci služby Application Gateway>.

V případech, kdy klient nepodporuje PROTOKOL HTTP2, se použije protokol HTTP1.1. Povolení protokolu HTTP2 nezakážuje HTTP1.1; umožňuje podporu obou.

Poznámka:

Aplikační brána podporuje HTTP/2 pouze přes TLS (posluchače HTTPS). Pokusy o upgrade z protokolu HTTP/1.1 na HTTP/2 (h2c) nejsou podporovány a výsledkem bude chyba 403 Zakázáno. Klienti, kteří se pokoušejí upgradovat h2c, by měli používat nativní připojení HTTP/2 přes PROTOKOL HTTPS nebo zůstat na http/1.1.

Podpora protokolu WebSocket

Podpora protokolu WebSocket je ve výchozím nastavení povolená. Neexistuje žádné uživatelsky konfigurovatelné nastavení pro povolení nebo zakázání. WebSockety můžete použít s naslouchacími procesy HTTP i HTTPS.

Vlastní chybové stránky

Můžete definovat přizpůsobené chybové stránky pro různé kódy odpovědí vrácené službou Application Gateway. Kódy odpovědí, pro které můžete konfigurovat chybové stránky, jsou 400, 403, 405, 408, 500, 502, 503 a 504. Konfiguraci chybové stránky na globální úrovni nebo specifickou pro jednotlivé posluchače můžete použít k podrobnému nastavení pro každého posluchače. Další informace najdete v tématu Vytvoření vlastních chybových stránek služby Application Gateway.

Poznámka:

Chyba pocházející z backendového serveru je službou Application Gateway nepřeměněná předána klientovi.

Zásady PROTOKOLU TLS

Pro back-endovou serverovou farmu můžete centralizovat správu certifikátů TLS/SSL a snížit režijní náklady na dešifrování šifrování. Centralizované zpracování protokolu TLS také umožňuje zadat centrální zásady TLS, které jsou vhodné pro vaše požadavky na zabezpečení. Můžete zvolit předdefinované nebo vlastní zásady TLS.

Zásady PROTOKOLU TLS nakonfigurujete pro řízení verzí protokolu TLS. Aplikační bránu můžete nakonfigurovat tak, aby používala minimální verzi protokolu pro metody handshake tls z TLS1.0, TLS1.1, TLS1.2 a TLS1.3. Ve výchozím nastavení jsou protokoly SSL 2.0 a 3.0 zakázané a nedají se konfigurovat. Další informace najdete v tématu Přehled zásad TLS služby Application Gateway.

Po vytvoření nasloucháče ho přidružíte k pravidlu směrování požadavků. Toto pravidlo určuje, jak se požadavky přijaté v naslouchacím procesu směrují na back-end.

Další kroky

  • Last updated on