Udostępnij za pośrednictwem

Rozwiązywanie problemów z nieprawidłową bramą w usłudze Application Gateway

  • Artykuł

Dowiedz się, jak rozwiązywać problemy z błędami nieprawidłowej bramy (502) odebrane podczas korzystania z usługi aplikacja systemu Azure Gateway.

Uwaga

Do interakcji z platformą Azure zalecamy używanie modułu Azure Az w programie PowerShell. Zobacz Instalowanie programu Azure PowerShell, aby rozpocząć. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.

Omówienie

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:

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ń, trasy zdefiniowanej przez użytkownika lub niestandardowego systemu DNS, wystąpienia bramy aplikacji nie mogą uzyskać dostępu do puli zaplecza. Ten problem powoduje błędy sondy, co powoduje błędy 502.

Sieciowa grupa zabezpieczeń/trasa zdefiniowana przez użytkownika może znajdować się w podsieci bramy aplikacji lub w podsieci, w której są wdrażane maszyny wirtualne aplikacji.

Podobnie obecność niestandardowego systemu DNS w sieci wirtualnej może również powodować problemy. Nazwa FQDN używana dla członków puli zaplecza może nie być poprawnie rozpoznawana przez użytkownika skonfigurowanego serwera DNS dla sieci wirtualnej.

Rozwiązanie

Zweryfikuj sieciową grupę zabezpieczeń, trasę zdefiniowaną przez użytkownika i konfigurację DNS, wykonując następujące kroki:

  1. Sprawdź sieciowe grupy zabezpieczeń skojarzone z podsiecią bramy aplikacji. 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 trasa zdefiniowana przez użytkownika nie kieruje ruchu z podsieci zaplecza. Na przykład sprawdź routing do wirtualnych urządzeń sieciowych lub tras domyślnych anonsowanych 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 rozpoznać nazwę FQDN elementu członkowskiego 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 aprowizacji wystąpienia bramy aplikacji automatycznie konfiguruje domyślną sondę kondycji do każdej puli BackendAddressPool przy użyciu właściwości 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 skojarzenie jest wykonywane między backendHttpSetting i BackendAddressPool. 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:

Właściwość sondy Wartość Opis
Adres URL sondy http://127.0.0.1/ Ścieżka adresu URL
Interwał 30 Interwał sondy w sekundach
Limit czasu 30 Limit czasu sondy w sekundach
Próg złej kondycji 3 Liczba ponownych prób sondy. Serwer zaplecza jest oznaczony jako wyłączony po osiągnięciu progu złej kondycji przez kolejną liczbę niepowodzeń sondy.

Rozwiązanie

  • Wartość hosta żądania zostanie 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 zostanie 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 metody powinno protocol://127.0.0.1:port 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 nazwą FQDN lub publicznym adresem IP, upewnij się, że odpowiedni punkt końcowy 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ą kondycji

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:

Właściwość sondy opis
Nazwa/nazwisko Nazwa sondy. Ta nazwa służy do odwoływania się do sondy w ustawieniach http zaplecza.
Protokół Protokół używany do wysyłania sondy. Sonda używa protokołu zdefiniowanego w ustawieniach http zaplecza
Gospodarz Nazwa hosta do wysłania sondy. Dotyczy tylko wtedy, gdy w bramie aplikacji skonfigurowano wiele lokacji. Różni się to od nazwy hosta maszyny wirtualnej.
Ścieżka Względna ścieżka sondy. Prawidłowa ścieżka rozpoczyna się od '/'. Sonda jest wysyłana do <adresu protocol>://<host>:<port><path>
Interwał Interwał sondy w sekundach. Jest to przedział czasu między dwoma kolejnymi sondami.
Limit czasu Limit czasu sondy w sekundach. Jeśli prawidłowa odpowiedź nie zostanie odebrana w tym przedziale czasu, sonda zostanie oznaczona jako nieudana.
Próg złej kondycji Liczba ponownych prób sondy. Serwer zaplecza jest oznaczony jako wyłączony po osiągnięciu progu złej kondycji przez kolejną liczbę niepowodzeń sondy.

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 lokacji, domyślnie nazwa hosta powinna być określona jako 127.0.0.1, chyba że w przeciwnym razie skonfigurowano w sondie niestandardowej.
  • Upewnij się, że wywołanie metody http://< host>:<ścieżka> portu><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 do żądania skonfigurowane reguły i kieruje je do wystąpienia puli zaplecza. Następnie czeka przez skonfigurowany interwał czasu na odpowiedź z wystąpienia zaplecza. Domyślnie ten interwał wynosi 20 sekund. W usłudze Application Gateway w wersji 1, jeśli w tym interwale czasu brama aplikacji nie otrzyma odpowiedzi z aplikacji zaplecza, żądanie użytkownika otrzyma błąd 502. W Application Gateway w wersji 2, jeśli w tym interwale czasu Application Gateway nie otrzyma odpowiedzi z aplikacji zaplecza, to żądanie zostanie wypróbowane z drugim członkiem puli wewnętrznej bazy danych. Jeśli drugie żądanie nie powiedzie się, to żądanie użytkownika otrzyma błąd 504.

Rozwiązanie

Usługa Application Gateway umożliwia skonfigurowanie tego ustawienia za pośrednictwem BackendHttpSetting, które można następnie zastosować do różnych pul. Różne pule wewnętrznej bazy danych 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 backendAddressPool

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. 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ć nieistniejącą pulę adresów zaplecza. W poniższym przykładzie przedstawiono dwie zwrócone pule, które są skonfigurowane przy użyciu nazwy FQDN lub adresów IP dla maszyn wirtualnych zaplecza. 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"
}]

Wystąpienia w złej kondycji w puli BackendAddressPool

Przyczyna

Jeśli wszystkie wystąpienia puli BackendAddressPool są w złej kondycji, brama aplikacji nie ma żadnego zaplecza do kierowania żądania użytkownika do. Może to być również przypadek, gdy wystąpienia zaplecza są w dobrej kondycji, ale nie mają wdrożonej wymaganej aplikacji.

Rozwiązanie

Upewnij się, że wystąpienia są w dobrej kondycji, a aplikacja jest prawidłowo skonfigurowana. Sprawdź, czy wystąpienia zaplecza mogą odpowiadać na polecenie 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 jest niezgodny

Przyczyna

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

W scenariuszach, w których włączono kompleksową obsługę protokołu TLS, konfiguracja osiągana przez edytowanie odpowiednich ustawień HTTP zaplecza i zmiana konfiguracji ustawienia "Protokół zaplecza" na https jest wymagana, aby upewnić się, że rekord CNAME certyfikatu TLS zainstalowanego na serwerach zaplecza jest zgodny z nazwą hosta przychodzącą do zaplecza w żądaniu nagłówka hosta HTTP.

Jak przypominamy, efekt włączenia opcji "Ustawienia HTTP zaplecza" opcji protokołu HTTPS, a nie PROTOKOŁU HTTP, będzie to, że druga część komunikacji, która odbywa się między wystąpieniami usługi Application Gateway a serwerami zaplecza, zostanie zaszyfrowana przy użyciu protokołu TLS.

Ze względu na fakt, że domyślnie usługa Application Gateway wysyła ten sam nagłówek hosta HTTP do zaplecza, który odbiera od klienta, należy upewnić się, że certyfikat TLS zainstalowany na serwerze zaplecza jest wystawiany z nazwą hosta zgodną z nazwą hosta odebraną przez ten serwer zaplecza 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.

Na przykład:

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

W tej usłudze Application Gateway należy mieć odbiornik dla hosta www.contoso.com z regułą, która ma "Obsługiwane ustawienie HTTP" wymuszone użycie protokołu HTTPS (zapewnienie kompleksowego protokołu 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 "Poparte na protokole HTTP" reguły spowoduje, że druga część komunikacji między wystąpieniami usługi Application Gateway a serwerami w zapleczu do używania protokołu TLS.

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

www.contoso.com —> adres IP frontonu bramy aplikacji —> odbiornik z regułą, która konfiguruje ustawienia HTTP zaplecza do używania protokołu HTTPS, a nie HTTP —> pula zaplecza —> serwer sieci Web (musi mieć zainstalowany certyfikat TLS dla www.contoso.com)

Rozwiązanie

Wymagane jest, aby CNAME certyfikatu TLS zainstalowanego na serwerze zaplecza, pasował do nazwy hosta skonfigurowanej w ustawieniach zaplecza HTTP, w przeciwnym razie druga część kompleksowej komunikacji, która występuje między wystąpieniami usługi Application Gateway i zaplecza, zakończy się niepowodzeniem z komunikatem "Nadrzędny certyfikat SSL nie jest zgodny" i zwróci błąd serwera: 502 — Serwer sieci Web otrzymał nieprawidłową odpowiedź działającą jako brama lub serwer proxy

Następne kroki

Jeśli powyższe kroki nie rozwiążą problemu, otwórz bilet pomocy technicznej.