Jak działa usługa Azure Application Gateway
Usługa Azure Application Gateway zawiera szereg składników łączących się w celu bezpiecznego kierowania i równoważenia obciążenia żądań w puli serwerów internetowych. Usługa Application Gateway zawiera następujące składniki:
- Front-end IP address: Żądania klientów są odbierane poprzez adres IP front-end. Usługę Application Gateway można skonfigurować tak, aby miała publiczny adres IP, prywatny adres IP lub oba te elementy. Usługa Application Gateway nie może mieć więcej niż jednego publicznego adresu IP i jednego prywatnego adresu IP.
- Nasłuchiwacze: usługa Application Gateway używa jednego lub więcej nasłuchiwaczy do odbierania żądań napływających. Odbiornik akceptuje ruch przychodzący na określoną kombinację protokołu, portu, hosta i adresu IP. Każdy odbiornik kieruje żądania do puli zaplecza serwerów zgodnie z określonymi regułami routingu. Słuchacz może być Podstawowy lub Wielolokalizacyjny. Odbiornik Basic kieruje żądanie tylko na podstawie ścieżki w adresie URL. Odbiornik wielowitrynowy może również kierować żądania przy użyciu elementu nazwy hosta w adresie URL. Odbiorniki obsługują również certyfikaty TLS/SSL na potrzeby zabezpieczania aplikacji między użytkownikiem i usługą Application Gateway.
- reguły routingu: reguła routingu wiąże odbiornik z pulami zaplecza. Reguła określa, jak interpretować nazwę hosta i elementy ścieżki w adresie URL żądania i kierować żądanie do odpowiedniej puli zaplecza. Reguła routingu ma również skojarzony zestaw ustawień HTTP. Te ustawienia PROTOKOŁU HTTP wskazują, czy ruch (i jak) jest szyfrowany między usługą Application Gateway i serwerami zaplecza. Inne informacje o konfiguracji obejmują protokół, trwałość sesji, opróżnianie połączenia, okres przekroczenia limitu czasu żądania i sondy kondycji.
Równoważenie obciążenia w usłudze Application Gateway
Usługa Application Gateway automatycznie równoważy obciążenie żądań wysyłanych do serwerów w każdej puli zaplecza przy użyciu mechanizmu działania okrężnego. Równoważenie obciążenia działa z routingiem warstwy OSI 7 zaimplementowanym przez routing usługi Application Gateway, co oznacza, że równoważy obciążenia żądań na podstawie parametrów routingu (nazw hostów i ścieżek) używanych przez reguły usługi Application Gateway. Dla porównania inne równoważniki obciążenia, takie jak Azure Load Balancer, działają na poziomie warstwy 4 modelu OSI i dystrybuują ruch na podstawie adresu IP docelowego żądania.
Można skonfigurować trwałość sesji, jeśli musisz upewnić się, że wszystkie żądania klienta w tej samej sesji są kierowane do tego samego serwera w puli zaplecza.
Zapora aplikacji internetowej
Zapora aplikacji internetowej (WAF) jest opcjonalnym składnikiem, który obsługuje żądania przychodzące przed dotarciem do odbiornika. Zapora aplikacji internetowej sprawdza każde żądanie pod kątem wielu typowych zagrożeń w oparciu o projekt Open Web Application Security Project (OWASP). Typowe zagrożenia obejmują: wstrzyknięcie kodu SQL, wykonywanie skryptów między witrynami, wstrzyknięcie poleceń, przemyt żądań HTTP, dzielenie odpowiedzi HTTP, dołączanie plików zdalnych, boty, przeszukiwarki i skanery oraz naruszenia i anomalie protokołu HTTP.
Program OWASP definiuje zestaw ogólnych reguł wykrywania ataków. Te reguły są określane jako podstawowy zestaw reguł (CRS). Zestawy reguł są w ciągłym przeglądzie, gdy ataki ewoluują w wyrafinowaniu. WAF obsługuje cztery zestawy reguł: CRS 3.2, 3.1, 3.0 i 2.2.9. CrS 3.1 jest wartością domyślną. W razie potrzeby możesz zdecydować się na wybranie tylko określonych reguł w zestawie reguł, ukierunkowanie na określone zagrożenia. Ponadto można dostosować zaporę, aby określić, które elementy w żądaniu mają być sprawdzane, i ograniczyć rozmiar komunikatów, aby zapobiec przeciążeniu serwerów przez masowe przekazywanie.
Zasoby zaplecza
Pula zaplecza to kolekcja serwerów internetowych, które mogą składać się z: stałego zestawu maszyn wirtualnych, zestawu skalowania maszyn wirtualnych, aplikacji hostowanej przez usługi Azure App Services lub kolekcji serwerów lokalnych.
Każda pula serwerów zaplecza ma skojarzone narzędzie równoważenia obciążenia, które dystrybuuje pracę wewnątrz puli. Podczas konfigurowania puli należy podać adres IP lub nazwę każdego serwera internetowego. Wszystkie serwery w puli zaplecza powinny być skonfigurowane w taki sam sposób, w tym ich ustawienia zabezpieczeń.
Jeśli używasz protokołu TLS/SSL, pula zaplecza ma ustawienie HTTP odwołujące się do certyfikatu używanego do uwierzytelniania serwerów zaplecza. Brama sieciowa ponownie szyfruje ruch przy użyciu tego certyfikatu przed wysłaniem go do jednego z serwerów w puli back-end.
Jeśli używasz usługi Azure App Service do hostowania aplikacji zaplecza, nie musisz instalować żadnych certyfikatów w usłudze Application Gateway, aby nawiązać połączenie z pulą zaplecza. Cała komunikacja jest automatycznie szyfrowana. Usługa Application Gateway ufa serwerom, ponieważ platforma Azure zarządza nimi.
Usługa Application Gateway używa reguły do określania sposobu kierowania komunikatów odbieranych na porcie przychodzącym do serwerów w puli zaplecza. Jeśli serwery korzystają z protokołu TLS/SSL, należy skonfigurować regułę tak, aby wskazywała:
- Że serwery oczekują ruchu za pośrednictwem protokołu HTTPS.
- Który certyfikat używany do szyfrowania ruchu i uwierzytelniania połączenia z serwerem.
Routing usługi Application Gateway
Gdy brama kieruje żądanie klienta do serwera internetowego w puli zaplecza, używa zestawu reguł skonfigurowanych dla bramy w celu określenia, dokąd powinno zostać skierowane żądanie. Istnieją dwie podstawowe metody routingu ruchu żądań klienta: routing oparty na ścieżkach i routing wielu lokacji.
Routing oparty na ścieżkach
Routing oparty na ścieżkach wysyła żądania z różnymi ścieżkami adresów URL do różnych pul serwerów zaplecza. Można na przykład kierować żądania ze ścieżką /video/* do puli zaplecza zawierającej serwery zoptymalizowane pod kątem obsługi przesyłania strumieniowego wideo i kierować żądania /images/* do puli serwerów obsługujących pobieranie obrazów.
Routing między wieloma lokalizacjami
Konfigurowanie trasowania dla wielu witryn umożliwia uruchamianie więcej niż jednej aplikacji webowej na tym samym wystąpieniu usługi Application Gateway. W konfiguracji obejmującej wiele lokacji należy zarejestrować wiele nazw DNS (CNAM) dla adresu IP bramy aplikacji, określając nazwę każdej lokacji. Application Gateway używa oddzielnych odbiorników, aby czekać na żądania dla każdej witryny. Każdy słuchacz przekazuje żądanie do innej reguły, która może kierować żądania do serwerów w innej puli zaplecza. Można na przykład kierować wszystkie żądania dotyczące http://contoso.com do serwerów w jednej puli zaplecza i żądania dotyczące http://fabrikam.com do innej puli zaplecza. Na poniższym diagramie przedstawiono tę konfigurację:
Konfiguracje wielomiejscowe są przydatne do obsługi aplikacji wielodostępnych, w których każdy najemca ma własny zestaw maszyn wirtualnych lub inne zasoby hostujące aplikację internetową.
Routing usługi Application Gateway obejmuje również następujące funkcje:
- przekierowanie. Przekierowanie może służyć do innej witryny lub z protokołu HTTP do protokołu HTTPS.
- Przepisywanie nagłówków HTTP. Nagłówki HTTP umożliwiają klientowi i serwerowi przekazywanie informacji o parametrach za pomocą żądania lub odpowiedzi.
- niestandardowe strony błędów. Usługa Application Gateway umożliwia tworzenie niestandardowych stron błędów zamiast wyświetlania domyślnych stron błędów. Możesz użyć własnego znakowania firmowego i układu za pomocą niestandardowej strony błędu.
Terminacja TLS/SSL
Kiedy kończysz połączenie TLS/SSL na bramie aplikacji, zdejmuje to z serwerów zadanie intensywnego wykorzystania CPU związane z zakończeniem TLS/SSL. Ponadto nie trzeba instalować certyfikatów i konfigurować protokołu TLS/SSL na serwerach.
Jeśli potrzebujesz szyfrowania end-to-end, usługa Application Gateway może odszyfrować ruch w bramie przy użyciu twojego klucza prywatnego, a następnie ponownie zaszyfrować go kluczem publicznym usługi uruchomionej w puli zaplecza.
Ruch wchodzi do bramy poprzez port front-endowy. Możesz otworzyć wiele portów, a usługa Application Gateway może odbierać komunikaty na dowolnym z tych portów. Listener jest pierwszą rzeczą, którą ruch napotyka przy wjeździe do bramy przez port. Odbiornik jest skonfigurowany do nasłuchiwania określonej nazwy hosta i określonego portu na określonym adresie IP. Odbiornik może użyć certyfikatu TLS/SSL, aby odszyfrować ruch, który wchodzi do bramy. Następnie odbiornik używa zdefiniowanej przez Ciebie reguły, aby kierować przychodzące żądania do puli serwerów zaplecza.
Uwidacznianie witryny internetowej lub aplikacji internetowej za pośrednictwem bramy aplikacji oznacza również, że serwery nie są bezpośrednio połączone z siecią Web. Udostępniasz tylko port 80 lub port 443 na bramce aplikacyjnej, który jest następnie przekazywany do serwera zaplecza. W tej konfiguracji serwery internetowe nie są bezpośrednio dostępne z Internetu, co zmniejsza obszar ataków infrastruktury.
Sondy kondycji
Sondy kondycji określają, które serwery są dostępne do równoważenia obciążenia w puli zaplecza. Usługa Application Gateway używa sondy kondycji do wysyłania żądania do serwera. Gdy serwer zwraca odpowiedź HTTP z kodem stanu z zakresu od 200 do 399, serwer jest uznawany za w dobrej kondycji. Jeśli nie skonfigurujesz sondy kondycji, usługa Application Gateway utworzy domyślną sondę, która czeka przez 30 sekund przed podjęciem decyzji, że serwer jest niedostępny. Sondy kondycji zapewniają, że ruch nie jest kierowany do nieodpowiadającego lub nieudanego punktu końcowego sieci w puli zapasowej.
Skalowanie automatyczne
Usługa Application Gateway obsługuje skalowanie automatyczne i może skalować w górę lub w dół na podstawie zmieniających się wzorców obciążenia ruchu. Skalowanie automatyczne eliminuje również wymaganie wybrania rozmiaru wdrożenia lub liczby wystąpień podczas aprowizacji.
Ruch WebSocket i HTTP/2
Usługa Application Gateway zapewnia natywną obsługę protokołów WebSocket i HTTP/2. Protokoły WebSocket i HTTP/2 umożliwiają pełną komunikację dwukierunkową między serwerem a klientem przez długotrwałe połączenie TCP. Ten typ komunikacji jest bardziej interaktywny między serwerem internetowym a klientem i może być dwukierunkowy bez konieczności sondowania zgodnie z wymaganiami w implementacjach opartych na protokole HTTP. Te protokoły mają niskie obciążenie (w przeciwieństwie do protokołu HTTP) i mogą ponownie używać tego samego połączenia TCP dla wielu żądań/odpowiedzi, co skutkuje bardziej wydajnym wykorzystaniem zasobów. Te protokoły są przeznaczone do pracy nad tradycyjnymi portami HTTP 80 i 443.