** Rozwiązywanie problemów z błędami złej bramy w usłudze Application Gateway

Dowiedz się, jak rozwiązywać problemy związane z błędami gateway (502) pojawiającymi się podczas korzystania z Azure Application Gateway.

Przegląd

Po skonfigurowaniu bramy aplikacji jeden z błędów, które mogą zostać wyświetlone, to 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 głównych powodów:

• Sieciowa grupa zabezpieczeń (NSG), trasa zdefiniowana przez użytkownika (UDR) lub niestandardowy system DNS blokuje dostęp do członków puli zaplecza.
• Maszyny wirtualne zaplecza lub wystąpienia zestawu skalowania maszyn wirtualnych nie odpowiadają na domyślną próbę sprawdzającą stan zdrowia.
• Nieprawidłowa lub niewłaściwa konfiguracja niestandardowych sond zdrowia.
• Brama aplikacji Azure ma niezaprojektowaną lub pustą pulę zaplecza.
• Żadna z maszyn wirtualnych ani instancji w zestawie skalowania maszyn wirtualnych nie jest w dobrej kondycji.
• Problemy z żądaniami użytkowników: albo przekroczenie limitu czasu, albo kłopoty z łącznością.

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

Przyczyna

Jeśli dostęp do zaplecza jest zablokowany z powodu sieciowej grupy zabezpieczeń (NSG), trasy zdefiniowanej przez użytkownika (UDR) lub niestandardowego DNS, wystąpienia bramy aplikacji nie mogą komunikować się z pulą zaplecza. Ten problem powoduje awarie sondy, skutkujące błędami 502.

Grupa zabezpieczeń sieciowych (NSG) / trasa zdefiniowana przez użytkownika (UDR) może znajdować się w podsieci bramy aplikacyjnej lub w podsieci, gdzie wdrażane są maszyny wirtualne aplikacji.

Podobnie obecność niestandardowego systemu DNS w sieci wirtualnej może również powodować problemy. FQDN używany dla członków zaplecza serwerów może nie być poprawnie rozpoznawany przez serwer DNS skonfigurowany przez użytkownika dla sieci wirtualnej.

Rozwiązanie

Zweryfikuj konfigurację sieciowej grupy zabezpieczeń (NSG), trasę zdefiniowaną przez użytkownika (UDR) i konfigurację DNS, wykonując następujące kroki:

1. Sprawdź grupy zabezpieczeń sieciowych (NSG) skojarzone z podsiecią bramy aplikacyjnej. Upewnij się, że komunikacja z zapleczem nie jest zablokowana. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń.

2. Sprawdź trasę zdefiniowaną przez użytkownika skojarzoną z podsiecią bramy aplikacji. Upewnij się, że UDR nie kieruje ruchu z zaplecza sieciowego. Na przykład sprawdź routing do wirtualnych urządzeń sieciowych lub trasy domyślne ogłaszane do podsieci bramy aplikacji za pośrednictwem usługi ExpressRoute/VPN.

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

3. Sprawdź obowiązującą sieciową grupę zabezpieczeń i trasę przy użyciu maszyny wirtualnej zaplecza

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

4. Sprawdź obecność niestandardowego systemu DNS w sieci wirtualnej. System DNS można sprawdzić, sprawdzają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ć nazwę FQDN elementu należącego do puli zaplecza.

Problemy z domyślną sondą kondycji

Przyczyna

Błędy 502 mogą być również częstymi wskaźnikami, że domyślna sonda kondycji nie może uzyskać dostępu do maszyn wirtualnych zaplecza.

Po wdrożeniu wystąpienia bramy aplikacji, automatycznie konfiguruje domyślną sondę zdrowotną dla każdej puli BackendAddressPool przy użyciu właściwości z BackendHttpSetting. Do ustawienia tej sondy nie jest wymagane żadne dane wejściowe użytkownika. W szczególności po skonfigurowaniu reguły równoważenia obciążenia, zostaje nawiązane powiązanie między ustawieniem Backend HTTP a pulą adresów Backend. Domyślna sonda jest skonfigurowana dla każdego z tych skojarzeń, a brama aplikacji uruchamia okresowe połączenie sprawdzania kondycji z każdym wystąpieniem w puli BackendAddressPool na porcie określonym w elemecie BackendHttpSetting.

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

Rozwiązanie

• Wartość hosta żądania jest ustawiona na 127.0.0.1. Upewnij się, że skonfigurowano domyślną witrynę i nasłuchuje pod adresem 127.0.0.1.
• Protokół żądania jest określany przez protokół BackendHttpSetting.
• Ścieżka identyfikatora URI jest ustawiona na /.
• Jeśli ustawienie BackendHttpSetting określa port inny niż 80, należy skonfigurować domyślną witrynę do nasłuchiwania na tym porcie.
• Wywołanie do 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 i nie ma żadnych reguł zapory ani sieciowych grup zabezpieczeń platformy Azure blokujących ruch przychodzący lub wychodzący na skonfigurowanym porcie.
• Jeśli klasyczne maszyny wirtualne platformy Azure lub usługa w chmurze są używane z FQDN lub publicznym adresem IP, upewnij się, że odpowiedni interfejs jest otwarty.
• Jeśli maszyna wirtualna jest skonfigurowana za pośrednictwem usługi Azure Resource Manager i znajduje się poza siecią wirtualną, w której wdrożono bramę aplikacji, należy skonfigurować sieciową grupę zabezpieczeń , aby zezwolić na dostęp na żądanym porcie.

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

Problemy z niestandardową sondą zdrowia

Przyczyna

Niestandardowe sondy kondycji umożliwiają dodatkową elastyczność domyślnego zachowania sondowania. W przypadku używania sond niestandardowych można skonfigurować interwał sondowania, adres URL, ścieżkę do testowania oraz liczbę nieudanych odpowiedzi do zaakceptowania przed oznaczeniem wystąpienia puli zaplecza jako w złej kondycji.

Dodawane są następujące dodatkowe właściwości:

Rozwiązanie

Sprawdź, czy niestandardowa sonda kondycji jest poprawnie skonfigurowana, jak pokazano w poprzedniej tabeli. Oprócz powyższych kroków rozwiązywania problemów upewnij się również, że:

• Upewnij się, że sonda jest poprawnie określona zgodnie z przewodnikiem.
• Jeśli brama aplikacji jest skonfigurowana dla jednej witryny, domyślnie nazwa hosta powinna być określona jako 127.0.0.1, chyba że skonfigurowano inaczej w niestandardowej sondzie.
• Upewnij się, że wywołanie pod adresem http://<host>:<port><path> zwraca kod wyniku HTTP 200.
• Upewnij się, że przedziały czasu, limit czasu i wartość UnhealthyThreshold znajdują się w dopuszczalnych zakresach.
• Jeśli używasz sondy HTTPS, upewnij się, że serwer zaplecza nie wymaga SNI, konfigurując certyfikat rezerwowy na samym serwerze zaplecza.

Limit czasu żądania

Przyczyna

Po odebraniu żądania użytkownika brama aplikacji stosuje skonfigurowane reguły do żądania i kieruje je do instancji puli backend. Oczekuje na konfigurowalny czas oczekiwania na odpowiedź z instancji zaplecza. Domyślnie ten interwał wynosi 20 sekund. Jeśli w wersji 1 usługi Application Gateway brama aplikacji nie otrzyma odpowiedzi z aplikacji zaplecza w tym przedziale czasowym, żądanie użytkownika otrzyma błąd 502. Jeśli w usłudze Application Gateway w wersji 2 brama aplikacji nie otrzyma odpowiedzi z aplikacji zaplecza w tym interwale czasowym, żądanie zostanie wypróbowane względem drugiego członka puli zaplecza. Jeśli drugie żądanie nie powiedzie się, żądanie użytkownika otrzyma błąd 504.

Rozwiązanie

Usługa Application Gateway umożliwia skonfigurowanie tego ustawienia za pośrednictwem elementu BackendHttpSetting, które można następnie zastosować do różnych pul. Różne pule zaplecza mogą mieć różne ustawienia BackendHttpSetting i inne skonfigurowane limity czasu żądania.

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

Pusta pula adresów zaplecza

Przyczyna

Jeśli brama aplikacyjna nie ma skonfigurowanych maszyn wirtualnych ani zestawu skalowania maszyn wirtualnych w puli adresowej zaplecza, nie może przekierować żadnego żądania klienta i zwraca błąd bramy.

Rozwiązanie

Upewnij się, że pula adresów zaplecza nie jest pusta. Można to zrobić za pomocą programu PowerShell, interfejsu wiersza polecenia lub portalu.

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 pule, które są zwrócone i skonfigurowane przy użyciu pełnej nazwy domeny (FQDN) lub adresów IP dla maszyn wirtualnych backendu. Stan aprowizacji puli BackendAddressPool musi mieć wartość "Powodzenie".

BackendAddressPoolsText:

[{
    "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"
}]

Nieprawidłowe instancje w puli BackendAddressPool

Przyczyna

Jeśli wszystkie wystąpienia puli BackendAddressPool są w złej kondycji, brama aplikacji nie ma żadnego backendu, do którego mogłaby przekierować żądanie użytkownika. Może się to również zdarzyć, gdy instancje zaplecza działają prawidłowo, ale nie mają wdrożonej wymaganej aplikacji.

Rozwiązanie

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

Nadrzędny certyfikat SSL nie jest zgodny

Przyczyna

Certyfikat TLS zainstalowany na serwerach zaplecza nie jest zgodny z nazwą hosta odebraną w nagłówku żądania hosta.

W scenariuszach, w których włączono TLS end-to-end, co osiąga się poprzez edytowanie odpowiednich ustawień "Backend HTTP Settings" i zmianę konfiguracji ustawienia "Protokół zaplecza" na HTTPS, konieczne jest zapewnienie, że nazwa DNS certyfikatu TLS zainstalowanego na serwerach zaplecza jest zgodna z nazwą hosta przychodzącego do zaplecza w nagłówku żądania hosta HTTP.

Przypominamy, że włączenie w "Ustawieniach HTTP zaplecza" opcji protokołu HTTPS zamiast HTTP powoduje, że druga część komunikacji, która odbywa się między wystąpieniami usługi Application Gateway a serwerami zaplecza, jest szyfrowana przy użyciu protokołu TLS.

Ze względu na to, że domyślnie Application Gateway wysyła do zaplecza ten sam nagłówek hosta HTTP, jaki otrzymuje od klienta, musisz upewnić się, że certyfikat TLS zainstalowany na serwerze zaplecza został wystawiony z nazwą DNS odpowiadającą nazwie hosta, którą ten serwer zaplecza otrzymuje w nagłówku hosta HTTP. Należy pamiętać, że jeśli nie określono inaczej, ta nazwa hosta będzie taka sama jak nazwa odebrana od klienta.

Przykład:

Załóżmy, że masz usługę Application Gateway do obsługi żądań https dla domeny www.contoso.com. Możesz mieć domenę contoso.com przekazaną do publicznej strefy Azure DNS, a rekord A DNS w tej strefie wskazujący www.contoso.com na publiczny adres IP określonej aplikacji Application Gateway, która będzie obsługiwać żądania.

W tej bramie Application Gateway powinien znajdować się nasłuchiwacz dla hosta www.contoso.com, z regułą, która wymusza użycie protokołu HTTPS w "Ustawieniu zaplecza HTTP" (zapewniając kompleksowy protokół TLS). Ta sama reguła mogła skonfigurować pulę zaplecza z dwiema maszynami wirtualnymi z uruchomionymi usługami IIS jako serwerami sieci Web.

Jak wiemy, włączenie protokołu HTTPS w ustawieniu "Prywatnym HTTP" reguły sprawia, że druga część komunikacji między wystąpieniami usługi Application Gateway a serwerami w zapleczu korzysta z protokołu TLS.

Jeśli serwery zaplecza nie mają certyfikatu TLS wystawionego dla nazwy www.contoso.com DNS lub *.contoso.com, żądanie kończy się niepowodzeniem z powodu błędu serwera: 502 — Serwer sieci Web odebrał nieprawidłową odpowiedź, działając jako brama lub serwer proxy , ponieważ nadrzędny certyfikat SSL (certyfikat zainstalowany na serwerach zaplecza) nie jest zgodny z nazwą hosta w nagłówku hosta, w związku z tym negocjowanie protokołu TLS kończy się niepowodzeniem.

www.contoso.com --> IP interfejsu bramy aplikacji —> odbiornik z regułą konfigurującą "Ustawienia HTTP zaplecza" do używania protokołu HTTPS zamiast HTTP —> pula zaplecza —> serwer WWW (musi mieć zainstalowany certyfikat TLS dla www.contoso.com)

Rozwiązanie

Wymagana jest nazwa DNS certyfikatu TLS zainstalowanego na serwerze zaplecza, która musi być zgodna z nazwą hosta skonfigurowaną w ustawieniach zaplecza HTTP, w przeciwnym razie druga część komunikacji end-to-end, która występuje między instancjami Application Gateway a zapleczem, kończy się niepowodzeniem z komunikatem "Certyfikat SSL po stronie serwera nie pasuje" i zwraca błąd serwera: 502 — Serwer sieci Web otrzymał nieprawidłową odpowiedź, działając jako brama lub serwer proxy

Dalsze kroki

Jeśli powyższe kroki nie rozwiążą problemu, otwórz zgłoszenie serwisowe.