Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Uwaga / Notatka
Zalecamy użycie modułu Azure Az PowerShell do interakcji z Azure. Aby rozpocząć, zobacz Instalowanie programu Azure PowerShell. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.
Odbiornik to jednostka logiczna, która sprawdza żądania połączeń przychodzących przy użyciu portu, protokołu, hosta i adresu IP. Podczas konfigurowania nasłuchiwacza musisz wprowadzić dla tych ustawień wartości zgodne z odpowiadającymi im wartościami w żądaniu przychodzącym do bramy.
Podczas tworzenia bramy aplikacji przy użyciu witryny Azure Portal można również utworzyć odbiornik domyślny, wybierając protokół i port odbiornika. Możesz wybrać, czy włączyć obsługę PROTOKOŁU HTTP2 na odbiorniku. Po utworzeniu bramy aplikacji możesz edytować ustawienia tego odbiornika domyślnego (appGatewayHttpListener) lub utworzyć nowe odbiorniki.
Typ odbiornika
Podczas tworzenia nowego nasłuchiwacza wybierasz między podstawowym i wielomiejscowym. Wybór zależy od tego, czy routowanie zależy od nazwy hosta w żądaniu przychodzącym.
| Routowanie zależy od nazwy hosta | Typ odbiornika | Behavior |
|---|---|---|
| No | Basic | Akceptuj i przekieruj wszystkie żądania dotyczące dowolnej domeny do pul backendowych. Dowiedz się , jak utworzyć bramę aplikacji przy użyciu podstawowego odbiornika. |
| Yes | Wielomiejscowość | Przekieruj żądania do różnych pul backendowych na podstawie nagłówka hosta lub nazw hostów. Usługa Application Gateway korzysta z nagłówków hostów HTTP 1.1 do hostowania więcej niż jednej witryny internetowej na tym samym publicznym adresie IP i porcie. Aby rozróżnić żądania na tym samym porcie, musisz podać nazwę hosta odpowiadającą nadchodzącemu żądaniu. |
Aby dowiedzieć się więcej o nasłuchiwaczach wielostronnych, zobacz hostowanie wielu stron za pomocą Application Gateway.
Kolejność przetwarzania odbiorników
Dla SKU v1, żądania są dopasowywane zgodnie z kolejnością reguł i typem nasłuchującego. Jeśli reguła z podstawowym odbiornikiem znajduje się jako pierwsza w kolejności, jest przetwarzana jako pierwsza i akceptuje każde żądanie dla tej kombinacji portu i adresu IP. Aby uniknąć tego zachowania, najpierw skonfiguruj reguły z wielostronnymi słuchaczami i przesuń regułę z podstawowym słuchaczem na ostatni punkt w liście.
W przypadku SKU v2 priorytet reguły definiuje kolejność przetwarzania nasłuchiwaczy. Zdefiniuj wieloznaczne i podstawowe nasłuchiwacze z numerem priorytetu wyższym niż nasłuchiwacze specyficzne dla witryny i dla wielu witryn. Ta konfiguracja zapewnia, że listenery specyficzne dla witryny i dla wielu witryn są wykonywane przed listenerami wieloznacznymi i podstawowymi.
Poniższa tabela podsumowuje, jak ustalana jest kolejność przetwarzania w każdym SKU.
| SKU | Co decyduje o kolejności | Zalecana konfiguracja |
|---|---|---|
| v1 | Kolejność zasad i typ słuchacza. Reguła z podstawowym słuchaczem, który pojawia się pierwszy w kolejności, przetwarza się jako pierwsza i akceptuje każde żądanie dotyczące kombinacji portu i IP. | Najpierw skonfiguruj reguły z odbiornikami wielu lokacji, a następnie przesuń regułę z podstawowym odbiornikiem na ostatnią pozycję na liście. |
| v2 | Priorytet reguły. | Zdefiniuj nasłuchiwacze wieloznaczne i podstawowe z numerem priorytetu większym niż ten używany dla nasłuchiwaczy specyficznych dla witryny i dla wielu witryn, tak aby nasłuchiwacze specyficzne dla witryny i dla wielu witryn były wykonywane jako pierwsze. |
Adres IP frontonu
Wybierz adres IP frontonu, który chcesz skojarzyć z tym odbiornikiem. Słuchacz nasłuchuje przychodzących żądań na tym IP.
Wybierz publiczny adres IP frontendu, gdy klienci uzyskują dostęp do aplikacji obsługiwanej przez ten odbiornik z Internetu. Wybierz prywatny adres IP frontendu dla wewnętrznego punktu końcowego, który nie jest dostępny w internecie, na przykład dla wewnętrznej aplikacji biznesowej lub poziomu aplikacji wielopoziomowej, która nadal wymaga rozkładu obciążenia, trwałości sesji lub zakończenia TLS. Aby poznać obsługiwane kombinacje, zobacz Konfiguracja adresów IP frontend.
Uwaga / Notatka
Fronton usługi Application Gateway obsługuje adresy IP z podwójnym stosem. Można utworzyć maksymalnie cztery adresy IP frontonu: dwa adresy IPv4 (publiczne i prywatne) i dwa adresy IPv6 (publiczne i prywatne).
Port frontonu
Skojarz port frontendowy. Możesz wybrać istniejący port lub utworzyć nowy. Wybierz dowolną wartość z dozwolonego zakresu portów. Można używać nie tylko dobrze znanych portów, takich jak 80 i 443, ale także dowolnego dozwolonego portu niestandardowego, który jest odpowiedni. Ten sam port może być używany dla odbiorników publicznych i prywatnych.
Port 80 jest typowym wyborem dla nasłuchiwacza HTTP, a port 443 to typowy wybór dla nasłuchiwacza HTTPS. Użyj niestandardowego portu, gdy aplikacja go wymaga, i popewnij, że wartość mieści się w dozwolonym zakresie dla Twojego SKU, ponieważ obsługiwany zakres różni się między wersjami v1 i v2.
Uwaga / Notatka
W przypadku korzystania z odbiorników prywatnych i publicznych z tym samym numerem portu brama aplikacji zmienia "adres docelowy" przepływu przychodzącego na adresy IP frontonu bramy aplikacji. W związku z tym, w zależności od konfiguracji Grupy zabezpieczeń sieci, może być potrzebna reguła ruchu przychodzącego z docelowymi adresami IP jako publicznymi i prywatnymi adresami IP interfejsu bramy aplikacyjnej.
Reguła ruchu przychodzącego:
- Źródło: (zgodnie z wymaganiami)
- Docelowe adresy IP: publiczne i prywatne adresy IP frontonu bramy aplikacji.
- Port docelowy: (zgodnie z konfiguracją odbiornika)
- Protokół: TCP
Reguła ruchu wychodzącego: (bez określonego wymagania)
Protokół
Wybierz HTTP lub HTTPS. Wybierz HTTPS, gdy ruch między klientem a bramą aplikacji musi być zaszyfrowany, co pozwala bramie na odciążenie szyfrowania i deszyfrowania, dzięki czemu serwery zaplecza nie są obciążone narzutem obliczeniowym TLS. Wybierz HTTP, gdy szyfrowanie nie jest wymagane dla ruchu, który ten słuchacz akceptuje.
W przypadku wybrania protokołu HTTP ruch między klientem a bramą aplikacji jest niezaszyfrowany.
Wybierz pozycję HTTPS, jeśli chcesz zakończyć pracę z protokołem TLS lub kompleksowe szyfrowanie TLS. Ruch między klientem a bramą aplikacji jest szyfrowany, a połączenie TLS zostanie przerwane w bramie aplikacji. Jeśli chcesz szyfrowanie end-to-end TLS do docelowego punktu zaplecza, musisz również wybrać protokół HTTPS w ustawieniach HTTP zaplecza. Dzięki temu ruch jest szyfrowany, gdy brama aplikacji inicjuje połączenie z serwerem zaplecza.
Aby skonfigurować kończenie żądań protokołu TLS, należy dodać certyfikat TLS/SSL do odbiornika. Dzięki temu usługa Application Gateway może odszyfrować ruch przychodzący i szyfrować ruch odpowiedzi do klienta. Certyfikat dostarczony do usługi Application Gateway musi być w formacie Wymiany informacji osobistych (PFX), który zawiera zarówno klucze prywatne, jak i publiczne.
Uwaga / Notatka
W przypadku korzystania z certyfikatu TLS z usługi Key Vault dla odbiornika należy upewnić się, że usługa Application Gateway zawsze ma dostęp do tego połączonego zasobu magazynu kluczy i obiektu certyfikatu w nim. Umożliwia to bezproblemowe działanie funkcji zakończenia sesji TLS i utrzymuje ogólną kondycję zasobu bramy. Jeśli zasób bramy aplikacyjnej wykryje nieprawidłowo skonfigurowany skarbiec kluczy, automatycznie umieszcza powiązane odbiorniki HTTPS w stanie wyłączonym. Dowiedz się więcej.
Obsługiwane certyfikaty
Zobacz Omówienie terminowania TLS i TLS typu end-to-end w usłudze Application Gateway.
Dodatkowa obsługa protokołu
Obsługa protokołu HTTP/2
Application Gateway obsługuje protokół HTTP/2 dla klientów łączących się ze słuchaczami bram aplikacji. Komunikacja z pulami serwerów backendowych zawsze korzysta z HTTP/1.1. Domyślnie obsługa protokołu HTTP/2 jest wyłączona. Poniższy fragment kodu Azure PowerShell pokazuje, jak włączyć to wsparcie:
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
Ważne
Gdy tworzysz zasób bramy aplikacji przez portal Azure, domyślna opcja HTTP2 jest włączona. Możesz wybrać opcję Wyłączone podczas tworzenia, a następnie ponownie włączyć obsługę protokołu HTTP/2, wybierając opcję Włączone w obszarze HTTP2 w sekcji Konfiguracja bramy > aplikacji w portalu Azure.
W przypadkach, gdy klient nie obsługuje HTTP/2, połączenie korzysta z HTTP/1.1. Włączenie HTTP/2 nie wyłącza HTTP/1.1; pozwala na wsparcie obu wariantów.
Uwaga / Notatka
Usługa Application Gateway obsługuje tylko protokół HTTP/2 za pośrednictwem protokołu TLS (odbiorniki HTTPS). Application Gateway nie obsługuje prób aktualizacji protokołu HTTP/2 Cleartext (h2c) z HTTP/1.1 i zwraca błąd 403 Prohibit. Klienci, którzy próbują aktualizacji h2c, powinni korzystać z natywnych połączeń HTTP/2 przez HTTPS lub pozostawać na HTTP/1.1.
Wsparcie HTTP/3 (QUIC)
Ważne
Wsparcie HTTP/3 w Azure Application Gateway jest obecnie w podglądzie. W wersji zapoznawczej funkcje, dostępność i inne aspekty tej funkcji mogą ulec zmianie w odpowiedzi na opinie.
Ta wersja zapoznawcza jest udostępniana bez umowy dotyczącej poziomu usług i nie jest zalecana w przypadku obciążeń produkcyjnych. Niektóre funkcje mogą nie być obsługiwane lub mogą mieć ograniczone możliwości.
Aby uzyskać więcej informacji, zobacz Warunki dodatkowe korzystania z testowych wersji Microsoft Azure.
Application Gateway obsługuje HTTP/3 tylko dla połączeń klientów korzystających z Basic listenerów. Słuchacz obsługujący HTTP/3 może również akceptować ruch HTTP/1.1 lub HTTP/2 od klientów. Komunikacja z Application Gateway do pul serwerów backendowych nadal korzysta z HTTP/1.1.
Obsługa HTTP/3 jest domyślnie wyłączona.
Jak reklamowane jest wsparcie HTTP/3
Application Gateway reklamuje wsparcie dla HTTP/3, używając nagłówka odpowiedzi HTTP Alt-Svc. Po włączeniu protokołu HTTP/3 na odbiorniku nasłuchującym usługa Application Gateway dołącza do odpowiedzi następujący nagłówek Alt-Svc.
Alt-Svc: h3=":<listener-port>"; ma=86400
Po wyłączeniu protokołu HTTP/3 usługa Application Gateway nie dołącza nagłówka Alt-Svc.
Klienci obsługujący HTTP/3 mogą użyć reklamowanej usługi do nawiązania połączenia QUIC na porcie nasłuchu. Klienci, którzy nie obsługują HTTP/3, nadal korzystają z HTTP/2 lub HTTP/1.1 przez TCP.
Obsługa protokołu WebSocket
Obsługa protokołu WebSocket jest domyślnie włączona. Nie ma konfigurowalnego ustawienia umożliwiającego jego włączenie lub wyłączenie. Można używać WebSocket zarówno z odbiornikami HTTP, jak i HTTPS.
Niestandardowe strony błędów
Możesz zdefiniować niestandardowe strony błędów dla różnych kodów odpowiedzi, które zwraca Application Gateway. Możesz skonfigurować strony błędów dla kodów odpowiedzi 400, 403, 405, 408, 500, 502, 503 i 504. Użyj konfiguracji stron błędów na poziomie globalnym lub specyficznym dla słuchacza, aby ustawić je szczegółowo dla każdego słuchacza. Aby uzyskać więcej informacji, zobacz Tworzenie niestandardowych stron błędów usługi Application Gateway.
Uwaga / Notatka
Application Gateway przekazuje błąd z serwera backendowego do klienta bez jego modyfikacji.
Zasady protokołu TLS
Zarządzanie certyfikatami TLS/SSL można scentralizować i zmniejszyć obciążenie związane z odszyfrowywaniem szyfrowania dla farmy serwerów zaplecza. Scentralizowane zarządzanie TLS pozwala także określić centralną politykę TLS odpowiadającą Twoim wymaganiom bezpieczeństwa. Możesz wybrać zdefiniowaną lubniestandardową politykę TLS.
Konfigurujesz politykę TLS do sterowania wersjami protokołów TLS. Możesz skonfigurować bramę aplikacyjną tak, aby używała minimalnej wersji protokołu dla TLS handshake z TLS 1.0, TLS 1.1, TLS 1.2 i TLS 1.3. Domyślnie protokoły SSL 2.0 i 3.0 są wyłączone i nie można ich konfigurować. Aby uzyskać więcej informacji, zobacz Application Gateway TLS policy overview (Omówienie zasad PROTOKOŁU TLS usługi Application Gateway).
Po utworzeniu odbiornika należy skojarzyć go z regułą routingu żądań. Ta reguła określa, jak żądania otrzymane przez słuchacza są kierowane do zaplecza.