Często zadawane pytania dotyczące usługi Application Gateway

aplikacja systemu Azure Gateway udostępnia kontroler dostarczania aplikacji jako usługę. Oferuje ona różne funkcje równoważenia obciążenia warstwy 7 dla aplikacji. Ta usługa jest wysoce dostępna, skalowalna i w pełni zarządzana przez platformę Azure.

Usługa Application Gateway obsługuje skalowanie automatyczne, odciążanie protokołu TLS i kompleksowe protokoły TLS, zaporę aplikacji internetowej (WAF), koligację sesji opartą na plikach cookie, routing oparty na ścieżkach URL, hosting w wielu lokacjach i inne funkcje. Aby uzyskać pełną listę obsługiwanych funkcji, zobacz Wprowadzenie do usługi Application Gateway.

Usługa Application Gateway to moduł równoważenia obciążenia warstwy 7, co oznacza, że działa tylko z ruchem internetowym (HTTP, HTTPS, WebSocket i HTTP/2). Obsługuje ona funkcje, takie jak kończenie żądań protokołu TLS, koligacja sesji oparte na plikach cookie i działanie okrężne dla ruchu równoważenia obciążenia. Moduł równoważenia obciążenia równoważy ruch w warstwie 4 (TCP lub UDP).

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

Zobacz Obsługa protokołu HTTP/2.

Zobacz Obsługiwane zasoby zaplecza.

Usługa Application Gateway w wersji 1 (Standardowa i zapora aplikacji internetowej) jest dostępna we wszystkich regionach globalnej platformy Azure. Jest ona również dostępna na platformie Microsoft Azure obsługiwanej przez firmę 21Vianet i platformę Azure Government.

Aby uzyskać informacje o dostępności usługi Application Gateway w wersji 2 (Standard_v2 i WAF_v2), zobacz Obsługiwane regiony dla usługi Application Gateway w wersji 2.

Usługa Application Gateway to dedykowane wdrożenie w sieci wirtualnej.

Przekierowanie jest obsługiwane. Zobacz Omówienie przekierowania usługi Application Gateway.

Zobacz kolejność przetwarzania odbiornika.

Jeśli używasz publicznego adresu IP jako punktu końcowego, informacje o adresie IP i systemie DNS znajdują się w zasobie publicznego adresu IP. Możesz go również znaleźć w witrynie Azure Portal na stronie przeglądu bramy aplikacji. Jeśli używasz wewnętrznych adresów IP, znajdź informacje na stronie przeglądu. W przypadku jednostki SKU w wersji 1 bram utworzonych po 1 maja 2023 r. domyślna nazwa DNS nie będzie automatycznie skojarzona z zasobem publicznego adresu IP. W przypadku jednostki SKU w wersji 2 otwórz zasób publicznego adresu IP i wybierz pozycję Konfiguracja. Pole Etykieta nazwy DNS (opcjonalnie) jest dostępne do skonfigurowania nazwy DNS.

Keep-Alive Limit czasu określa, jak długo brama aplikacji oczekuje na wysłanie przez klienta innego żądania HTTP na trwałe połączenie przed ponownym użyciem lub zamknięciem. Limit czasu bezczynności protokołu TCP określa, jak długo połączenie TCP jest otwarte, jeśli nie ma żadnych działań.

W przypadku połączeń Keep-Alive HTTP/1.1 limit czasu w jednostce SKU usługi Application Gateway w wersji 1 i w wersji 2 wynosi 120 sekund. W przypadku prywatnych adresów IP wartość jest nieskonfigurowalna z limitem czasu bezczynności protokołu TCP przez 5 minut. Limit czasu bezczynności protokołu TCP to 4-minutowa wartość domyślna dla wirtualnego adresu IP frontonu (VIP) jednostki SKU usługi Application Gateway w wersji 1 i 2. Wartość limitu czasu bezczynności protokołu TCP można skonfigurować w wystąpieniach usługi Application Gateway w wersji 1 i 2, aby wynosiła od 4 minut do 30 minut. W przypadku wystąpień usługi Application Gateway w wersji 1 i 2 należy przejść do publicznego adresu IP bramy aplikacji i zmienić limit czasu bezczynności PROTOKOŁU TCP w okienku Konfiguracja publicznego adresu IP w portalu. Wartość limitu czasu bezczynności protokołu TCP dla publicznego adresu IP można ustawić za pomocą programu PowerShell, uruchamiając następujące polecenia:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

W przypadku połączeń HTTP/2 z adresem IP frontonu w jednostce SKU usługi Application Gateway w wersji 2 limit czasu bezczynności jest ustawiony na 180 sekund i jest niekonfigurowalny.

Aby zapobiec konfliktowi i nieoczekiwanemu zachowaniu, upewnij się, że limit czasu bezczynności protokołu TCP jest taki sam jak lub dłuższy niż limit czasu utrzymania aktywności.

Tak. Usługa Application Gateway ponownie używa istniejących połączeń TCP z serwerem zaplecza.

L.p. Nie ma możliwości zmiany nazwy zasobu usługi Application Gateway. Musisz utworzyć nowy zasób o innej nazwie.

L.p. Nie ma możliwości przywrócenia zasobu usługi Application Gateway lub jego publicznego adresu IP po usunięciu. Musisz utworzyć nowy zasób.

W przypadku jednostki SKU usługi Application Gateway w wersji 1 adres VIP może ulec zmianie po zatrzymaniu i uruchomieniu bramy aplikacji. Jednak nazwa DNS skojarzona z bramą aplikacji nie zmienia się w okresie istnienia bramy. Ponieważ nazwa DNS nie zmienia się, należy użyć aliasu CNAME i wskazać go na adres DNS bramy aplikacji. W przypadku jednostki SKU usługi Application Gateway w wersji 2 adresy IP są statyczne, więc adresy IP i nazwa DNS nie zmienią się w okresie istnienia bramy aplikacji.

Tak. Jednostka SKU usługi Application Gateway w wersji 2 obsługuje statyczne publiczne adresy IP i statyczne wewnętrzne adresy IP. Jednostka SKU w wersji 1 obsługuje statyczne wewnętrzne adresy IP.

Brama aplikacji obsługuje tylko jeden publiczny adres IP na protokół IP. Jeśli brama aplikacji jest skonfigurowana jako DualStack, może obsługiwać dwa publiczne adresy IP, jeden dla protokołu IPv4 i jeden dla protokołu IPv6.

Zobacz Zagadnienia dotyczące rozmiaru podsieci usługi Application Gateway.

Tak. Oprócz wielu wystąpień danego wdrożenia usługi Application Gateway można aprowizować inny unikatowy zasób usługi Application Gateway do istniejącej podsieci zawierającej inny zasób usługi Application Gateway.

Pojedyncza podsieć nie może obsługiwać jednostek SKU usługi Application Gateway w wersji 2 i 1.

Tak, ale tylko określone scenariusze. Aby uzyskać więcej informacji, zobacz Konfiguracja infrastruktury usługi Application Gateway.

Tak. Zobacz Modyfikacje żądania.

Aprowizowania nowych wdrożeń jednostki SKU usługi Application Gateway w wersji 1 może potrwać do 20 minut. Zmiany rozmiaru lub liczby wystąpień nie są zakłócające, a brama pozostaje aktywna w tym czasie.

Aprowizacja większości wdrożeń korzystających z jednostki SKU w wersji 2 trwa około 6 minut. Jednak proces może trwać dłużej w zależności od typu wdrożenia. Na przykład wdrożenia w wielu strefach dostępności z wieloma wystąpieniami mogą potrwać ponad 6 minut.

Aktualizacje inicjowane w usłudze Application Gateway są stosowane w jednej domenie aktualizacji jednocześnie. W miarę aktualizowania wystąpień każdej domeny aktualizacji pozostałe wystąpienia w innych domenach aktualizacji nadal obsługują ruch¹. Aktywne połączenia są bezpiecznie opróżniane z wystąpień aktualizowanych przez maksymalnie 5 minut, aby ułatwić nawiązanie łączności z wystąpieniami w innej domenie aktualizacji przed rozpoczęciem aktualizacji. Podczas aktualizacji usługa Application Gateway tymczasowo działa z ograniczoną maksymalną pojemnością, która jest określana przez liczbę skonfigurowanych wystąpień. Proces aktualizacji przechodzi do następnego zestawu wystąpień tylko wtedy, gdy bieżący zestaw wystąpień został pomyślnie uaktualniony.

¹ Zalecamy skonfigurowanie minimalnej liczby wystąpień 2 dla wdrożeń jednostki SKU usługi Application Gateway w wersji 1 w celu zapewnienia, że co najmniej jedno wystąpienie może obsługiwać ruch podczas stosowania aktualizacji.

Usługa Application Gateway obsługuje serwer proxy protokołu TLS/TCP za pośrednictwem serwera proxy warstwy 4 w wersji zapoznawczej.

Serwer proxy warstwy 7 usługi Application Gateway z protokołami HTTP(S) nie będzie obsługiwał protokołów poczty e-mail, takich jak SMTP, IMAP i POP3. Jednak w przypadku niektórych pomocniczych usług poczty e-mail, takich jak Outlook Web Access (OWA), ActiveSync i ruch wykrywania automatycznego korzystający z protokołów HTTP(S), można użyć serwera proxy warstwy 7, a ich ruch powinien przepływać. (Uwaga: wykluczenia w regułach zapory aplikacji internetowej mogą być wymagane w przypadku korzystania z jednostki SKU zapory aplikacji internetowej).

Tak. Aby uzyskać więcej informacji, zobacz Migrate aplikacja systemu Azure Gateway and Web Application Firewall from v1 to v2 (Migrowanie bramy aplikacja systemu Azure i zapory aplikacji internetowej z wersji 1 do wersji 2).

Tak. Jednostka SKU usługi Application Gateway w wersji 1 jest nadal obsługiwana. Zdecydowanie zalecamy przejście do wersji 2, aby skorzystać z aktualizacji funkcji w tej jednostce SKU. Aby uzyskać więcej informacji na temat różnic między funkcjami w wersji 1 i 2, zobacz Autoskalowanie i strefowo nadmiarowa usługa Application Gateway w wersji 2. Wdrożenia jednostki SKU usługi Application Gateway w wersji 1 można migrować ręcznie do wersji 2, postępując zgodnie z naszym dokumentem migracji v1-v2.

L.p. Usługa Application Gateway w wersji 2 nie obsługuje żądań proxy z uwierzytelnianiem NTLM lub Kerberos.

Nazwy nagłówków żądania mogą zawierać znaki alfanumeryczne i łączniki. Nazwy nagłówków żądań, które zawierają inne znaki, są odrzucane, gdy żądanie jest wysyłane do obiektu docelowego zaplecza. Nazwy nagłówków odpowiedzi mogą zawierać dowolne znaki alfanumeryczne i określone symbole zgodnie z definicją w dokumencie RFC 7230.

Tak. Aktualizacja przeglądarki Chromium w wersji 80 wprowadziła mandat dotyczący plików cookie HTTP bez atrybutu SameSite, który ma być traktowany jako .SameSite=Lax Oznacza to, że plik cookie koligacji usługi Application Gateway nie zostanie wysłany przez przeglądarkę w kontekście innej firmy.

W celu obsługi tego scenariusza usługa Application Gateway wprowadza inny plik cookie o nazwie ApplicationGatewayAffinityCORS oprócz istniejącego ApplicationGatewayAffinity pliku cookie. Te pliki cookie są podobne, ale ApplicationGatewayAffinityCORS plik cookie ma do niego jeszcze dwa atrybuty: SameSite=None i Secure. Te atrybuty utrzymują trwałe sesje nawet w przypadku żądań między źródłami. Aby uzyskać więcej informacji, zobacz sekcję Koligacja oparta na plikach cookie.

Aktywny odbiornik to odbiornik skojarzony z regułą i wysyłający ruch do puli zaplecza. Każdy odbiornik, który przekierowuje tylko ruch, nie jest aktywnym odbiornikiem. Odbiorniki skojarzone z regułami przekierowania nie są traktowane jako aktywne. Jeśli reguła przekierowania jest regułą opartą na ścieżkach, wszystkie ścieżki w tej regule przekierowania muszą być przekierowywane lub odbiornik jest uznawany za aktywny. Aby uzyskać szczegółowe informacje na temat limitu poszczególnych składników, zobacz Limity, limity przydziału i ograniczenia subskrypcji i usług platformy Azure.

Jednostka SKU usługi Application Gateway w wersji 1 obsługuje scenariusze wysokiej dostępności po wdrożeniu co najmniej dwóch wystąpień. Platforma Azure dystrybuuje te wystąpienia między domenami aktualizacji i błędów, aby upewnić się, że wystąpienia nie wszystkie kończą się niepowodzeniem w tym samym czasie. Jednostka SKU w wersji 1 obsługuje skalowalność przez dodanie wielu wystąpień tej samej bramy w celu współużytkowania obciążenia.

Jednostka SKU w wersji 2 automatycznie zapewnia, że nowe wystąpienia są rozmieszczone w domenach błędów i domenach aktualizacji. W przypadku wybrania nadmiarowości strefy najnowsze wystąpienia są również rozmieszczone w różnych strefach dostępności, aby zapewnić odporność na awarie strefowe.

Usługa Azure Traffic Manager umożliwia dystrybucję ruchu między wieloma bramami aplikacji w różnych centrach danych.

Tak. Możesz skonfigurować opróżnianie połączeń, aby zmienić elementy członkowskie w puli zaplecza bez zakłóceń. Aby uzyskać więcej informacji, zobacz sekcję Opróżnianie połączenia w usłudze Application Gateway.

Tak, jednostka SKU usługi Application Gateway w wersji 2 obsługuje skalowanie automatyczne. Aby uzyskać więcej informacji, zobacz Autoskalowanie i strefowo nadmiarowa usługa Application Gateway.

L.p. Wystąpienia są dystrybuowane między domenami uaktualniania i domenami błędów.

Tak.

Tak.

Tak. Usługa Application Gateway jest zawsze wdrażana w podsieci sieci wirtualnej. Ta podsieć może zawierać tylko bramy aplikacji. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące sieci wirtualnej i podsieci.

Jeśli masz łączność z protokołem IP, usługa Application Gateway może komunikować się z wystąpieniami spoza sieci wirtualnej, w której się znajduje. Usługa Application Gateway może również komunikować się z wystąpieniami spoza subskrypcji, w których się znajduje. Jeśli planujesz używać wewnętrznych adresów IP jako elementów członkowskich puli zaplecza, użyj komunikacji równorzędnej sieci wirtualnych lub usługi Azure VPN Gateway.

Podobnie jak w przypadku każdego rozpoznawania nazw DNS zasób usługi Application Gateway honoruje wartość Time to Live (TTL) rekordu DNS serwera zaplecza. Po wygaśnięciu czasu wygaśnięcia brama wykonuje wyszukiwanie w celu zaktualizowania tych informacji DNS. Podczas tego wyszukiwania, jeśli brama aplikacji napotka problem z uzyskaniem odpowiedzi (lub nie znaleziono żadnego rekordu DNS), brama będzie nadal używać ostatniej znanej dobrej wartości DNS do obsługi ruchu. Aby uzyskać więcej informacji, zobacz Jak działa brama aplikacji.

Wystąpienia bramy aplikacji używają konfiguracji DNS sieci wirtualnej do rozpoznawania nazw. Po zmianie dowolnej konfiguracji serwera DNS należy ponownie uruchomić (zatrzymać i uruchomić) bramę aplikacji dla nowych serwerów DNS, aby uzyskać przypisanie. Do tego czasu rozwiązania nazw oparte na nazwie FQDN dla łączności wychodzącej mogą zakończyć się niepowodzeniem.

L.p. Można jednak wdrożyć inne bramy aplikacji w podsieci.

Bramę aplikacji można przenieść między podsieciami tylko w tej samej sieci wirtualnej. Jest obsługiwana w wersji 1 z publicznym i prywatnym frontonem (alokacja dynamiczna) i wersją 2 tylko z publicznym frontonem. Nie można przenieść bramy aplikacji do innej podsieci, jeśli konfiguracja prywatnego adresu IP frontonu jest przydzielana statycznie. Aby wykonać tę akcję, brama aplikacji powinna być w stanie Zatrzymano . Zatrzymywanie lub uruchamianie wersji 1 zmienia publiczny adres IP. Tę operację można wykonać tylko przy użyciu programu Azure PowerShell i interfejsu wiersza polecenia platformy Azure, uruchamiając następujące polecenia:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Aby uzyskać więcej informacji, zobacz Set-AzApplicationGatewayIPConfiguration.

Interfejs wiersza polecenia platformy Azure

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Zobacz Sieciowe grupy zabezpieczeń w podsieci usługi Application Gateway.

Zobacz Trasy zdefiniowane przez użytkownika obsługiwane w podsieci usługi Application Gateway.

L.p. Zasady punktu końcowego usługi dla kont magazynu nie są obsługiwane w podsieci usługi Application Gateway i konfigurowaniu go blokuje ruch infrastruktury platformy Azure.

Zobacz Limity usługi Application Gateway.

Tak. Usługa Application Gateway obsługuje jeden wewnętrzny adres IP i jeden zewnętrzny adres IP na bramę aplikacji.

Tak. Komunikacja równorzędna sieci wirtualnych ułatwia równoważenie obciążenia ruchu w innych sieciach wirtualnych.

Tak, o ile ruch jest dozwolony.

Architektura mikrousług jest obsługiwana. Aby sondować na różnych portach, należy skonfigurować wiele ustawień zaplecza.

L.p.

Zobacz Kolejność reguł przetwarzania.

Pole Host określa nazwę, do której ma być wysyłana sonda, gdy skonfigurowano wiele lokacji w usłudze Application Gateway. W przeciwnym razie użyj wartości 127.0.0.1. Ta wartość różni się od nazwy hosta maszyny wirtualnej. Jego format to <protocol>://<host>:<port><path>.

Tak. Zobacz Ograniczanie dostępu do określonych źródłowych adresów IP.

Tak, można używać odbiorników publicznych i prywatnych z tym samym numerem portu, aby jednocześnie obsługiwać klientów publicznych i prywatnych. Jeśli sieciowa grupa zabezpieczeń jest skojarzona z podsiecią bramy aplikacji, może być potrzebna określona reguła ruchu przychodzącego w zależności od jego konfiguracji. Dowiedz się więcej.

Usługa Application Gateway w wersji 2 obsługuje frontony IPv4 i IPv6. Obecnie obsługa protokołu IPv6 jest dostępna tylko dla nowych bram aplikacji. Aby obsługiwać protokół IPv6, sieć wirtualna powinna być podwójnym stosem. Usługa Application Gateway w wersji 1 nie obsługuje sieci wirtualnych z podwójnym stosem.

Jednostki SKU usługi Application Gateway w wersji 1 mogą działać w trybie zatwierdzonym przez standard FIPS 140–2, który jest często określany jako "tryb FIPS". Tryb FIPS wywołuje zweryfikowany moduł kryptograficzny FIPS 140-2, który zapewnia zgodne ze standardem FIPS algorytmy szyfrowania, tworzenia skrótów i podpisywania po włączeniu. Aby upewnić się, że tryb FIPS jest włączony, FIPSMode należy skonfigurować ustawienie za pomocą programu PowerShell, szablonu usługi Azure Resource Manager lub interfejsu API REST po zarejestrowaniu subskrypcji w celu włączenia FIPSmodekonfiguracji programu .

Uwaga: W ramach zgodności FedRAMP rząd USA nakazuje, aby systemy działały w trybie zatwierdzonym przez fiPS po sierpniu 2024 r.

Kroki włączania trybu FIPS w jednostce SKU w wersji 1:

Krok 1. Rejestrowanie funkcji "AllowApplicationGatewayEnableFIPS" w celu zarejestrowania subskrypcji na potrzeby konfiguracji trybu FIPS.

Aby zarejestrować się przy użyciu programu Azure PowerShell, otwórz monit usługi Cloud Shell i wprowadź następujące polecenie:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Aby zarejestrować się w witrynie Azure Portal:

• Zaloguj się do witryny Azure Portal i wyszukaj funkcje w wersji zapoznawczej.
• Wprowadź wartość AllowApplicationGatewayEnableFIPS w polu filtru. Wybierz pozycję Application Gateway v1 Zezwalaj na tryb FIPS, a następnie wybierz pozycję Zarejestruj.

Krok 2. Ustaw właściwość enableFips na true przy użyciu programu PowerShell, szablonu usługi Azure Resource Manager lub interfejsu API REST.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

Zmiana trybu FIPS nie wpływa na ogólną dostępność zestawów szyfrowania w bramach w wersji 1. Jednak w przypadku korzystania z kryptografii krzywej eliptycznej dla szyfrów, z wyłączonym trybem FIPS można użyć krzywej 25519, NistP256 i NistP384, podczas gdy z włączonym trybem FIPS tylko NistP256 i NistP384 są dozwolone, a krzywa25519 jest wyłączona. Ponieważ krzywa 25519 staje się niedostępna w trybie FIPS, upewnij się, że klienci obsługują protokół NistP256 lub NistP384 w celu zapewnienia bezpiecznej komunikacji przed włączeniem protokołu FIPS.

Usługa Application Gateway w wersji 2 obecnie obsługuje konfigurację frontonu prywatnego adresu IP (bez publicznego adresu IP) za pośrednictwem publicznej wersji zapoznawczej. Aby uzyskać więcej informacji, zobacz Wdrażanie usługi Private Application Gateway (wersja zapoznawcza).

W przypadku bieżącej ogólnej obsługi dostępności usługa Application Gateway w wersji 2 obsługuje następujące kombinacje:

• Prywatny adres IP i publiczny adres IP
• Tylko publiczny adres IP

Aby ograniczyć ruch tylko do prywatnych adresów IP z bieżącą funkcjonalnością, wykonaj następujący proces:

1. Utwórz bramę aplikacji z publicznym i prywatnym adresem IP frontonu.

2. Nie twórz żadnych odbiorników dla publicznego adresu IP frontonu. Usługa Application Gateway nie będzie nasłuchiwać żadnego ruchu na publicznym adresie IP, jeśli nie zostaną dla niego utworzone żadne odbiorniki.

3. Utwórz i dołącz sieciową grupę zabezpieczeń dla podsieci usługi Application Gateway z następującą konfiguracją w kolejności priorytetu:

   1. Zezwalaj na ruch ze źródła jako tag usługi GatewayManager, Destination as Any i port docelowy jako 65200-65535. Ten zakres portów jest wymagany do komunikacji infrastruktury platformy Azure. Te porty są chronione (zablokowane) przez uwierzytelnianie certyfikatu. Jednostki zewnętrzne, w tym administratorzy użytkowników bramy, nie mogą inicjować zmian w tych punktach końcowych bez odpowiednich certyfikatów.

   2. Zezwalaj na ruch ze źródła jako tag usługi AzureLoadBalancer i port docelowy jako dowolny.

   3. Odmów całego ruchu przychodzącego ze źródła jako tag usługi Internet i port docelowy jako dowolny. Nadaj tej regule najmniejszy priorytet w regułach ruchu przychodzącego.

   4. Zachowaj reguły domyślne, takie jak AllowVNetInBound , aby dostęp na prywatnym adresie IP nie był blokowany.

   5. Nie można zablokować wychodzącej łączności z Internetem. W przeciwnym razie występują problemy z rejestrowaniem i metrykami.

Przykładowa konfiguracja sieciowej grupy zabezpieczeń na potrzeby dostępu tylko do prywatnych adresów IP:

Aby zatrzymać i uruchomić usługę Application Gateway, możesz użyć programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure. Po zatrzymaniu i uruchomieniu usługi Application Gateway rozliczenia również są zatrzymywane i uruchamiane. Każda operacja PUT wykonywana na zatrzymanej bramie aplikacji (na przykład dodawanie tagu, sondy kondycji lub odbiornika) wyzwala uruchomienie. Zalecamy zatrzymanie bramy aplikacji po zaktualizowaniu konfiguracji.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Usługa Application Gateway obsługuje certyfikaty z podpisem własnym, certyfikaty urzędu certyfikacji (CA), certyfikaty rozszerzonej weryfikacji (EV), certyfikaty wielodomenowe (SAN) i certyfikaty wieloznaczne.

Usługa Application Gateway obsługuje następujące zestawy szyfrowania:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Aby uzyskać informacje na temat dostosowywania opcji protokołu TLS, zobacz Konfigurowanie wersji zasad PROTOKOŁU TLS i zestawów szyfrowania w usłudze Application Gateway.

Tak. Usługa Application Gateway obsługuje odciążanie protokołu TLS i kompleksowe szyfrowanie TLS, które ponownie szyfruje ruch do zaplecza.

Tak. Usługę Application Gateway można skonfigurować tak, aby blokowała protokoły TLS1.0, TLS1.1 i TLS1.2. Domyślnie protokoły SSL 2.0 i 3.0 są już wyłączone i nie można ich konfigurować.

Tak. W usłudze Application Gateway można skonfigurować zestawy szyfrowania. Aby zdefiniować zasady niestandardowe, włącz co najmniej jeden z następujących zestawów szyfrowania:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Usługa Application Gateway używa algorytmu SHA256 do zarządzania zapleczem.

Usługa Application Gateway obsługuje maksymalnie 100 certyfikatów TLS/SSL.

Tak, usługa Application Gateway obsługuje certyfikaty z rozszerzeniami OCSP i zszywanieM OCSP dla certyfikatów serwera.

Usługa Application Gateway obsługuje maksymalnie 100 certyfikatów uwierzytelniania.

Tak, jednostka SKU usługi Application Gateway w wersji 2 obsługuje usługę Key Vault. Aby uzyskać więcej informacji, zobacz Zakończenie szyfrowania TLS z certyfikatami usługi Key Vault.

W przypadku routingu opartego na wielu domenach (opartego na hoście) można utworzyć odbiorniki wielowitrynowe, skonfigurować odbiorniki używające protokołu HTTPS jako protokół i skojarzyć odbiorniki z regułami routingu. Aby uzyskać więcej informacji, zobacz Hostowanie wielu witryn przy użyciu usługi Application Gateway.

L.p. Użyj tylko znaków alfanumerycznych w haśle pliku pfx.

Członkowie urzędu certyfikacji/przeglądarki opublikowali ostatnio raporty zawierające szczegółowe informacje o wielu certyfikatach wystawionych przez dostawców urzędu certyfikacji, które są używane przez naszych klientów, firmę Microsoft i większą społeczność technologiczną, które były niezgodne ze standardami branżowymi dla publicznie zaufanych urzędów certyfikacji. Raporty dotyczące niezgodnych urzędów certyfikacji można znaleźć tutaj:

• 1649951 usterek
• 1650910 usterek

Zgodnie z wymaganiami dotyczącymi zgodności w branży dostawcy urzędu certyfikacji zaczęli odwoływać niezgodne urzędy certyfikacji i wystawiać zgodne urzędy certyfikacji, co wymaga od klientów ponownego wystawienia certyfikatów. Firma Microsoft ściśle współpracuje z tymi dostawcami, aby zminimalizować potencjalny wpływ na usługi platformy Azure. Jednak certyfikaty wydane samodzielnie lub certyfikaty używane w scenariuszach BYOC (Bring Your Own Certificate) są nadal narażone na nieoczekiwane odwołanie.

Aby sprawdzić, czy certyfikaty używane przez aplikację zostały odwołane, zobacz ogłoszenie firmy DigiCert i monitor odwołania certyfikatów. Jeśli certyfikaty zostały odwołane lub zostaną odwołane, musisz zażądać nowych certyfikatów od dostawcy urzędu certyfikacji używanego w aplikacjach. Aby uniknąć przerwania dostępności aplikacji z powodu nieoczekiwanego odwołania certyfikatów lub zaktualizowania certyfikatu, który został odwołany, zobacz Odwołanie niezgodnych urzędów certyfikacji potencjalnie wpływających na usługi platformy Azure klienta.

Aby uzyskać informacje specyficzne dla usługi Application Gateway:

Jeśli używasz certyfikatu wystawionego przez jeden z odwołanych urzędów ICA, dostępność aplikacji może zostać przerwana. W zależności od aplikacji mogą pojawić się różne komunikaty o błędach, w tym między innymi:

• Nieprawidłowy certyfikat/odwołany certyfikat
• Przekroczono limit czasu połączenia
• HTTP 502

Aby uniknąć jakichkolwiek przerw w działaniu aplikacji z powodu tego problemu lub ponownego wystawienia urzędu certyfikacji, który został odwołany, należy wykonać następujące czynności:

1. Skontaktuj się z dostawcą certyfikatów, aby dowiedzieć się, jak ponownie wystawiać certyfikaty.
2. Po ich ponownym uruchomieniu zaktualizuj certyfikaty w usłudze Application Gateway/zaporze aplikacji internetowej za pomocą pełnego łańcucha zaufania (liścia, pośredniego i certyfikatu głównego). W zależności od tego, gdzie używasz certyfikatu, na odbiorniku lub w ustawieniach PROTOKOŁU HTTP bramy aplikacji, wykonaj kroki opisane tutaj, aby zaktualizować certyfikaty. Aby uzyskać więcej informacji, zapoznaj się z wymienionymi linkami do dokumentacji.
3. Zaktualizuj serwery aplikacji zaplecza, aby używały ponownie certyfikatu. W zależności od używanego serwera zaplecza kroki aktualizacji certyfikatu mogą się różnić. Sprawdź dokumentację od dostawcy.

Aby zaktualizować certyfikat w odbiorniku:

1. W witrynie Azure Portal otwórz zasób usługi Application Gateway.
2. Otwórz ustawienia odbiornika skojarzone z certyfikatem.
3. Wybierz pozycję Odnów lub edytuj wybrany certyfikat.
4. Przekaż nowy certyfikat PFX przy użyciu hasła i wybierz pozycję Zapisz.
5. Uzyskaj dostęp do witryny internetowej i sprawdź, czy witryna działa zgodnie z oczekiwaniami. Aby uzyskać więcej informacji, zobacz Odnawianie certyfikatów usługi Application Gateway.

Jeśli odwołujesz się do certyfikatów z usługi Key Vault w odbiorniku usługi Application Gateway, zalecamy wykonanie następujących kroków w celu szybkiej zmiany:

1. W witrynie Azure Portal przejdź do ustawień usługi Key Vault skojarzonych z bramą aplikacji.
2. Dodaj lub zaimportuj ponownie wyświetlony certyfikat w magazynie. Aby uzyskać więcej informacji, zobacz Szybki start: tworzenie magazynu kluczy przy użyciu witryny Azure Portal.
3. Po zaimportowaniu certyfikatu przejdź do ustawień odbiornika usługi Application Gateway, a następnie w obszarze Wybierz certyfikat z usługi Key Vault wybierz listę rozwijaną Certyfikat i wybierz ostatnio dodany certyfikat.
4. Wybierz pozycję Zapisz. Aby uzyskać więcej informacji na temat kończenia żądań protokołu TLS w usłudze Application Gateway z certyfikatami usługi Key Vault, zobacz Kończenie szyfrowania TLS przy użyciu certyfikatów usługi Key Vault.

Aby zaktualizować certyfikat w ustawieniach protokołu HTTP:

Jeśli używasz jednostki SKU w wersji 1 usługi Application Gateway/zapory aplikacji internetowej, musisz przekazać nowy certyfikat jako certyfikat uwierzytelniania zaplecza.

1. W witrynie Azure Portal otwórz zasób usługi Application Gateway.
2. Otwórz ustawienia PROTOKOŁU HTTP skojarzone z certyfikatem.
3. Wybierz pozycję Dodaj certyfikat, przekaż ponownie wyświetlony certyfikat, a następnie wybierz pozycję Zapisz.
4. Stary certyfikat można usunąć później, wybierając przycisk opcje ... obok starego certyfikatu. Wybierz pozycję Usuń , a następnie wybierz pozycję Zapisz. Aby uzyskać więcej informacji, zobacz Konfigurowanie kompleksowego protokołu TLS przy użyciu usługi Application Gateway z portalem.

Jeśli używasz jednostki SKU w wersji 2 usługi Application Gateway/zapory aplikacji internetowej, nie musisz przekazywać nowego certyfikatu w ustawieniach PROTOKOŁU HTTP, ponieważ jednostka SKU w wersji 2 używa "zaufanych certyfikatów głównych", a w tym miejscu nie trzeba podejmować żadnych działań.

Tak. Zarówno warstwa 7, jak i warstwa 4 routingu za pośrednictwem bramy aplikacji używają tej samej konfiguracji adresu IP frontonu. W ten sposób można skierować wszystkich klientów do jednego adresu IP (publicznego lub prywatnego), a ten sam zasób bramy będzie kierować je na podstawie skonfigurowanych protokołów odbiornika i portów.

Chociaż ruch HTTP może być również obsługiwany za pośrednictwem protokołów serwera proxy L4, nie zalecamy tego. Rozwiązanie serwera proxy L7 usługi Application Gateway zapewnia większą kontrolę i bezpieczeństwo protokołów HTTP(S) za pomocą zaawansowanych funkcji, takich jak ponowne zapisywanie, koligacja sesji, przekierowywanie, protokoły WebSocket, zapora aplikacji internetowej i inne.

Właściwości zasobów dla funkcji warstwy 4 różnią się od właściwości warstwy 7. W związku z tym w przypadku korzystania z interfejsu API REST lub interfejsu wiersza polecenia należy użyć następujących właściwości.

• Interfejs API REST
• CLI

L.p. Nie można łączyć właściwości warstwy 4 i warstwy 7. W związku z tym reguła routingu umożliwia łączenie odbiornika warstwy 4 z ustawieniem zaplecza warstwy 4.

Nie można użyć tej samej nazwy dla L7 (httpListeners) i L4 (odbiorniki). Dotyczy to również innych właściwości L4, takich jak backendSettingsCollection i routingRules.

Naturalnie. Podobnie jak w przypadku serwera proxy warstwy 7, można dodać prywatny punkt końcowy do puli zaplecza bramy aplikacji. Ten prywatny punkt końcowy musi zostać wdrożony w sąsiedniej podsieci tej samej sieci wirtualnej bramy aplikacji.

Nie używa ona usługi Keepalive dla połączeń zaplecza. W przypadku każdego żądania przychodzącego w połączeniu odbiornika frontonu usługa Application Gateway inicjuje nowe połączenie zaplecza w celu spełnienia tego żądania.

Serwer zaplecza widzi adres IP bramy aplikacji. Obecnie nie obsługujemy "zachowywania adresu IP klienta", za pomocą którego aplikacja zaplecza może być świadoma oryginalnego adresu IP klienta.

Ta sama konfiguracja zasad TLS/SSL ma zastosowanie zarówno dla warstwy 7 (HTTPS), jak i warstwy 4 (TLS). Teraz można używać profilu SSL (dla zasad protokołu TLS specyficznych dla odbiornika i wzajemnego uwierzytelniania) dla odbiorników PROTOKOŁU TLS. Jednak obecnie profil SSL może być skojarzony z odbiornikiem TLS tylko za pośrednictwem interfejsu wiersza polecenia, programu PowerShell lub interfejsu API REST.

L.p. Routing klienta do tego samego serwera zaplecza nie jest obecnie obsługiwany. Połączenia będą dystrybuowane w sposób okrężny do serwerów w puli zaplecza.

Tak, funkcja automatycznego skalowania będzie działać również w przypadku skoków i redukcji ruchu w przypadku protokołu TLS lub TCP.

Możliwości zapory aplikacji internetowej (WAF) nie będą działać w przypadku użycia warstwy 4.

L.p. Obecnie obsługa protokołu UDP nie jest dostępna.

Ta sama lista dozwolonych zakresów portów i wyjątków dotyczy również serwera proxy warstwy 4.

Użycie wspólnego portu dla odbiorników TLS/TCP nie jest obecnie obsługiwane.

Platforma Kubernetes umożliwia tworzenie deployment zasobów i service uwidocznienie grupy zasobników w klastrze. Aby uwidocznić tę samą usługę Ingress zewnętrznie, zdefiniowany jest zasób, który zapewnia równoważenie obciążenia, kończenie żądań PROTOKOŁU TLS i hosting wirtualny oparty na nazwach. Aby spełnić ten Ingress zasób, wymagany jest kontroler ruchu przychodzącego, który nasłuchuje wszelkich zmian Ingress zasobów i konfiguruje zasady modułu równoważenia obciążenia.

Kontroler ruchu przychodzącego usługi Application Gateway (AGIC) umożliwia usłudze Application Gateway używanie jako ruchu przychodzącego dla usługi Azure Kubernetes Service, znanej również jako klaster usługi AKS.

Bezpośrednia konfiguracja usługi Application Gateway nie jest obsługiwana.

Jeśli w usłudze Application Gateway trzeba zmienić ustawienia, wprowadź zmianę przy użyciu uwidocznionej konfiguracji na kontrolerze ruchu przychodzącego lub innych obiektach Kubernetes, takich jak użycie obsługiwanych adnotacji. Po połączeniu usługi Application Gateway z kontrolerem ruchu przychodzącego usługi Application Gateway (AGIC) prawie wszystkie konfiguracje tej bramy zostaną zsynchronizowane i kontrolowane przez kontroler ruchu przychodzącego. Jeśli próbujesz bezpośrednio skonfigurować usługę Application Gateway w sposób imperatywny lub za pomocą infrastruktury jako kodu, te zmiany zostaną ostatecznie zastąpione przez kontroler ruchu przychodzącego.

Obecnie jedno wystąpienie kontrolera ruchu przychodzącego może być skojarzone tylko z jedną bramą aplikacji.

Program AGIC próbuje automatycznie skojarzyć zasób tabeli tras z podsiecią usługi Application Gateway, ale może się nie powieść z powodu braku uprawnień z usługi AGIC. Jeśli program AGIC nie może skojarzyć tabeli tras z podsiecią usługi Application Gateway, w dziennikach AGIC zostanie wyświetlony błąd. W takim przypadku należy ręcznie skojarzyć tabelę tras utworzoną przez klaster usługi AKS z podsiecią usługi Application Gateway. Aby uzyskać więcej informacji, zobacz Obsługiwane trasy zdefiniowane przez użytkownika.

Tak, o ile sieci wirtualne są równorzędne i nie mają nakładających się przestrzeni adresowych. Jeśli używasz usługi AKS z rozwiązaniem kubenet, pamiętaj, aby skojarzyć tabelę tras wygenerowaną przez usługę AKS z podsiecią usługi Application Gateway.

Aby uzyskać różnice między programem AGIC wdrożonym za pośrednictwem programu Helm a wdrożonym jako dodatek usługi AKS, zobacz Różnice między wdrożeniem programu Helm i dodatkiem AKS.

Aby uzyskać różnice między usługą AGIC wdrożoną za pośrednictwem programu Helm a wdrożoną jako dodatek usługi AKS, zobacz Różnice między wdrożeniem programu Helm i dodatkiem AKS, zwłaszcza tabele dokumentujące, które scenariusze są obsługiwane przez program AGIC wdrożony za pośrednictwem programu Helm, w przeciwieństwie do dodatku usługi AKS. Ogólnie rzecz biorąc, wdrażanie za pomocą programu Helm umożliwia testowanie funkcji beta i kandydatów do wydania przed oficjalnym wydaniem.

L.p. Dodatek AGIC jest usługą zarządzaną, co oznacza, że firma Microsoft automatycznie aktualizuje dodatek do najnowszej stabilnej wersji.

Wzajemne uwierzytelnianie jest dwukierunkowym uwierzytelnianiem między klientem a serwerem. Wzajemne uwierzytelnianie za pomocą usługi Application Gateway umożliwia obecnie bramie sprawdzenie, czy klient wysyła żądanie, czyli uwierzytelnianie klienta. Zazwyczaj klient jest jedynym klientem, który uwierzytelnia bramę aplikacji. Ponieważ usługa Application Gateway może teraz również uwierzytelniać klienta, staje się uwierzytelnianiem wzajemnym, w którym usługa Application Gateway i klient wzajemnie się uwierzytelniają.

Nie, wzajemne uwierzytelnianie jest obecnie tylko między klientem frontonu a bramą aplikacji. Wzajemne uwierzytelnianie zaplecza nie jest obecnie obsługiwane.

Usługa Application Gateway udostępnia trzy dzienniki:

• ApplicationGatewayAccessLog: dziennik dostępu zawiera każde żądanie przesłane do frontonu bramy aplikacji. Dane obejmują adres IP obiektu wywołującego, żądany adres URL, opóźnienie odpowiedzi, kod zwrotny i bajty w i na wyjęcie. Zawiera jeden rekord na bramę aplikacji.
• ApplicationGatewayPerformanceLog: dziennik wydajności przechwytuje informacje o wydajności dla każdej bramy aplikacji. Informacje obejmują przepływność w bajtach, łączną liczbę obsługiwanych żądań, liczbę żądań niepomyślnie oraz liczbę wystąpień zaplecza w złej kondycji i kondycji.
• ApplicationGatewayFirewallLog: w przypadku bram aplikacji skonfigurowanych za pomocą zapory aplikacji internetowej dziennik zapory zawiera żądania rejestrowane za pośrednictwem trybu wykrywania lub trybu zapobiegania.

Wszystkie dzienniki są zbierane co 60 sekund. Aby uzyskać więcej informacji, zobacz Kondycja zaplecza, dzienniki diagnostyczne i metryki dla usługi Application Gateway.

Sprawdź kondycję przy użyciu polecenia cmdlet Get-AzApplicationGatewayBackendHealth programu PowerShell lub portalu. Aby uzyskać więcej informacji, zobacz Diagnostyka usługi Application Gateway.

Dzienniki diagnostyczne przepływają do konta magazynu klienta. Klienci mogą ustawić zasady przechowywania na podstawie ich preferencji. Dzienniki diagnostyczne można również wysyłać do centrum zdarzeń lub dzienników usługi Azure Monitor. Aby uzyskać więcej informacji, zobacz Diagnostyka usługi Application Gateway.

W portalu w okienku menu bramy aplikacji wybierz pozycję Dziennik aktywności, aby uzyskać dostęp do dziennika inspekcji.

Tak. W usłudze Application Gateway alerty są konfigurowane dla metryk. Aby uzyskać więcej informacji, zobacz Metryki usługi Application Gateway i Otrzymywanie powiadomień o alertach.

Dzienniki dostępu można wyświetlać i analizować na kilka sposobów. Użyj dzienników usługi Azure Monitor, programu Excel, usługi Power BI itd.

Można również użyć szablonu usługi Resource Manager, który instaluje i uruchamia popularny analizator dzienników usługi GoAccess dla dzienników dostępu usługi Application Gateway. Funkcja GoAccess udostępnia cenne statystyki ruchu HTTP, takie jak unikatowe osoby odwiedzające, żądane pliki, hosty, systemy operacyjne, przeglądarki i kody stanu HTTP. Aby uzyskać więcej informacji, zobacz plik Readme w folderze szablonu usługi Resource Manager.

Zazwyczaj jest wyświetlany nieznany stan, gdy dostęp do zaplecza jest blokowany przez sieciową grupę zabezpieczeń, niestandardowy routing DNS lub routing zdefiniowany przez użytkownika w podsieci usługi Application Gateway. Aby uzyskać więcej informacji, zobacz Kondycja zaplecza, rejestrowanie diagnostyczne i metryki dla usługi Application Gateway.

Ze względu na bieżące ograniczenia platformy, jeśli masz sieciową grupę zabezpieczeń w podsieci Application Gateway w wersji 2 (Standard_v2, WAF_v2), a jeśli włączono dzienniki przepływu sieciowej grupy zabezpieczeń, zobaczysz nieokreślone zachowanie. Ten scenariusz nie jest obecnie obsługiwany.

Usługa Application Gateway nie przenosi ani nie przechowuje danych klientów z regionu, w którym jest wdrażany.

Następne kroki

• Aby dowiedzieć się więcej o usłudze Application Gateway, zobacz Co to jest aplikacja systemu Azure Gateway.
• Aby dowiedzieć się więcej na temat kończenia żądań protokołu TLS i kompleksowego protokołu TLS w usłudze Application Gateway, zobacz Włączanie kompleksowego protokołu TLS w usłudze aplikacja systemu Azure Gateway.