Poprzednie

Następne

Planowanie i implementowanie bramy aplikacja systemu Azure

Ukończone

Azure Application Gateway to moduł równoważenia obciążenia ruchu internetowego (OSI layer 7), który umożliwia zarządzanie ruchem kierowanym do aplikacji internetowych. Tradycyjne moduły równoważenia obciążenia działają w warstwie transportu (warstwie OSI 4 — TCP i UDP) i kierują ruch na podstawie źródłowego adresu IP i portu do docelowego adresu IP i portu.

Usługa Application Gateway może podejmować decyzje dotyczące routingu na podstawie dodatkowych atrybutów żądania HTTP, na przykład ścieżki identyfikatora URI lub nagłówków hosta. Na przykład można kierować ruch na podstawie przychodzącego adresu URL. Jeśli więc /images znajduje się w przychodzącym adresie URL, możesz kierować ruch do określonego zestawu serwerów (nazywanych pulą) skonfigurowanych dla obrazów. Jeśli /video znajduje się w adresie URL, ruch jest kierowany do innej puli zoptymalizowanej pod kątem wideo.

Ten typ routingu jest nazywany równoważeniem obciążenia warstwy aplikacji (warstwy OSI 7). Usługa Azure Application Gateway może wykonywać routing oparty na adresach URL i nie tylko.

Składniki usługi Application Gateway

Brama aplikacji służy jako pojedynczy punkt kontaktu dla klientów. Dystrybuuje ruch przychodzący aplikacji między wiele pul zaplecza, w tym maszyn wirtualnych platformy Azure, zestawów skalowania maszyn wirtualnych, aplikacja systemu Azure Service i lokalnych/zewnętrznych serwerów.

Infrastruktura

Infrastruktura usługi Application Gateway obejmuje sieć wirtualną, podsieci, sieciowe grupy zabezpieczeń i trasy zdefiniowane przez użytkownika.

Adres IP frontonu

Bramę aplikacji można skonfigurować tak, aby miała publiczny adres IP, prywatny adres IP lub oba te adresy. Publiczny adres IP jest wymagany w przypadku hostowania zaplecza, do którego klienci muszą uzyskiwać dostęp za pośrednictwem Internetu za pośrednictwem wirtualnego adresu IP (VIP).

Publiczny adres IP nie jest wymagany dla wewnętrznego punktu końcowego, który nie jest uwidoczniony w Internecie. Prywatna konfiguracja frontonu jest przydatna w przypadku wewnętrznych aplikacji biznesowych, które nie są uwidocznione w Internecie. Jest to również przydatne w przypadku usług i warstw w aplikacji wielowarstwowej w granicach zabezpieczeń, które nie są uwidocznione w Internecie, ale wymagają dystrybucji obciążenia działania okrężnego, przyklejania sesji lub kończenia żądań TLS.

Obsługiwany jest tylko jeden publiczny adres IP i jeden prywatny adres IP. Adres IP frontonu należy wybrać podczas tworzenia bramy aplikacji.

Uwaga

Fronton usługi Application Gateway obsługuje adresy IP z podwójnym stosem (publiczna wersja zapoznawcza). Można utworzyć maksymalnie cztery adresy IP frontonu. Dwa to adresy IPv4 (publiczne i prywatne), a dwa to adresy IPv6 (publiczne i prywatne).

• W przypadku publicznego adresu IP można utworzyć nowy publiczny adres IP lub użyć istniejącego publicznego adresu IP w tej samej lokalizacji co brama aplikacji. Aby uzyskać więcej informacji, zobacz Statyczny i dynamiczny publiczny adres IP.
• W przypadku prywatnego adresu IP można określić prywatny adres IP z podsieci, w której jest tworzona brama aplikacji. W przypadku wdrożeń jednostki SKU usługi Application Gateway w wersji 2 należy zdefiniować statyczny adres IP podczas dodawania prywatnego adresu IP do bramy. W przypadku wdrożeń jednostki SKU usługi Application Gateway w wersji 1, jeśli nie określisz adresu IP, dostępny adres IP zostanie automatycznie wybrany z podsieci. Nie można później zmienić wybranego typu adresu IP (statycznego lub dynamicznego).

Adres IP frontonu jest skojarzony z odbiornikiem, który sprawdza żądania przychodzące w adresie IP frontonu.

Można utworzyć odbiorniki prywatne i publiczne o tym samym numerze portu. Należy jednak pamiętać o każdej sieciowej grupie zabezpieczeń skojarzonej z podsiecią usługi Application Gateway. W zależności od konfiguracji sieciowej grupy zabezpieczeń może być potrzebna reguła zezwalania na ruch przychodzący z docelowymi adresami IP jako publicznymi i prywatnymi adresami IP frontonu bramy aplikacji. W przypadku korzystania z tego samego portu brama aplikacji zmienia docelowy przepływ przychodzący na adresy IP frontonu bramy.

Reguła ruchu przychodzącego:

• Źródło: Zgodnie z wymaganiami
  
• Miejsce docelowe: publiczne i prywatne adresy IP frontonu bramy aplikacji.
• Port docelowy: zgodnie ze skonfigurowanymi odbiornikami
• Protokół: TCP

Reguła ruchu wychodzącego: brak określonego wymagania

Odbiorniki

Odbiornik to jednostka logiczna, która sprawdza żądania połączeń przychodzących przy użyciu portu, protokołu, hosta i adresu IP. Podczas konfigurowania odbiornika należy wprowadzić wartości odpowiadające odpowiednim wartościom w żądaniu przychodzącym w bramie.

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

Odbiornik to jednostka logiczna, która sprawdza żądania połączeń przychodzących. Odbiornik akceptuje żądanie, jeśli protokół, port, nazwa hosta i adres IP skojarzony z żądaniem są zgodne z tymi samymi elementami skojarzonymi z konfiguracją odbiornika.

Przed użyciem bramy aplikacji należy dodać co najmniej jeden odbiornik. Może istnieć wiele odbiorników dołączonych do bramy aplikacji i mogą być używane dla tego samego protokołu.

Po wykryciu przez odbiornik żądań przychodzących od klientów brama aplikacji kieruje te żądania do członków w puli zaplecza skonfigurowanej w regule.

Odbiorniki obsługują następujące porty i protokoły.

Porty

Port to miejsce, w którym odbiornik nasłuchuje żądania klienta. Porty dla jednostek SKU w wersji 1 i 2 można skonfigurować zgodnie z poniższymi wymaganiami.

SKU	Obsługiwany zakres portów	Wyjątki
Wersja 2	Od 1 do 64999	22
Wersja 1	Od 1 do 65502	3389

Protokoły

Usługa Application Gateway obsługuje cztery protokoły: HTTP, HTTPS, HTTP/2 i WebSocket:

Uwaga

Obsługa protokołu HTTP/2 jest dostępna tylko dla klientów łączących się z odbiornikami bramy aplikacji. Komunikacja z pulami serwerów zaplecza jest zawsze za pośrednictwem protokołu HTTP/1.1. Domyślnie obsługa protokołu HTTP/2 jest wyłączona. Możesz ją włączyć.

• Określ między protokołami HTTP i HTTPS w konfiguracji odbiornika.
• Obsługa protokołów WebSocket i HTTP/2 jest zapewniana natywnie, a obsługa protokołu WebSocket jest domyślnie włączona. Nie ma żadnych ustawień konfigurowanych przez użytkownika umożliwiających selektywne włączenie lub wyłączenie obsługi protokołu WebSocket. Używaj obiektów WebSocket zarówno z odbiornikami HTTP, jak i HTTPS.

Użyj odbiornika HTTPS na potrzeby kończenia żądań protokołu TLS. Odbiornik HTTPS odciąża szyfrowanie i odszyfrowywanie do bramy aplikacji, więc serwery internetowe nie są obciążone obciążeniem.

Żądanie reguł rozsyłania

Podczas tworzenia bramy aplikacji przy użyciu witryny Azure Portal tworzysz regułę domyślną (reguła1). Ta reguła wiąże odbiornik domyślny (appGatewayHttpListener) z domyślną pulą zaplecza (appGatewayBackendPool) i domyślnymi ustawieniami http zaplecza (appGatewayBackendHttp Ustawienia). Po utworzeniu bramy można edytować ustawienia reguły domyślnej lub utworzyć nowe reguły.

Typ reguły

Podczas tworzenia reguły wybierasz między podstawową i opartą na ścieżce.

• Wybierz pozycję Podstawowa, jeśli chcesz przekazać wszystkie żądania do skojarzonego odbiornika (na przykład blog.contoso.com/*) do pojedynczej puli zaplecza.
  
• Wybierz ścieżkę opartą na ścieżce, jeśli chcesz kierować żądania z określonych ścieżek url do określonych pul zaplecza. Wzorzec ścieżki jest stosowany tylko do ścieżki adresu URL, a nie do parametrów zapytania.

Skojarzony odbiornik

Skojarz odbiornik z regułą, aby reguła routingu żądań skojarzona z odbiornikiem została obliczona w celu określenia puli zaplecza w celu kierowania żądania do.

Skojarzona pula zaplecza

Skojarz z regułą pulę zaplecza zawierającą obiekty docelowe zaplecza obsługujące żądania odbierane przez odbiornik.

• W przypadku reguły podstawowej dozwolona jest tylko jedna pula zaplecza. Wszystkie żądania skojarzonego odbiornika są przekazywane do tej puli zaplecza.
  
• W przypadku reguły opartej na ścieżkach dodaj wiele pul zaplecza odpowiadających każdej ścieżce adresu URL. Żądania pasujące do wprowadzonej ścieżki adresu URL są przekazywane do odpowiedniej puli zaplecza. Ponadto dodaj domyślną pulę zaplecza. Żądania, które nie pasują do żadnej ścieżki adresu URL w regule, są przekazywane do tej puli.
  

Skojarzone ustawienie HTTP zaplecza

Dodaj ustawienie HTTP zaplecza dla każdej reguły. Żądania są kierowane z bramy aplikacji do obiektów docelowych zaplecza przy użyciu numeru portu, protokołu i innych informacji określonych w tym ustawieniu.

W przypadku reguły podstawowej dozwolone jest tylko jedno ustawienie HTTP zaplecza. Wszystkie żądania skojarzonego odbiornika są przekazywane do odpowiednich obiektów docelowych zaplecza przy użyciu tego ustawienia HTTP.

W przypadku reguły opartej na ścieżkach dodaj wiele ustawień http zaplecza odpowiadających każdej ścieżce adresu URL. Żądania pasujące do ścieżki adresu URL w tym ustawieniu są przekazywane do odpowiednich obiektów docelowych zaplecza przy użyciu ustawień HTTP odpowiadających każdej ścieżce adresu URL. Ponadto dodaj domyślne ustawienie HTTP. Żądania, które nie pasują do żadnej ścieżki adresu URL w tej regule, są przekazywane do domyślnej puli zaplecza przy użyciu domyślnego ustawienia HTTP.

Ustawienie przekierowania

Jeśli przekierowanie jest skonfigurowane dla reguły podstawowej, wszystkie żądania w skojarzonym odbiorniku są przekierowywane do obiektu docelowego. Jest to globalne przekierowanie. Jeśli przekierowanie jest skonfigurowane dla reguły opartej na ścieżkach, przekierowywane są tylko żądania w określonym obszarze witryny. Przykładem jest obszar koszyka, który jest oznaczony przez /cart/*. Jest to przekierowanie oparte na ścieżkach.

Odbiornik

Wybierz odbiornik jako docelowy przekierowania, aby przekierować ruch z jednego odbiornika do innego w bramie. To ustawienie jest wymagane, gdy chcesz włączyć przekierowywanie HTTP-to-HTTPS. Przekierowuje ruch z odbiornika źródłowego, który sprawdza przychodzące żądania HTTP do odbiornika docelowego, który sprawdza przychodzące żądania HTTPS. Możesz również uwzględnić ciąg zapytania i ścieżkę z oryginalnego żądania w żądaniu przesłanym dalej do docelowego przekierowania.

Witryna zewnętrzna

Wybierz witrynę zewnętrzną, jeśli chcesz przekierować ruch na odbiornik skojarzony z tą regułą do lokacji zewnętrznej. Możesz dołączyć ciąg zapytania z oryginalnego żądania do żądania przekazanego do obiektu docelowego przekierowania. Nie można przekazać ścieżki do witryny zewnętrznej, która znajdowała się w oryginalnym żądaniu.

Ponowne zapisywanie nagłówków HTTP i adresów URL

Za pomocą reguł ponownego zapisywania można dodawać, usuwać lub aktualizować nagłówki żądań HTTP(S) i odpowiedzi, a także ścieżki adresu URL i parametrów ciągu zapytania, ponieważ pakiety żądań i odpowiedzi są przenoszone między pulami klienta i zaplecza za pośrednictwem bramy aplikacji.

Nagłówki i parametry adresu URL można ustawić na wartości statyczne lub inne nagłówki i zmienne serwera. Pomaga to w ważnych przypadkach użycia, takich jak wyodrębnianie adresów IP klienta, usuwanie poufnych informacji o zapleczu, dodawanie większej liczby zabezpieczeń itd.

Ustawienia protokołu HTTP

Brama aplikacji kieruje ruch do serwerów zaplecza przy użyciu konfiguracji określonej w tym miejscu. Po utworzeniu ustawienia HTTP należy skojarzyć je z co najmniej jedną regułą routingu żądań.

Koligacja na podstawie pliku cookie

aplikacja systemu Azure Gateway używa plików cookie zarządzanych przez bramę do obsługi sesji użytkowników. Gdy użytkownik wysyła pierwsze żądanie do usługi Application Gateway, ustawia plik cookie koligacji w odpowiedzi z wartością skrótu zawierającą szczegóły sesji, dzięki czemu kolejne żądania przenoszące plik cookie koligacji zostaną przekierowane do tego samego serwera zaplecza w celu zachowania gotowości.

Ta funkcja jest przydatna, gdy chcesz zachować sesję użytkownika na tym samym serwerze i gdy stan sesji jest zapisywany lokalnie na serwerze dla sesji użytkownika. Jeśli aplikacja nie może obsługiwać koligacji opartej na plikach cookie, nie możesz użyć tej funkcji. Aby go używać, upewnij się, że klienci obsługują pliki cookie.

Uwaga

Niektóre skanowania luk w zabezpieczeniach mogą oznaczać flagę pliku cookie koligacji usługi Application Gateway, ponieważ flagi Secure lub HttpOnly nie są ustawione. Te skanowania nie uwzględniają, że dane w pliku cookie są generowane przy użyciu jednokierunkowego skrótu. Plik cookie nie zawiera żadnych informacji o użytkowniku i jest używany wyłącznie do routingu.

Opróżnianie połączeń

Połączenie opróżnianie jonów pomaga bezpiecznie usuwać elementy członkowskie puli zaplecza podczas planowanych aktualizacji usługi. Dotyczy to wystąpień zaplecza, które są

• jawnie usunięte z puli zaplecza,
  
• usunięto podczas operacji skalowania w poziomie lub
• zgłoszone jako w złej kondycji przez sondy kondycji.

To ustawienie można zastosować do wszystkich elementów członkowskich puli zaplecza, włączając opróżnianie Połączenie ionów w ustawieniu zaplecza. Gwarantuje to, że wszystkie wyrejestrowanie wystąpień w puli zaplecza nie odbierają żadnych nowych żądań/połączeń przy zachowaniu istniejących połączeń do momentu skonfigurowania wartości limitu czasu. Dotyczy to również połączeń protokołu WebSocket.

Typ konfiguracji	Wartość
Wartość domyślna, gdy opróżnianie Połączenie ion nie jest włączone w ustawieniu zaplecza	30 sekund
Wartość zdefiniowana przez użytkownika w przypadku włączenia opróżniania Połączenie ionu w ustawieniu zaplecza	Od 1 do 3600 sekund

Jedynym wyjątkiem są żądania związane z wyrejestrowaniem wystąpień z powodu koligacji sesji zarządzanej przez bramę i będą nadal przekazywane do wyrejestrowanych wystąpień.

Protokół

Usługa Application Gateway obsługuje zarówno protokół HTTP, jak i HTTPS na potrzeby routingu żądań do serwerów zaplecza. W przypadku wybrania protokołu HTTP ruch do serwerów zaplecza jest niezaszyfrowany. Jeśli niezaszyfrowana komunikacja nie jest akceptowalna, wybierz pozycję HTTPS.

To ustawienie w połączeniu z protokołem HTTPS w odbiorniku obsługuje kompleksowe protokoły TLS. Dzięki temu można bezpiecznie przesyłać poufne dane zaszyfrowane do zaplecza. Każdy serwer zaplecza w puli zaplecza z włączoną kompleksową obsługą protokołu TLS musi być skonfigurowany przy użyciu certyfikatu, aby umożliwić bezpieczną komunikację.

Port

To ustawienie określa port, na którym serwery zaplecza nasłuchują ruchu z bramy aplikacji. Można skonfigurować porty z zakresu od 1 do 65535.

Zaufany certyfikat główny

W przypadku wybrania protokołu HTTPS jako protokołu zaplecza usługa Application Gateway wymaga zaufanego certyfikatu głównego, aby ufać puli zaplecza dla kompleksowej usługi SSL. Domyślnie opcja Użyj dobrze znanego certyfikatu urzędu certyfikacji jest ustawiona na Nie. Jeśli planujesz użyć certyfikatu z podpisem własnym lub certyfikatu podpisanego przez wewnętrzny urząd certyfikacji, musisz podać bramie Application Gateway pasujący certyfikat publiczny, którego będzie używać pula zaplecza. Ten certyfikat należy przekazać bezpośrednio do usługi Application Gateway w programie . Format CER.

Jeśli planujesz użyć certyfikatu w puli zaplecza podpisanej przez zaufany publiczny urząd certyfikacji, możesz ustawić opcję Użyj dobrze znanego certyfikatu urzędu certyfikacji na Wartość Tak i pominąć przekazywanie certyfikatu publicznego.

Przekroczono limit czasu żądania

To ustawienie to liczba sekund oczekiwania bramy aplikacji na odebranie odpowiedzi z serwera zaplecza.

Zastąp ścieżkę zaplecza

To ustawienie umożliwia skonfigurowanie opcjonalnej niestandardowej ścieżki przekazywania do użycia, gdy żądanie jest przekazywane do zaplecza. Każda część ścieżki przychodzącej, która pasuje do ścieżki niestandardowej w polu przesłonięć ścieżkę zaplecza, jest kopiowana do ścieżki przekazywanej. W poniższej tabeli przedstawiono sposób działania tej funkcji:

Gdy ustawienie HTTP jest dołączone do podstawowej reguły routingu żądań:

Oryginalne żądanie	Zastąpij ścieżkę zaplecza	Żądanie przekazane do zaplecza
/W: strona główna/	/Zastąpić/	/override/home/
/home/secondhome/	/Zastąpić/	/override/home/secondhome/

Gdy ustawienie HTTP jest dołączone do reguły routingu żądań opartej na ścieżce:

Oryginalne żądanie	Reguła ścieżki	Zastąpij ścieżkę zaplecza	Żądanie przekazane do zaplecza
/pathrule/home/	/pathrule*	/Zastąpić/	/override/home/
/pathrule/home/secondhome/	/pathrule*	/Zastąpić/	/override/home/secondhome/
/W: strona główna/	/pathrule*	/Zastąpić/	/override/home/
/home/secondhome/	/pathrule*	/Zastąpić/	/override/home/secondhome/
/pathrule/home/	/pathrule/home*	/Zastąpić/	/Zastąpić/
/pathrule/home/secondhome/	/pathrule/home*	/Zastąpić/	/override/secondhome/
/pathrule/	/pathrule/	/Zastąpić/	/Zastąpić/

Korzystanie z sondy niestandardowej

To ustawienie kojarzy sondę niestandardową z ustawieniem HTTP. Można skojarzyć tylko jedną sondę niestandardową z ustawieniem HTTP. Jeśli nie skojarzysz jawnie sondy niestandardowej, domyślna sonda jest używana do monitorowania kondycji zaplecza. Zalecamy utworzenie niestandardowej sondy w celu zapewnienia większej kontroli nad monitorowaniem kondycji zaplecza.

Uwaga

Sonda niestandardowa nie monitoruje kondycji puli zaplecza, chyba że odpowiednie ustawienie HTTP jest jawnie skojarzone z odbiornikiem.

Konfigurowanie nazwy hosta

Usługa Application Gateway umożliwia nawiązanie połączenia z zapleczem w celu użycia innej nazwy hosta niż ta używana przez klienta do nawiązywania połączenia z usługą Application Gateway. Chociaż ta konfiguracja może być przydatna w niektórych przypadkach, należy zachować ostrożność, przesłonięć nazwę hosta między klientem a bramą aplikacji i bramą aplikacji do obiektu docelowego zaplecza.

W środowisku produkcyjnym zaleca się zachowanie nazwy hosta używanej przez klienta w bramie aplikacji jako tej samej nazwy hosta używanej przez bramę aplikacji do docelowego zaplecza. Pozwala to uniknąć potencjalnych problemów z bezwzględnymi adresami URL, adresami URL przekierowania i plikami cookie powiązanymi z hostem.

Przed skonfigurowaniem usługi Application Gateway, która się z tego różni, zapoznaj się z implikacjami takiej konfiguracji, jak opisano bardziej szczegółowo w temacie Centrum architektury: Zachowaj oryginalną nazwę hosta HTTP między zwrotnym serwerem proxy i aplikacją internetową zaplecza.

Istnieją dwa aspekty ustawienia HTTP, które wpływają na nagłówek HTTP hosta używany przez usługę Application Gateway do nawiązywania połączenia z zapleczem:

• Wybierz nazwę hosta z adresu zaplecza
  
• Zastąpienie nazwy hosta

Wybierz nazwę hosta z adresu zaplecza

Ta funkcja dynamicznie ustawia nagłówek hosta w żądaniu na nazwę hosta puli zaplecza. Używa on adresu IP lub nazwy FQDN.

Ta funkcja pomaga, gdy nazwa domeny zaplecza różni się od nazwy DNS bramy aplikacji, a zaplecze opiera się na określonym nagłówku hosta w celu rozpoznania poprawnego punktu końcowego.

Przykładowy przypadek to wielodostępne usługi jako zaplecze. Usługa app Service to wielodostępna usługa, która używa przestrzeni udostępnionej z pojedynczym adresem IP. W związku z tym dostęp do usługi app Service można uzyskać tylko za pośrednictwem nazw hostów skonfigurowanych w ustawieniach domeny niestandardowej.

Domyślnie niestandardowa nazwa domeny jest example.azurewebsites.net. Aby uzyskać dostęp do usługi app Service przy użyciu bramy aplikacji za pośrednictwem nazwy hosta, która nie jest jawnie zarejestrowana w usłudze app Service lub za pośrednictwem nazwy FQDN bramy aplikacji, możesz zastąpić nazwę hosta w oryginalnym żądaniu do nazwy hosta usługi App Service. W tym celu włącz ustawienie wybierz nazwę hosta z adresu zaplecza.

W przypadku domeny niestandardowej, której istniejąca niestandardowa nazwa DNS jest mapowana na usługę app Service, zalecana konfiguracja nie umożliwia wyboru nazwy hosta z adresu zaplecza.

Zastąpienie nazwy hosta

Ta funkcja zastępuje nagłówek hosta w żądaniu przychodzącym w bramie aplikacji nazwą hosta, którą określisz.

Jeśli na przykład www.contoso.com jest określona w ustawieniu Nazwa hosta, oryginalne żądanie *https://appgw.eastus.cloudapp.azure.com/path1zostanie zmienione na *https://www.contoso.com/path1 po przesłaniu żądania do serwera zaplecza.

Pula zaplecza

Pulę zaplecza można wskazać na cztery typy elementów członkowskich zaplecza: określoną maszynę wirtualną, zestaw skalowania maszyn wirtualnych, adres IP/nazwę FQDN lub usługę aplikacji.

Po utworzeniu puli zaplecza należy skojarzyć ją z co najmniej jedną regułą routingu żądań. Należy również skonfigurować sondy kondycji dla każdej puli zaplecza w bramie aplikacji. Po spełnieniu warunku reguły routingu żądań brama aplikacji przekazuje ruch do serwerów w dobrej kondycji (określonych przez sondy kondycji) w odpowiedniej puli zaplecza.

Sondy kondycji

aplikacja systemu Azure Gateway monitoruje kondycję wszystkich serwerów w puli zaplecza i automatycznie zatrzymuje wysyłanie ruchu do dowolnego serwera, który uważa za w złej kondycji. Sondy nadal monitorują taki serwer w złej kondycji, a brama uruchamia kierowanie ruchu do niego po raz kolejny, gdy tylko sondy wykryją go jako w dobrej kondycji.

Domyślna sonda używa numeru portu ze skojarzonego ustawienia zaplecza i innych wstępnych konfiguracji. Możesz użyć sond niestandardowych, aby skonfigurować je w sposób.

Zachowanie sond

Źródłowy adres IP

Źródłowy adres IP sond zależy od typu serwera zaplecza:

• Jeśli serwer w puli zaplecza jest publicznym punktem końcowym, adres źródłowy będzie publicznym adresem IP frontonu bramy aplikacji.
  
• Jeśli serwer w puli zaplecza jest prywatnym punktem końcowym, źródłowy adres IP będzie pochodzić z przestrzeni adresowej podsieci bramy aplikacji.

Operacje sondy

Brama uruchamia sondy natychmiast po skonfigurowaniu reguły przez skojarzenie jej z ustawieniem zaplecza i pulą zaplecza (i odbiornikiem, oczywiście). Ilustracja pokazuje, że brama niezależnie sonduje wszystkie serwery puli zaplecza. Przychodzące żądania, które zaczynają odbierać, są wysyłane tylko do serwerów w dobrej kondycji. Serwer zaplecza jest domyślnie oznaczony jako w złej kondycji do momentu odebrania pomyślnej odpowiedzi sondy.

Wymagane sondy są określane na podstawie unikatowej kombinacji ustawień serwera zaplecza i zaplecza. Rozważmy na przykład bramę z jedną pulą zaplecza z dwoma serwerami i dwoma ustawieniami zaplecza, z których każda ma różne numery portów. Gdy te odrębne ustawienia zaplecza są skojarzone z tą samą pulą zaplecza przy użyciu odpowiednich reguł, brama tworzy sondy dla każdego serwera i kombinację ustawienia zaplecza. Można to wyświetlić na stronie Kondycja zaplecza.

Ponadto wszystkie wystąpienia bramy aplikacji sonduje serwery zaplecza niezależnie od siebie.

Uwaga

Raport kondycji zaplecza jest aktualizowany na podstawie interwału odświeżania odpowiedniego sondy i nie zależy od żądania użytkownika.

Domyślna sonda kondycji

Brama aplikacji automatycznie konfiguruje domyślną sondę kondycji, gdy nie konfigurujesz żadnej niestandardowej konfiguracji sondy. Zachowanie monitorowania działa przez wysłanie żądania HTTP GET do adresów IP lub nazwy FQDN skonfigurowanej w puli zaplecza. W przypadku domyślnych sond, jeśli ustawienia http zaplecza są skonfigurowane dla protokołu HTTPS, sonda używa protokołu HTTPS do testowania kondycji serwerów zaplecza.

Na przykład: brama aplikacji umożliwia używanie serwerów zaplecza A, B i C do odbierania ruchu sieciowego HTTP na porcie 80. Domyślne monitorowanie kondycji testuje trzy serwery co 30 sekund dla dobrej kondycji odpowiedzi HTTP z 30-sekundowym limitem czasu dla każdego żądania. Odpowiedź HTTP w dobrej kondycji ma kod stanu z zakresu od 200 do 399. W takim przypadku żądanie HTTP GET dla sondy kondycji wygląda następująco: http://127.0.0.1/. Zobacz również kody odpowiedzi HTTP w usłudze Application Gateway.

Jeśli domyślne sprawdzanie sondy zakończy się niepowodzeniem dla serwera A, brama aplikacji zatrzymuje przekazywanie żądań do tego serwera. Domyślna sonda nadal sprawdza serwer A co 30 sekund. Gdy serwer A odpowiada pomyślnie na jedno żądanie z domyślnej sondy kondycji, usługa Application Gateway ponownie uruchamia przekazywanie żądań do serwera.

Domyślne ustawienia sondy kondycji

Właściwość sondy	Wartość	Opis
Adres URL sondy	<protocol>://127.0.0.1:<port>/	Protokół i port są dziedziczone z ustawień http zaplecza, z którymi jest skojarzona sonda
Interwał	30	Czas oczekiwania w sekundach przed wysłaniem następnej sondy kondycji.
Limit czasu	30	Czas w sekundach oczekiwania bramy aplikacji na odpowiedź sondy przed oznaczeniem sondy jako w złej kondycji. Jeśli sonda zwróci wartość w dobrej kondycji, odpowiednie zaplecze jest natychmiast oznaczone jako w dobrej kondycji.
Próg złej kondycji	3	Określa, ile sond ma być wysyłanych w przypadku awarii regularnej sondy kondycji. W wersji 1 jednostka SKU te dodatkowe sondy kondycji są wysyłane w krótkim odstępie czasu, aby szybko określić kondycję zaplecza i nie czekać na interwał sondy. W przypadku jednostki SKU w wersji 2 sondy kondycji czekają interwał. Serwer zaplecza jest oznaczony jako wyłączony po osiągnięciu progu złej kondycji przez kolejną liczbę niepowodzeń sondy.

Sonda domyślna sprawdza tylko <protokół>://127.0.0.1:<port> w celu określenia stanu kondycji. Jeśli musisz skonfigurować sondę kondycji, aby przejść do niestandardowego adresu URL lub zmodyfikować inne ustawienia, musisz użyć sond niestandardowych.

Niestandardowa sonda kondycji

Niestandardowe sondy umożliwiają bardziej szczegółową kontrolę nad monitorowaniem kondycji. W przypadku używania sond niestandardowych można skonfigurować niestandardową nazwę hosta, ścieżkę adresu URL, interwał sondy i liczbę nieudanych odpowiedzi do zaakceptowania przed oznaczeniem wystąpienia puli zaplecza jako w złej kondycji itp.

Niestandardowe ustawienia sondy kondycji

Poniższa tabela zawiera definicje właściwości niestandardowej sondy kondycji.

Właściwość sondy	Opis
Nazwa/nazwisko	Nazwa sondy. Ta nazwa służy do identyfikowania i odwoływania się do sondy w ustawieniach http zaplecza.
Protokół	Protokół używany do wysyłania sondy. Musi to być zgodne z protokołem zdefiniowanym w ustawieniach protokołu HTTP zaplecza, które są skojarzone z
Gospodarz	Nazwa hosta do wysłania sondy za pomocą polecenia . W wersji 1 jednostka SKU ta wartość jest używana tylko dla nagłówka hosta żądania sondy. W wersji 2 jednostka SKU jest używana zarówno jako nagłówek hosta, jak i SNI
Ścieżka	Względna ścieżka sondy. Prawidłowa ścieżka zaczyna się od "/"
Port	Jeśli jest zdefiniowana, jest to używane jako port docelowy. W przeciwnym razie używa tego samego portu co ustawienia PROTOKOŁU HTTP, z którymi jest skojarzony. Ta właściwość jest dostępna tylko w jednostce SKU w wersji 2
Interwał	Interwał sondy w sekundach. Ta wartość to przedział czasu między dwoma kolejnymi sondami
Limit czasu	Limit czasu sondy w sekundach. Jeśli prawidłowa odpowiedź nie zostanie odebrana w tym przedziale czasu, sonda zostanie oznaczona jako nieudana
Próg złej kondycji	Liczba ponownych prób sondy. Serwer zaplecza jest oznaczony jako wyłączony po osiągnięciu progu złej kondycji przez kolejną liczbę niepowodzeń sondy

Dopasowywanie sondy

Domyślnie odpowiedź HTTP z kodem stanu z zakresu od 200 do 399 jest uważana za w dobrej kondycji. Niestandardowe sondy kondycji dodatkowo obsługują dwa kryteria dopasowania. Kryteria dopasowania mogą służyć do opcjonalnego modyfikowania domyślnej interpretacji tego, co sprawia, że odpowiedź w dobrej kondycji.

Poniżej przedstawiono kryteria dopasowania:

• Dopasowanie kodu stanu odpowiedzi HTTP — kryterium dopasowania sondy do akceptowania kodu odpowiedzi HTTP lub zakresów kodu odpowiedzi http. Obsługiwane są poszczególne kody stanu odpowiedzi rozdzielane przecinkami lub zakres kodu stanu.
  
• Dopasowanie treści odpowiedzi HTTP — kryterium dopasowania sondy, które analizuje treść odpowiedzi HTTP i pasuje do określonego ciągu użytkownika. Dopasowanie wyszukuje tylko obecność określonego ciągu użytkownika w treści odpowiedzi i nie jest pełnym dopasowaniem wyrażenia regularnego. Określone dopasowanie musi zawierać 4090 znaków lub mniej.

Kryteria dopasowania można określić przy użyciu New-AzApplicationGatewayProbeHealthResponseMatch polecenia cmdlet .

Przykład:

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399

$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

Kryteria dopasowania można dołączyć do konfiguracji sondy przy użyciu -Match operatora w programie PowerShell.

Niestandardowe przypadki użycia sondy

• Jeśli serwer zaplecza zezwala na dostęp tylko do uwierzytelnionych użytkowników, sondy bramy aplikacji otrzymają kod odpowiedzi 403 zamiast 200. Ponieważ klienci (użytkownicy) są zobowiązani do uwierzytelniania się dla ruchu na żywo, możesz skonfigurować ruch sondy tak, aby akceptował 403 jako oczekiwaną odpowiedź.
• Gdy serwer zaplecza ma zainstalowany certyfikat wieloznaczny (*.contoso.com) obsługujący różne domeny podrzędne, można użyć sondy niestandardowej z określoną nazwą hosta (wymaganą dla sieci SNI), która jest akceptowana w celu ustanowienia pomyślnej sondy TLS i raportowania tego serwera jako dobrej kondycji. W przypadku ustawienia "przesłonięć nazwę hosta" w ustawieniu zaplecza na NIE, różne przychodzące nazwy hostów (poddomeny) zostaną przekazane jako do zaplecza.

Zagadnienia dotyczące sieciowej grupy zabezpieczeń

Szczegółowa kontrola nad podsiecią usługi Application Gateway za pośrednictwem reguł sieciowej grupy zabezpieczeń jest możliwa w publicznej wersji zapoznawczej. Więcej informacji można znaleźć tutaj.

W przypadku bieżących funkcji istnieją pewne ograniczenia:

Musisz zezwolić na przychodzący ruch internetowy na portach TCP 65503-65534 dla jednostki SKU usługi Application Gateway w wersji 1, a porty TCP 65200-65535 dla jednostki SKU w wersji 2 z docelową podsiecią jako dowolną i źródło jako tag usługi GatewayManager. Ten zakres portów jest wymagany do komunikacji infrastruktury platformy Azure.

Ponadto nie można zablokować wychodzącej łączności internetowej, a ruch przychodzący pochodzący z tagu AzureLoadBalancer musi być dozwolony.

Jak działa brama aplikacji

Jak brama aplikacji akceptuje żądanie

1. Zanim klient wyśle żądanie do bramy aplikacji, rozpozna nazwę domeny bramy aplikacji przy użyciu serwera systemu nazw domen (DNS). Platforma Azure kontroluje wpis DNS, ponieważ wszystkie bramy aplikacji znajdują się w domenie azure.com.
2. Usługa Azure DNS zwraca adres IP do klienta, czyli adres IP frontonu bramy aplikacji.
   
3. Brama aplikacji akceptuje ruch przychodzący na co najmniej jednym odbiorniku. Odbiornik jest jednostką logiczną, która sprawdza żądania połączeń. Jest on skonfigurowany przy użyciu adresu IP frontonu, protokołu i numeru portu dla połączeń od klientów do bramy aplikacji.
   
4. Jeśli zapora aplikacji internetowej (WAF) jest używana, brama aplikacji sprawdza nagłówki żądań i treść, jeśli jest obecna, względem reguł zapory aplikacji internetowej. Ta akcja określa, czy żądanie jest prawidłowym żądaniem, czy zagrożeniem bezpieczeństwa. Jeśli żądanie jest prawidłowe, jest kierowane do zaplecza. Jeśli żądanie jest nieprawidłowe, a zapora aplikacji internetowej jest w trybie zapobiegania, jest blokowana jako zagrożenie bezpieczeństwa. Jeśli jest w trybie wykrywania, żądanie jest oceniane i rejestrowane, ale nadal przekazywane do serwera zaplecza.
   

aplikacja systemu Azure Gateway może służyć jako wewnętrzny moduł równoważenia obciążenia aplikacji lub jako moduł równoważenia obciążenia aplikacji dostępny z Internetu. Brama aplikacji dostępnej z Internetu używa publicznych adresów IP. Nazwa DNS bramy aplikacji dostępnej z Internetu jest publicznie rozpoznawalna dla jego publicznego adresu IP. W związku z tym bramy aplikacji dostępne z Internetu mogą kierować żądania klientów z Internetu.

Wewnętrzne bramy aplikacji używają tylko prywatnych adresów IP. Jeśli używasz strefy niestandardowej lub Prywatna strefa DNS, nazwa domeny powinna być wewnętrznie rozpoznawana jako prywatny adres IP usługi Application Gateway. W związku z tym wewnętrzne moduły równoważenia obciążenia mogą kierować żądania tylko od klientów z dostępem do sieci wirtualnej dla bramy aplikacji.

Jak brama aplikacji kieruje żądanie

Jeśli żądanie jest prawidłowe i nie jest blokowane przez zaporę aplikacji internetowej, brama aplikacji ocenia regułę routingu żądań skojarzona z odbiornikiem. Ta akcja określa, do której puli zaplecza ma być kierowane żądanie.

Na podstawie reguły routingu żądań brama aplikacji określa, czy mają być kierowane wszystkie żądania na odbiornik do określonej puli zaplecza, kierować żądania do różnych pul zaplecza na podstawie ścieżki adresu URL lub przekierowywać żądania do innego portu lub witryny zewnętrznej.

Gdy brama aplikacji wybierze pulę zaplecza, wysyła żądanie do jednego z serwerów zaplecza w dobrej kondycji w puli (y.y.y.y.y.y). Kondycja serwera jest określana przez sondę kondycji. Jeśli pula zaplecza zawiera wiele serwerów, brama aplikacji używa algorytmu działania okrężnego do kierowania żądań między serwerami w dobrej kondycji. To obciążenie równoważy żądania na serwerach.

Po określeniu serwera zaplecza przez bramę aplikacji zostanie otwarta nowa sesja TCP z serwerem zaplecza na podstawie ustawień protokołu HTTP. Ustawienia protokołu HTTP określają protokół, port i inne ustawienia związane z routingiem, które są wymagane do ustanowienia nowej sesji z serwerem zaplecza.

Port i protokół używany w ustawieniach protokołu HTTP określają, czy ruch między bramą aplikacji a serwerami zaplecza jest szyfrowany (w ten sposób jest to kompleksowe szyfrowanie TLS) czy niezaszyfrowany.

Uwaga

Reguły są przetwarzane w kolejności, w której są wyświetlane w portalu dla jednostki SKU w wersji 1.

Gdy brama aplikacji wysyła oryginalne żądanie do serwera zaplecza, honoruje dowolną konfigurację niestandardową w ustawieniach PROTOKOŁU HTTP związanych z zastępowaniem nazwy hosta, ścieżki i protokołu. Ta akcja utrzymuje koligację sesji opartą na plikach cookie, opróżnianie połączeń, wybór nazwy hosta z zaplecza itd.

Jeśli pula zaplecza:

• Jest publicznym punktem końcowym, brama aplikacji używa publicznego adresu IP frontonu do nawiązania połączenia z serwerem. Jeśli nie ma publicznego adresu IP frontonu, zostanie przypisany do wychodzącej łączności zewnętrznej.
• Zawiera wewnętrzną nazwę FQDN lub prywatny adres IP, brama aplikacji kieruje żądanie do serwera zaplecza przy użyciu prywatnych adresów IP wystąpienia.
• Zawiera zewnętrzny punkt końcowy lub zewnętrznie rozpoznawalną nazwę FQDN, brama aplikacji kieruje żądanie do serwera zaplecza przy użyciu publicznego adresu IP frontonu. Jeśli podsieć zawiera punkty końcowe usługi, brama aplikacji będzie kierować żądanie do usługi za pośrednictwem jego prywatnego adresu IP. Rozpoznawanie nazw DNS jest oparte na prywatnej strefie DNS lub niestandardowym serwerze DNS, jeśli jest skonfigurowany lub używa domyślnego systemu DNS udostępnianego przez platformę Azure. Jeśli nie ma publicznego adresu IP frontonu, zostanie przypisany do wychodzącej łączności zewnętrznej.

Rozpoznawanie nazw DNS serwera zaplecza

Gdy serwer puli zaplecza jest skonfigurowany z w pełni kwalifikowaną nazwą domeny (FQDN), usługa Application Gateway wykonuje wyszukiwanie DNS, aby uzyskać adresy IP nazwy domeny. Wartość adresu IP jest przechowywana w pamięci podręcznej bramy aplikacji, aby umożliwić jej szybsze osiąganie celów podczas obsługi żądań przychodzących.

Usługa Application Gateway zachowuje te buforowane informacje dla okresu równoważnego czasowi wygaśnięcia tego rekordu DNS (czas wygaśnięcia) i wykonuje nowe wyszukiwanie DNS po wygaśnięciu czasu wygaśnięcia. Jeśli brama wykryje zmianę adresu IP dla kolejnej kwerendy DNS, rozpocznie kierowanie ruchu do tego zaktualizowanego miejsca docelowego. W przypadku problemów, takich jak wyszukiwanie DNS, które nie może odebrać odpowiedzi lub rekord już nie istnieje, brama nadal używa ostatniego znanego dobrego adresu IP(es). Zapewnia to minimalny wpływ na ścieżkę danych.

• W przypadku korzystania z niestandardowych serwerów DNS z siecią wirtualną usługi Application Gateway ważne jest, aby wszystkie serwery są identyczne i odpowiadały spójnie z tymi samymi wartościami DNS.
• Użytkownicy lokalnych niestandardowych serwerów DNS muszą zapewnić łączność z usługą Azure DNS za pośrednictwem usługi Azure DNS Private Resolver (zalecane) lub maszyny wirtualnej usługi przesyłania dalej DNS w przypadku korzystania z strefy Prywatna strefa DNS dla prywatnego punktu końcowego.

Modyfikacje żądania

Usługa Application Gateway wstawia sześć dodatkowych nagłówków do wszystkich żądań, zanim przekaże żądania do zaplecza. Te nagłówki to x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url i x-appgw-trace-id. Format nagłówka x-forwarded-for to rozdzielona przecinkami lista adresów IP:port.

Prawidłowe wartości x-forwarded-proto to HTTP lub HTTPS. Port przekierowany X określa port, na którym żądanie dotarło do bramy aplikacji. Nagłówek X-original-host zawiera oryginalny nagłówek hosta, z którym dotarło żądanie. Ten nagłówek jest przydatny w integracji witryny internetowej platformy Azure, gdzie nagłówek hosta przychodzącego jest modyfikowany przed kierowaniem ruchu do zaplecza. Jeśli koligacja sesji jest włączona jako opcja, dodaje plik cookie koligacji zarządzanej przez bramę.

X-appgw-trace-id to unikatowy identyfikator GUID generowany przez bramę aplikacji dla każdego żądania klienta i przedstawiony w przesłanym dalej żądaniu do elementu członkowskiego puli zaplecza. Identyfikator GUID składa się z 32 znaków alfanumerycznych przedstawionych bez kreski (na przykład: ac882cd65a2712a0fe1289ec2bb6aee7). Ten identyfikator GUID może służyć do skorelowania żądania odebranego przez bramę aplikacji i zainicjowanego do elementu członkowskiego puli zaplecza za pośrednictwem właściwości transactionId w dziennikach diagnostycznych.

Bramę aplikacji można skonfigurować tak, aby modyfikowała nagłówki żądań i odpowiedzi oraz adres URL przy użyciu funkcji Ponowne zapisywanie nagłówków i adresów URL protokołu HTTP lub modyfikowanie ścieżki identyfikatora URI przy użyciu ustawienia zastąpienia ścieżki. Jednak jeśli nie zostanie to skonfigurowane, wszystkie żądania przychodzące są kierowane do zaplecza.

Kontynuuj