Udostępnij za pośrednictwem

Konfiguracja ustawień zaplecza usługi Application Gateway

Ustawienia zaplecza umożliwiają zarządzanie konfiguracjami połączeń zaplecza ustanowionych z zasobu bramy aplikacji do serwera w puli zaplecza. Konfiguracja ustawień zaplecza może być skojarzona z co najmniej jedną regułą routingu.

Typy ustawień zaplecza w usłudze Application Gateway

Użytkownicy portalu będą widzieć tylko opcję "Ustawienia zaplecza", ale użytkownicy interfejsu API będą mieli dostęp do dwóch typów ustawień. Zgodnie z protokołem należy użyć prawidłowej konfiguracji.

  • Ustawienia HTTP serwera bazowego — dotyczy konfiguracji serwera proxy warstwy 7, które obsługują protokoły HTTP i HTTPS.
  • Ustawienia zaplecza — dotyczy konfiguracji serwera proxy warstwy 4 (wersja zapoznawcza), które obsługują protokoły TLS i TCP.

Azure Application Gateway używa plików cookie zarządzanych przez bramę do utrzymania sesji użytkowników. Gdy użytkownik wysyła pierwsze żądanie do usługi Application Gateway, w odpowiedzi ustawiane jest ciasteczko sesyjne z wartością skrótu zawierającą szczegóły sesji. Ten proces umożliwia kolejne żądania, które zawierają ciasteczko affinacji, być kierowane do tego samego serwera zaplecza, co zapewnia utrzymanie 'przyczepnoś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ć plik cookie powiązania 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ądarkiChromium 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ć atrybutów SameSite=None; Secure i powinien być wysyłany tylko za pośrednictwem protokołu HTTPS. W przeciwnym razie, w scenariuszu, w którym używane jest tylko HTTP, przeglądarka nie wysyła plików cookie w kontekście zewnętrznego dostawcy. 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.

Domyślna nazwa pliku cookie koligacji to ApplicationGatewayAffinity i można ją zmienić. Jeśli w topologii sieci wdrożysz wiele bramek aplikacji w kolejności, musisz ustawić unikatowe nazwy cookie dla każdego zasobu. Jeśli używasz niestandardowej nazwy cookie skojarzeniowego, do tej nazwy zostanie dodany dodatkowy cookie z sufiksem CORS. Na przykład: CustomCookieNameCORS.

Uwaga

Jeśli atrybut SameSite=None jest ustawiony, wymagany jest również, aby plik cookie zawierał 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 komunikacji TLS od końca do końca dla usługi Application Gateway. Zobacz Omówienie protokołu SSL, Konfigurowanie bramy aplikacji z kończeniem protokołu TLS i Konfigurowanie kompleksowego protokołu TLS.

Opróżnianie połączeń

Opróżnianie połączeń pomaga bezpiecznie usuwać członków puli zaplecza podczas planowanych aktualizacji usługi. Dotyczy instancji zaplecza, które są jawnie usuwane z puli zaplecza.

Można zastosować to ustawienie do wszystkich członków puli zaplecza, włączając drenaż połączeń w ustawieniach zaplecza. Gwarantuje to, że wszystkie wyrejestrowujące się wystąpienia w puli zaplecza nie odbierają żadnych nowych żądań/połączeń, zachowując istniejące połączenia do upływu skonfigurowanego limitu czasu. Ten proces dotyczy 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 od tego procesu są żądania mające na celu wyrejestrowanie wystąpień z powodu powiązania sesji zarządzanego przez bramę. Te żądania nadal są przekazywane do wyrejestrowujących się wystąpień.

Uwaga

Istnieje ograniczenie polegające na tym, że aktualizacja konfiguracji zakończy trwające połączenia po przekroczeniu limitu czasu opróżniania połączenia. Aby rozwiązać ten problem, należy zwiększyć limit czasu opróżniania połączenia w ustawieniach zaplecza do wartości wyższej niż maksymalny oczekiwany czas pobierania klienta.

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

Podczas wybierania protokołu HTTPS w ustawieniach zaplecza zasób bramy aplikacji korzysta z domyślnego magazynu certyfikatów zaufanego głównego urzędu certyfikacji w celu zweryfikowania łańcucha i autentyczności certyfikatu dostarczonego przez serwer zaplecza.

Domyślnie zasób Application Gateway zawiera popularne certyfikaty CA, co umożliwia bezproblemowe połączenia TLS z zapleczem, gdy certyfikat serwera zaplecza jest wystawiany przez publiczny urząd certyfikacji. Jeśli jednak zamierzasz użyć prywatnego urzędu certyfikacji lub certyfikatu wygenerowanego samodzielnie, musisz podać odpowiedni certyfikat głównego urzędu certyfikacji (.cer) w tej konfiguracji ustawień zaplecza.

Przekroczono limit czasu żądania

Ustawienie to określa, ile sekund brama aplikacji czeka na odpowiedź od serwera zaplecza. Wartość domyślna to 20 sekund. Możesz jednak dostosować to ustawienie do potrzeb aplikacji.

Zastąp ścieżkę backendu

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łaniania ścieżki 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ę backendu Żądanie przekazane do zaplecza systemowego
    /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ę backendu Żądanie przekazane do zaplecza systemowego
    /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 przypiszesz jawnie niestandardowej sondy, do monitorowania kondycji systemu zaplecza zostanie użyta domyślna sonda. Zalecamy utworzenie niestandardowej sondy w celu zapewnienia lepszej kontroli nad monitorowaniem kondycji zapleczy.

Uwaga

Sonda niestandardowa nie monitoruje kondycji puli zaplecza, dopóki odpowiednie ustawienie HTTP nie zostanie jawnie przypisane do odbiornika.

Konfigurowanie nazwy hosta

Usługa Application Gateway umożliwia nawiązanie połączenia z zapleczem, używając 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ść przy zastępowaniu nazwy hosta, tak aby różniła się ona między bramą aplikacyjną a klientem a docelowym serwerem zaplecza.

W środowiskach produkcyjnych najlepszą praktyką jest użycie tej samej nazwy hosta dla połączenia klienta z bramą aplikacyjną oraz z bramą aplikacyjną do docelowego zaplecza. Ta praktyka pozwala 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 Architecture Center: Preserve the original HTTP host name between a reverse proxy and its backend web application (Zachowaj oryginalną nazwę hosta HTTP między zwrotnym serwerem proxy i 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 host w żądaniu na nazwę host 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 usługi wielodostępne działające 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 aplikacji 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 aplikacyjnej za pośrednictwem nazwy hosta, która nie jest jawnie zarejestrowana w usłudze App Service, lub za pośrednictwem nazwy FQDN bramy aplikacyjnej, możesz zastąpić nazwę hosta w oryginalnym żądaniu na nazwę 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, nie zaleca się włączania opcji 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 określono wartość w ustawieniu Nazwa hosta , oryginalne żądanie *https://appgw.eastus.cloudapp.azure.com/path1 zostanie zmienione na *https://www.contoso.com/path1 po przesłaniu żądania do serwera zaplecza.

Następne kroki