Jak działa brama aplikacji
W tym artykule wyjaśniono, jak brama aplikacji akceptuje żądania przychodzące i kieruje je do zaplecza.
Jak brama aplikacji akceptuje żądanie
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.
Usługa Azure DNS zwraca adres IP do klienta, czyli adres IP frontonu bramy aplikacji.
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.
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.
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 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.
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.
Uwaga
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.
Ważne
- W przypadku używania niestandardowych serwerów DNS z siecią wirtualną usługi Application Gateway ważne jest, aby wszystkie serwery odpowiadały spójnie z tymi samymi wartościami DNS. Gdy wystąpienie usługi Application Gateway wystawia zapytanie DNS, używa wartości z serwera, który odpowiada jako pierwszy.
- 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.