Rozwiązywanie problemów z błędami nieprawidłowej bramy (502) w Azure Application Gateway

Podsumowanie

Dowiedz się, jak rozwiązywać problemy z błędami nieprawidłowej bramy (502) w Azure Application Gateway, aby szybko przywrócić niezawodny dostęp do aplikacji internetowych.

Symptoms

Po skonfigurowaniu bramy aplikacji może zostać wyświetlony błąd "Błąd serwera: 502 — Serwer sieci Web odebrał nieprawidłową odpowiedź podczas działania jako brama lub serwer proxy". Ten błąd może wystąpić z następujących powodów:

• Problem z sieciową grupą zabezpieczeń, trasą zdefiniowaną przez użytkownika (UDR) lub niestandardowym systemem nazw domen (DNS)
• Domyślna sonda kondycji nie może dotrzeć do maszyn wirtualnych zaplecza
• Przekroczono limit czasu żądania do serwera zaplecza
• Pula zaplecza usługi Application Gateway nie jest skonfigurowana lub jest pusta
• Niezdrowe instancje w puli BackendAddressPool
• Nadrzędny certyfikat SSL nie jest zgodny

Problem z sieciową grupą zabezpieczeń, trasą zdefiniowaną przez użytkownika lub niestandardowym systemem DNS

Przyczyna

Jeśli sieciowa grupa zabezpieczeń, trasa zdefiniowana przez użytkownika lub niestandardowy system nazw domen blokują dostęp do zaplecza, instancje gateway aplikacji nie mogą uzyskać dostępu do puli zaplecza. Ten problem powoduje awarie prób, prowadząc do błędów 502.

W podsieci bramy aplikacji lub w podsieci, w której wdrożono maszyny wirtualne aplikacji (VM), może być skonfigurowana sieciowa grupa zabezpieczeń (NSG) lub trasa zdefiniowana przez użytkownika (UDR).

Podobnie obecność niestandardowego systemu DNS w sieci wirtualnej może również powodować problemy. Serwer DNS skonfigurowany przez użytkownika dla sieci wirtualnej (VNet) może nie rozwiązywać poprawnie w pełni kwalifikowanej nazwy domeny (FQDN) używanej dla członków puli zaplecza.

Rozwiązanie

Zweryfikuj konfigurację NSG, UDR i DNS. W tym celu wykonaj następujące kroki:

1. Sprawdź sieciowe grupy zabezpieczeń skojarzone z podsiecią usługi Application Gateway. Upewnij się, że komunikacja z zapleczem nie jest zablokowana. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń. Aby uzyskać informacje o łączności z zapleczem i kontroli sondy kondycji, zobacz Błąd połączenia TCP.

2. Sprawdź trasę UDR skojarzoną z podsiecią bramy aplikacji. Upewnij się, że trasa zdefiniowana przez użytkownika (UDR) nie kieruje ruchu z podsieci backendu. Na przykład sprawdź, czy ruch jest kierowany do wirtualnych urządzeń sieciowych lub czy do podsieci usługi Application Gateway są rozgłaszane trasy domyślne przy użyciu usługi Azure ExpressRoute lub Azure VPN. Uruchom następujące polecenia w Azure PowerShell.

   $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
   Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
   

3. Sprawdź obowiązujące sieciowe grupy zabezpieczeń i trasy przy użyciu maszyny wirtualnej zaplecza. Uruchom następujące polecenia w Azure PowerShell.

   Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
   Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
   

4. Sprawdź obecność niestandardowego systemu DNS w sieci wirtualnej. Sprawdź system DNS, przeglądając szczegóły właściwości sieci wirtualnej w danych wyjściowych.

   Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
   DhcpOptions            : {
                              "DnsServers": [
                                "x.x.x.x"
                              ]
                            }
   

5. Jeśli istnieje, upewnij się, że serwer DNS może poprawnie rozwiązać FQDN członka puli zaplecza.

Domyślna sonda kondycji nie może nawiązać połączenia z maszynami wirtualnymi zaplecza

Przyczyna

Błąd 502 może również wskazywać, że domyślna sonda kondycji nie może uzyskać dostępu do maszyn wirtualnych zaplecza.

Podczas aprowizowania wystąpienia bramy aplikacji automatycznie konfiguruje domyślną sondę kondycji dla każdego BackendAddressPool z nich przy użyciu właściwości BackendHttpSetting.

Nie musisz podawać żadnych danych wejściowych, aby ustawić tę sondę. W szczególności podczas konfigurowania reguły równoważenia obciążenia należy skojarzyć element BackendHttpSetting z elementem BackendAddressPool. Każde z tych powiązań ma skonfigurowaną domyślną sondę, a brama aplikacji nawiązuje okresowe połączenie kontroli kondycji z każdym wystąpieniem w BackendAddressPool na porcie określonym w elemencie BackendHttpSetting.

W poniższej tabeli wymieniono wartości skojarzone z domyślną sondą kondycji.

Rozwiązanie

Skorzystaj z poniższych wskazówek, aby rozwiązać problemy z domyślną sondą kondycji.

• Wartość hosta żądania jest ustawiona na 127.0.0.1. Sprawdź, czy skonfigurowano domyślną witrynę i czy nasłuchuje pod adresem IP 127.0.0.1.
• Protokół BackendHttpSetting określa protokół żądania.
• Ścieżka identyfikatora URI jest ustawiona na /*.
• Jeśli BackendHttpSetting określa port inny niż 80, skonfiguruj lokację domyślną do nasłuchiwania na tym porcie.
• Wywołanie protocol://127.0.0.1:port powinno zwrócić kod wyniku HTTP 200. Ten kod powinien zostać zwrócony w ciągu 30-sekundowego limitu czasu.
• Upewnij się, że skonfigurowany port jest otwarty oraz że nie ma żadnych reguł zapory ani sieciowych grup zabezpieczeń platformy Azure (NSG) blokujących ruch przychodzący lub wychodzący na tym porcie.
• Jeśli używasz klasycznych maszyn wirtualnych Azure lub usługi w chmurze posiadających FQDN albo publiczny adres IP, upewnij się, że otwierasz odpowiadający mu endpoint.
• Jeśli skonfigurujesz maszynę wirtualną (VM) przy użyciu Azure Resource Manager (ARM), a ta znajduje się poza siecią VNet, w której wdrożono usługę Application Gateway, skonfiguruj sieciową grupę zabezpieczeń, aby zezwolić na dostęp na określonym porcie.

Aby uzyskać więcej informacji, zobacz Konfiguracja infrastruktury usługi Application Gateway.

Asymetria ścieżki powrotnej

Sonda kondycji może dotrzeć do serwera zaplecza, ale mimo to zakończyć się niepowodzeniem, jeśli odpowiedź zostanie przekierowana lub odrzucona, zanim wróci do usługi Application Gateway. Ta asymetria ścieżki zwrotnej może wystąpić, gdy trasa zdefiniowana przez użytkownika (UDR) lub trasa uzyskana za pośrednictwem komunikacji równorzędnej sieci wirtualnych albo protokołu Border Gateway Protocol (BGP) kieruje odpowiedź przez wirtualne urządzenie sieciowe lub zaporę.

Sprawdź tabele tras i reguły zapory dla podsieci usługi Application Gateway i zaplecza oraz obowiązujące trasy w każdym interfejsie sieciowym zaplecza. Upewnij się, że ścieżka powrotna może dotrzeć do podsieci usługi Application Gateway i że zapora zezwala na ruch sondy. Aby uzyskać szczegółową listę kontrolną routingu i wskazówki dotyczące korygowania, zobacz Ścieżka sieciowa i symetria ścieżki zwrotnej.

W przypadku wdrożenia Application Gateway v2, które nie korzysta z wdrożenia Private Application Gateway, możesz również użyć Connection troubleshoot w portalu Azure, wybierając usługę Application Gateway jako źródło oraz adres i port zaplecza jako miejsce docelowe. Polecenie Azure CLI obsługuje maszynę wirtualną jako źródło. Aby przetestować ścieżkę z maszyny wirtualnej diagnostycznej do zaplecza, uruchom polecenie:

az network watcher test-connectivity \
  --source-resource '<diagnostic-vm-resource-id>' \
  --dest-address '<backend-ip-or-fqdn>' \
  --protocol TCP \
  --dest-port '<backend-port>'

Przejrzyj zwrócone przeskoki i problemy wskazujące na brakującą trasę lub blokującą regułę sieciowej grupy zabezpieczeń (NSG). Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z połączeniami za pomocą Azure Network Watcher.

Nieprawidłowa lub niewłaściwa konfiguracja niestandardowych sond kondycji

Przyczyna

Niestandardowe sondy kondycji zapewniają większą elastyczność niż domyślne zachowanie sondowania. W przypadku używania sond niestandardowych można ustawić interwał sondy, adres URL, ścieżkę do testowania oraz liczbę nieudanych odpowiedzi do zaakceptowania przed oznaczeniem wystąpienia puli zaplecza jako w złej kondycji.

W poniższej tabeli opisano dodatkowe właściwości, które można ustawić.

Rozwiązanie

Sprawdź, czy niestandardowa sonda kondycji została prawidłowo skonfigurowana, jak pokazano w poprzedniej tabeli. Oprócz powyższych wskazówek dotyczących rozwiązywania problemów postępuj zgodnie z poniższymi wskazówkami.

• Upewnij się, że prawidłowo określisz sondę zgodnie z przewodnikiem.
• Jeśli skonfigurujesz bramę aplikacji dla jednej witryny, ustaw domyślną nazwę hosta na 127.0.0.1, chyba że ustawisz ją inaczej w niestandardowej sondzie.
• Upewnij się, że wywołanie do http://<host>:<port><path> zwraca kod odpowiedzi HTTP 200.
• Upewnij się, że wartości Interval, Timeout i UnhealthyThreshold mieszczą się w dopuszczalnych zakresach.
• Jeśli używasz sondy HTTPS w jednostce SKU v2, usługa Application Gateway również wysyła nazwę hosta sondy jako wartość SNI. Upewnij się, że nazwa hosta jest zgodna z alternatywną nazwą podmiotu certyfikatu zaplecza (SAN) lub nazwą pospolitą (CN), jeśli certyfikat nie ma sieci SAN, zgodnie z opisem w specyfikacji RFC 6125. Usługa Application Gateway nie wysyła SNI, gdy nazwa hosta ma postać adresu IP, w tym domyślnego 127.0.0.1. Aby zapoznać się z instrukcjami porównania nazwy hosta sondy z nazwą w certyfikacie, zobacz Rozwiązanie F w artykule Rozwiązywanie problemów z błędami HTTP 502 w Azure Application Gateway. Jeśli nie możesz zmienić certyfikatu zaplecza, dostosuj ustawienia weryfikacji https zaplecza , aby użyć określonej wartości SNI lub pominąć walidację nazwy podmiotu.

Przekroczono limit czasu żądania do serwera zaplecza

Przyczyna

Gdy brama aplikacji odbiera żądanie użytkownika, stosuje skonfigurowane reguły do żądania i kieruje je do wystąpienia serwera zaplecza. Oczekuje na konfigurowalną przerwę na odpowiedź z instancji zaplecza. Domyślnie ten interwał wynosi 20 sekund. W usłudze Application Gateway v1, jeśli usługa Application Gateway nie otrzyma odpowiedzi z aplikacji zaplecza w tym czasie, użytkownik otrzyma błąd 502. W usłudze Application Gateway v2, jeśli brama aplikacji nie otrzyma odpowiedzi z aplikacji zaplecza w tym czasie, żądanie zostanie skierowane do drugiego członka puli zaplecza. Jeśli drugie żądanie również zakończy się niepowodzeniem, zamiast tego żądanie użytkownika otrzyma błąd 504. Jeśli użytkownicy otrzymują błędy 504 zamiast 502, zobacz Rozwiązywanie problemów z błędami HTTP 504 w Azure Application Gateway.

Jeśli aplikacja backendowa rutynowo potrzebuje więcej czasu na odpowiedź niż wynosi skonfigurowany interwał (na przykład w przypadku długotrwale wykonywanego zapytania lub generowania raportu), zwiększ limit czasu żądania w ustawieniu HTTP backendu używanym przez tę pulę backendów.

Rozwiązanie

Limit czasu żądania jest właściwością ustawienia HTTP zaplecza, więc różne pule zaplecza mogą mieć różne wartości limitu czasu żądania. Zwiększ ją przy użyciu portalu Azure, Azure CLI lub Azure PowerShell. Zaakceptowany zakres wynosi od 1 do 86400 sekund. Aby uzyskać więcej informacji, zobacz Limit czasu żądania.

Azure Portal

Wykonaj te kroki:

1. W portalu Azure przejdź do bramy aplikacji.
2. W obszarze Ustawienia wybierz pozycję Ustawienia zaplecza.
3. Wybierz ustawienie zaplecza używane przez pulę zaplecza, którego dotyczy problem.
4. Zwiększ wartość limitu czasu żądania (w sekundach), aby zapewnić więcej czasu odpowiedzi zaplecza.
5. Wybierz opcję Zapisz.

Azure CLI

Uruchom następujące polecenie w interfejsie wiersza polecenia platformy Azure:

az network application-gateway http-settings update \
  --gateway-name <application-gateway-name> \
  --resource-group <resource-group-name> \
  --name <backend-http-settings-name> \
  --timeout <time-out-in-seconds>

Azure PowerShell

Uruchom następujące polecenie w Azure PowerShell:

New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

Pula zaplecza usługi Application Gateway nie jest skonfigurowana lub jest pusta

Przyczyna

Jeśli brama aplikacji nie ma maszyn wirtualnych ani zestawu skalowania maszyn wirtualnych skonfigurowanych w puli adresów zaplecza, nie może kierować żadnych żądań klienta i wysyła błąd nieprawidłowej bramy.

Rozwiązanie

Upewnij się, że pula adresów zaplecza nie jest pusta. Ten warunek można sprawdzić za pomocą Azure PowerShell, Azure CLI lub portalu. Zobacz poniższy przykład, aby sprawdzić pulę adresów zaplecza za pośrednictwem Azure PowerShell.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

Dane wyjściowe z poprzedniego polecenia cmdlet powinny zawierać niepustą pulę adresów zaplecza. W poniższym przykładzie przedstawiono dwie zwrócone pule skonfigurowane przy użyciu nazwy FQDN lub adresów IP dla maszyn wirtualnych na zapleczu. Stan aprowizacji elementu BackendAddressPool musi wynosić Succeeded.

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

Wystąpienia niezdrowe w puli BackendAddressPool

Przyczyna

Jeśli wszystkie wystąpienia BackendAddressPool są w złej kondycji, brama aplikacji nie ma żadnego backendu do kierowania żądań użytkowników do. Ten warunek może również wystąpić, gdy instancje zaplecza działają prawidłowo, ale nie mają wdrożonej potrzebnej aplikacji.

Rozwiązanie

Upewnij się, że instancje są w dobrej kondycji, a aplikacja jest prawidłowo skonfigurowana. Sprawdź, czy instancje zaplecza mogą odpowiadać na ping z innej maszyny wirtualnej w tej samej sieci wirtualnej. Jeśli skonfigurujesz publiczny punkt końcowy, upewnij się, że żądanie przeglądarki do aplikacji internetowej jest możliwe do obsługi.

W przypadku zaplecza HTTPS wygasły certyfikat, niekompletny lub nieprawidłowy łańcuch certyfikatów lub niezgodność zaufanego certyfikatu głównego może powodować błędy sondy kondycji. Sprawdź ważność certyfikatu zaplecza i konfigurację zaufanego certyfikatu głównego w skojarzonym ustawieniu zaplecza. Aby uzyskać szczegółowe informacje na temat diagnostyki i usuwania problemu, zobacz Wygasły lub nieprawidłowy certyfikat TLS zaplecza.

Nadrzędny certyfikat SSL nie jest zgodny

Przyczyna

Certyfikat Transport Layer Security (TLS) zainstalowany na serwerach zaplecza nie jest zgodny z nazwą hosta odebraną w nagłówku żądania hosta HTTP.

W scenariuszach, w których włączono TLS typu end-to-end, skonfiguruj to, edytując odpowiednie ustawienia Backend HTTP. W razie potrzeby zmień konfigurację ustawienia protokołu zaplecza na HTTPS . Upewnij się, że DNS NAME certyfikat TLS zainstalowany na serwerach zaplecza jest zgodny z nazwą hosta przychodzącą do zaplecza w żądaniu nagłówka hosta HTTP.

Po ukończeniu tego kroku druga część komunikacji, która odbywa się między usługą Application Gateway a serwerami zaplecza, jest szyfrowana przy użyciu protokołu TLS.

Domyślnie usługa Application Gateway wysyła do zaplecza ten sam nagłówek HTTP Host, jaki otrzymuje od klienta. Upewnij się, że certyfikat TLS zainstalowany na serwerze zaplecza został wystawiony z DNS NAME, który odpowiada nazwie hosta otrzymywanej przez ten serwer zaplecza w nagłówku Host protokołu HTTP. Ta nazwa hosta powinna być taka sama jak nazwa odebrana od klienta.

Rozwiązanie

Instrukcje dotyczące dopasowania nazwy hosta sondy i nazwy SNI do nazwy SAN lub CN certyfikatu można znaleźć w sekcji Rozwiązanie F w artykule Rozwiązywanie problemów z błędami HTTP 502 w usłudze Azure Application Gateway. Aby dowiedzieć się, jak ustawienia zaplecza Wybierz nazwę hosta z obiektu docelowego zaplecza i Zastąp określoną nazwą domeny są mapowane na nazwę certyfikatu oczekiwaną przez usługę Application Gateway, zobacz Nazwa pospolita (CN) nie jest zgodna.