Konfiguracja ustawień PROTOKOŁU HTTP usługi Application Gateway
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 są kierowane 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.
Aktualizacja przeglądarki Chromium w wersji 80 wprowadziła mandat, w którym pliki cookie HTTP bez atrybutu SameSite muszą być traktowane jako SameSite=Lax. W przypadku żądań mechanizmu CORS (współużytkowania zasobów między źródłami), jeśli plik cookie musi zostać wysłany w kontekście innej firmy, musi używać polecenia SameSite=None; Bezpieczne atrybuty i powinny być wysyłane tylko za pośrednictwem protokołu HTTPS. W przeciwnym razie w scenariuszu tylko http przeglądarka nie wysyła plików cookie w kontekście innej firmy. Celem tej aktualizacji programu Chrome jest zwiększenie bezpieczeństwa i uniknięcie ataków csrF (Cross-Site Request Forgery).
Aby zapewnić obsługę tej zmiany, począwszy od 17 lutego 2020 r. usługa Application Gateway (wszystkie typy jednostek SKU) wstrzykuje kolejny plik cookie o nazwie ApplicationGatewayAffinityCORS oprócz istniejącego pliku cookie ApplicationGatewayAffinity . Plik cookie ApplicationGatewayAffinityCORS ma do niego jeszcze dwa atrybuty ("SameSite=None; Bezpieczne"), dzięki czemu sesje sticky są utrzymywane nawet w przypadku żądań między źródłami.
Pamiętaj, że domyślna nazwa pliku cookie koligacji to ApplicationGatewayAffinity i można ją zmienić. Jeśli w topologii sieci wdrożysz wiele bram aplikacji w wierszu, musisz ustawić unikatowe nazwy plików cookie dla każdego zasobu. Jeśli używasz niestandardowej nazwy pliku cookie koligacji, dodatkowy plik cookie zostanie dodany jako CORS sufiks. Na przykład: CustomCookieNameCORS.
Uwaga
Jeśli atrybut SameSite=None jest ustawiony, wymagany jest również, aby plik cookie zawierał również flagę Secure i musi zostać wysłany za pośrednictwem protokołu HTTPS. Jeśli koligacja sesji jest wymagana przez mechanizm CORS, należy przeprowadzić migrację obciążenia do protokołu HTTPS. Zapoznaj się z dokumentacją dotyczącą odciążania protokołu TLS i kompleksowej dokumentacji protokołu TLS dla usługi Application Gateway tutaj — omówienie, Konfigurowanie bramy aplikacji z kończeniem protokołu TLS przy użyciu witryny Azure Portal, Konfigurowanie kompleksowego protokołu TLS przy użyciu usługi Application Gateway z portalem.
Opróżnianie połączeń
Opróżnianie połączeń 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 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łączeń 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łączenia nie jest włączone w ustawieniu zaplecza | 30 sekund |
| Wartość zdefiniowana przez użytkownika, gdy opróżnianie połączenia jest włączone 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ę. Te żądania nadal są 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 używany przez pulę 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ąp ścieżkę zaplecza Żądanie przekazane do zaplecza /dom/ /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ąp ścieżkę zaplecza Żądanie przekazane do zaplecza /pathrule/home/ /pathrule* /Zastąpić/ /override/home/ /pathrule/home/secondhome/ /pathrule* /Zastąpić/ /override/home/secondhome/ /dom/ /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ść podczas zastępowania nazwy hosta, tak aby różniła się ona między bramą aplikacji a klientem w porównaniu z obiektem docelowym 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 a aplikacją internetową zaplecza
Istnieją dwa aspekty ustawienia HTTP, które wpływają na Host nagłówek HTTP 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ładowe przypadki to usługi wielodostępne 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.
Uwaga
To ustawienie nie jest wymagane w przypadku środowiska App Service Environment, które jest dedykowanym wdrożeniem.
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 * zostanie zmienione na *https://appgw.eastus.cloudapp.azure.com/path1https://www.contoso.com/path1 po przesłaniu żądania do serwera zaplecza.