Problemy z kondycją zaplecza w usłudze Application Gateway

Omówienie

Domyślnie usługa Azure Application Gateway sonduje serwery zaplecza, aby sprawdzić stan ich kondycji i czy są one gotowe do obsługi żądań. Użytkownicy mogą również tworzyć niestandardowe sondy, aby wspomnieć o nazwie hosta, ścieżce do sondowania i kodach stanu, które mają być akceptowane jako w dobrej kondycji. W każdym przypadku, jeśli serwer zaplecza nie odpowie pomyślnie, Brama aplikacji oznaczy serwer jako w złej kondycji i przestanie przekazywać żądania do serwera. Gdy serwer zacznie odpowiadać pomyślnie, Brama aplikacji wznowi przekazywanie żądań.

Jak sprawdzić kondycję zaplecza

Aby sprawdzić kondycję puli zaplecza, możesz użyć strony Kondycja zaplecza w witrynie Azure Portal. Możesz też użyć programu Azure PowerShell, interfejsu wiersza polecenia lub interfejsu API REST.

Stan pobrany przez dowolną z tych metod może być jednym z następujących stanów:

• Dobra kondycja
• Nieprawidłowy
• Nieznane

Usługa Application Gateway przekazuje żądanie do serwera z puli zaplecza, jeśli jego stan jest w dobrej kondycji. Jeśli wszystkie serwery w puli zaplecza są w złej kondycji lub nieznane, klienci mogą napotkać problemy z dostępem do aplikacji zaplecza. Przeczytaj więcej, aby zrozumieć różne komunikaty zgłaszane przez usługę Backend Health, ich przyczyny i ich rozwiązanie.

Stan kondycji zaplecza: W złej kondycji

Jeśli stan kondycji zaplecza jest w złej kondycji, widok portalu przypomina następujący zrzut ekranu:

Jeśli używasz programu Azure PowerShell, interfejsu wiersza polecenia lub zapytania interfejsu API REST platformy Azure, otrzymasz odpowiedź podobną do następującego przykładu:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

Po otrzymaniu statusu serwera zaplecza w złej kondycji dla wszystkich serwerów w puli zaplecza, żądania nie są przekazywane do serwerów, a usługa Application Gateway zwraca błąd „502 Bad Gateway” do żądającego klienta. Aby rozwiązać ten problem, sprawdź kolumnę Szczegóły na karcie Kondycja zaplecza.

Komunikat wyświetlany w kolumnie Szczegóły zawiera bardziej szczegółowe informacje o problemie i na podstawie tych szczegółów możesz rozpocząć rozwiązywanie problemu.

Komunikaty o błędach

Limit czasu serwera zaplecza

Komunikat: Czas odpowiedzi zaplecza na sondę kondycji usługi Application Gateway przekracza próg limitu czasu w ustawieniu sondy.

Przyczyna: Gdy usługa Application Gateway wysyła żądanie sondy HTTP(S) do serwera zaplecza, czeka na odpowiedź z serwera zaplecza przez skonfigurowany okres. Jeśli serwer wewnętrznej bazy danych nie odpowie w skonfigurowanym czasie (wartość limitu czasu), zostanie oznaczony jako w złej kondycji, dopóki nie zacznie ponownie odpowiadać w skonfigurowanym czasie.

Rozdzielczość: Sprawdź, dlaczego serwer zaplecza lub aplikacja nie odpowiada w skonfigurowanym przedziale czasu, a także sprawdź zależności aplikacji. Sprawdź na przykład, czy w bazie danych występują jakiekolwiek problemy, które mogą powodować opóźnienie odpowiedzi. Jeśli wiesz o zachowaniu aplikacji i powinna ona odpowiadać dopiero po upływie wartości limitu czasu, zwiększ wartość limitu czasu w ustawieniach sondy niestandardowej. Aby zmienić wartość limitu czasu, wymagana jest sonda niestandardowa. Aby uzyskać informacje o sposobie konfigurowania sondy niestandardowej, zobacz stronę dokumentacji.

Aby zwiększyć wartość limitu czasu, wykonaj następujące kroki:

1. Uzyskaj bezpośredni dostęp do serwera zaplecza i sprawdź czas potrzebny serwerowi na udzielenie odpowiedzi na tej stronie. Do uzyskiwania dostępu do serwera zaplecza, w tym przeglądarki przy użyciu narzędzi deweloperskich, można użyć dowolnego narzędzia.
2. Po zapoznaniu się z czasem potrzebnym aplikacji na odpowiedź wybierz kartę Sondy kondycji , a następnie wybierz sondę skojarzona z ustawieniami PROTOKOŁU HTTP.
3. Wprowadź dowolną wartość limitu czasu większą niż czas odpowiedzi aplikacji w sekundach.
4. Zapisz ustawienia sondy niestandardowej i sprawdź, czy kondycja zaplecza jest teraz w dobrej kondycji.

Błąd rozpoznawania nazw DNS

Komunikat: Usługa Application Gateway nie może utworzyć sondy dla tego zaplecza. Dzieje się tak zazwyczaj wtedy, gdy nazwa FQDN zaplecza nie została wprowadzona prawidłowo. 

Przyczyna: Jeśli pula zaplecza jest typu ADRES IP, nazwa FQDN (w pełni kwalifikowana nazwa domeny) lub usługa App Service, usługa Application Gateway rozpoznaje adres IP nazwy FQDN wprowadzonej za pośrednictwem systemu DNS (wartość niestandardowa lub domyślna platforma Azure). Następnie brama aplikacji próbuje nawiązać połączenie z serwerem na porcie TCP wymienionym w ustawieniach protokołu HTTP. Ale jeśli jest wyświetlany ten komunikat, sugeruje to, że usługa Application Gateway nie mogła pomyślnie rozpoznać adresu IP wprowadzonej nazwy FQDN.

Rozwiązanie:

1. Sprawdź, czy nazwa FQDN wprowadzona w puli zaplecza jest poprawna i czy jest to domena publiczna, a następnie spróbuj rozpoznać ją z komputera lokalnego.
2. Jeśli możesz rozpoznać adres IP, może wystąpić problem z konfiguracją DNS w sieci wirtualnej.
3. Sprawdź, czy sieć wirtualna jest skonfigurowana z niestandardowym serwerem DNS. Jeśli tak jest, sprawdź serwer DNS, dlaczego nie może rozpoznać adresu IP określonej nazwy FQDN.
4. Jeśli używasz domyślnego systemu DNS platformy Azure, sprawdź u rejestratora nazw domen to, czy zostało ukończone prawidłowe mapowanie rekordów A lub CNAME.
5. Jeśli domena jest prywatna lub wewnętrzna, spróbuj rozwiązać problem z maszyną wirtualną w tej samej sieci wirtualnej. Jeśli możesz go rozwiązać, uruchom ponownie usługę Application Gateway i sprawdź ponownie. Aby ponownie uruchomić usługę Application Gateway, należy zatrzymać i uruchomić przy użyciu poleceń programu PowerShell opisanych w tych połączonych zasobach.

Błąd połączenia TCP

Komunikat: Usługa Application Gateway nie może nawiązać połączenia z zapleczem. Sprawdź, czy zaplecze odpowiada na porcie używanym na potrzeby sondy. Sprawdź również, czy dostępu do adresu IP i portu tego zaplecza nie blokuje żadna sieciowa grupa zabezpieczeń, trasa zdefiniowana przez użytkownika lub zapora.

Przyczyna: Po fazie rozpoznawania nazw DNS usługa Application Gateway próbuje nawiązać połączenie z serwerem wewnętrznej baza danych na porcie TCP skonfigurowanym w ustawieniach protokołu HTTP. Jeśli usługa Application Gateway nie może ustanowić sesji TCP na określonym porcie, sonda jest oznaczana jako w złej kondycji z tym komunikatem.

Rozwiązanie: Jeśli wystąpi ten błąd, wykonaj następujące kroki:

1. Sprawdź, czy możesz nawiązać połączenie z serwerem zaplecza na porcie wymienionym w ustawieniach PROTOKOŁU HTTP przy użyciu przeglądarki lub programu PowerShell. Na przykład uruchom następujące polecenie: Test-NetConnection -ComputerName www.bing.com -Port 443.

2. Jeśli wymieniony port nie jest żądanym portem, wprowadź prawidłowy numer portu dla usługi Application Gateway, aby nawiązać połączenie z serwerem zaplecza.

3. Jeśli nie możesz również nawiązać połączenia na porcie z komputera lokalnego, wykonaj następujące czynności:

   a. Sprawdź ustawienia sieciowej grupy zabezpieczeń karty sieciowej i podsieci serwera zaplecza oraz sprawdź, czy połączenia przychodzące ze skonfigurowanym portem są dozwolone. Jeśli tak nie jest, utwórz nową regułę, aby zezwolić na połączenia. Aby dowiedzieć się, jak tworzyć reguły sieciowej grupy zabezpieczeń, zobacz stronę dokumentacji.

   b. Sprawdź, czy ustawienia sieciowej grupy zabezpieczeń podsieci usługi Application Gateway zezwalają na wychodzący ruch publiczny i prywatny, aby można było nawiązać połączenie. Sprawdź stronę dokumentu podaną w kroku 3a, aby dowiedzieć się więcej na temat tworzenia reguł sieciowej grupy zabezpieczeń.

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

   c. Sprawdź ustawienia tras zdefiniowanych przez użytkownika w usłudze Application Gateway i podsieci serwera zaplecza pod kątem wszelkich anomalii routingu. Upewnij się, że trasa zdefiniowana przez użytkownika nie kieruje ruchem z podsieci zaplecza. Na przykład sprawdź trasy do wirtualnych urządzeń sieciowych lub tras domyślnych anonsowanych do podsieci usługi Application Gateway za pośrednictwem usługi Azure ExpressRoute i/lub sieci VPN.

   d. Aby sprawdzić obowiązujące trasy i reguły dla karty sieciowej, możesz użyć następujących poleceń programu PowerShell:

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

4. Jeśli nie znajdziesz żadnych problemów z sieciową grupą zabezpieczeń lub trasy zdefiniowanej przez użytkownika, sprawdź serwer zaplecza pod kątem problemów związanych z aplikacjami, które uniemożliwiają klientom ustanowienie sesji TCP na skonfigurowanych portach. Kilka rzeczy do sprawdzenia:

   a. Otwórz wiersz polecenia (Win+R —> cmd), wprowadź ciąg netstat i wybierz klawisz Enter.

   b. Sprawdź, czy serwer nasłuchuje na skonfigurowanym porcie. Na przykład:

           Proto Local Address Foreign Address State PID
           TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
   

   c. Jeśli nie nasłuchuje na skonfigurowanym porcie, sprawdź ustawienia serwera internetowego. Na przykład: powiązania lokacji w usługach IIS, blok serwera w serwerach NGINX i host wirtualny w systemie Apache.

   d. Sprawdź ustawienia zapory systemu operacyjnego, aby upewnić się, że ruch przychodzący do portu jest dozwolony.

Niezgodność kodu stanu HTTP

Komunikat: Kod stanu odpowiedzi HTTP zaplecza nie był zgodny z ustawieniem sondy. Oczekiwano:{HTTPStatusCode0} Odebrano:{HTTPStatusCode1}.

Przyczyna: Po nawiązaniu połączenia przy użyciu protokołu TCP i uzgodnieniu protokołu TLS (jeśli protokół TLS jest włączony), usługa Application Gateway wyśle sondę jako żądanie HTTP GET do serwera wewnętrznej bazy danych. Jak opisano wcześniej, domyślna sonda będzie mieć <protocol>://127.0.0.1:<port>/wartość i uwzględnia kody stanu odpowiedzi w zakresie od 200 do 399 jako w dobrej kondycji. Jeśli serwer zwróci inny kod stanu, zostanie oznaczony jako W złej kondycji z tym komunikatem.

Rozwiązanie: w zależności od kodu odpowiedzi serwera zaplecza można wykonać następujące kroki. Poniżej wymieniono kilka typowych kodów stanu:

Jeśli jednak uważasz, że odpowiedź jest prawidłowa i chcesz, aby usługa Application Gateway akceptowała inne kody stanu jako w dobrej kondycji, możesz utworzyć niestandardową sondę. Takie podejście jest przydatne w sytuacjach, w których witryna internetowa zaplecza wymaga uwierzytelniania. Ponieważ żądania sondy nie niosą żadnych poświadczeń użytkownika, zakończy się niepowodzeniem, a kod stanu HTTP 401 zostanie zwrócony przez serwer zaplecza.

Aby utworzyć sondę niestandardową, wykonaj następujące kroki.

Niezgodność treści odpowiedzi HTTP

Komunikat: Treść odpowiedzi HTTP zaplecza nie jest zgodna z ustawieniem sondy. Odebrana treść odpowiedzi nie zawiera ciągu {string}.

Przyczyna: Podczas tworzenia sondy niestandardowej można oznaczyć serwer zaplecza jako w dobrej kondycji dopasowując ciąg znaków z treści odpowiedzi. Na przykład możesz skonfigurować usługę Application Gateway, aby akceptowała wartości „nieautoryzowane” jako ciąg do dopasowania. Jeśli odpowiedź serwera zaplecza dla żądania sondy zawiera ciąg nieautoryzowany, oznacza go jako w dobrej kondycji. W przeciwnym razie jest on oznaczony jako W złej kondycji z danym komunikatem.

Rozwiązanie: Aby rozwiązać ten problem, wykonaj następujące kroki:

1. Uzyskaj dostęp do serwera zaplecza lokalnie lub z komputera klienckiego na ścieżce sondy i sprawdź treść odpowiedzi.
2. Sprawdź, czy treść odpowiedzi w niestandardowej konfiguracji sondy usługi Application Gateway jest zgodna ze skonfigurowaną.
3. Jeśli nie są one zgodne, zmień konfigurację sondy tak, aby akceptowała prawidłową wartość ciągu.

Dowiedz się więcej o dopasowywaniu sondy usługi Application Gateway.

Nazwa pospolita (CN) jest niezgodna

Komunikat: (W przypadku wersji 2) Nazwa pospolita certyfikatu liścia przedstawionego przez serwer zaplecza nie jest zgodna z nazwą hosta sondy lub ustawienia zaplecza bramy aplikacji.
(Dla wersji 1) Nazwa pospolita certyfikatu zaplecza jest niezgodna.

Przyczyna: : (dla wersji 2) Dzieje się tak, gdy wybrano protokół HTTPS w ustawieniach wewnętrznej bazy danych, a ani nazwa hosta sondy niestandardowej, ani ustawienia wewnętrznej bazy danych (w tej kolejności) nie są zgodne z nazwą wspólną (CN) certyfikatu serwera wewnętrznej bazy danych.
(Dla wersji 1) Nazwa FQDN obiektu docelowego puli zaplecza jest niezgodna z nazwą pospolitą certyfikatu serwera zaplecza.

Rozwiązanie: informacje o nazwie hosta mają krytyczne znaczenie dla połączenia HTTPS zaplecza, ponieważ ta wartość jest używana do ustawiania wskazania nazwy serwera (SNI) podczas uzgadniania protokołu TLS. Ten problem można rozwiązać w następujący sposób na podstawie konfiguracji bramy.

W przypadku wersji 2

• Jeśli używasz sondy domyślnej — możesz określić nazwę hosta w skojarzonym ustawieniu zaplecza bramy aplikacji. W ustawieniu zaplecza możesz wybrać pozycję "Zastąpij z określoną nazwą hosta" lub "Wybierz nazwę hosta z obiektu docelowego zaplecza".
• Jeśli używasz sondy niestandardowej — dla sondy niestandardowej, możesz użyć pola "host", aby określić nazwę pospolitą certyfikatu serwera zaplecza. Alternatywnie, jeśli ustawienie zaplecza jest już skonfigurowane z tą samą nazwą hosta, możesz wybrać opcję "Wybierz nazwę hosta z ustawienia zaplecza" w ustawieniach sondy.

W przypadku wersji 1 sprawdź, czy nazwa FQDN docelowej puli zaplecza jest taka sama jak nazwa pospolita (CN).

Wskazówki: Aby określić nazwę pospolitą (CN) certyfikatu serwera zaplecza, można użyć dowolnej z tych metod. Należy również pamiętać, że zgodnie z RFC 6125 , jeśli sieć SAN istnieje weryfikacja SNI jest wykonywana tylko względem tego pola. Pole nazwy pospolitej jest zgodne, jeśli w certyfikacie nie ma sieci SAN.

• Za pomocą przeglądarki lub dowolnego klienta: uzyskaj bezpośredni dostęp do serwera zaplecza (nie za pośrednictwem usługi Application Gateway) i kliknij kłódkę certyfikatu na pasku adresu, aby wyświetlić szczegóły certyfikatu. Znajdziesz go w sekcji "Wystawiono do".

• Logując się do serwera zaplecza (Windows):

  1. Zaloguj się do maszyny, na której jest hostowana aplikacja.
  2. Wybierz pozycję Win+R lub kliknij prawym przyciskiem myszy przycisk Start i wybierz polecenie Uruchom.
  3. Wprowadź ciąg certlm.msc i wybierz klawisz Enter. Możesz również wyszukać Menedżera certyfikatów w menu Start.
  4. Znajdź certyfikat (zazwyczaj w obszarze Certyfikaty — komputer lokalny\Osobiste\Certyfikaty) i otwórz certyfikat.
  5. Na karcie Szczegóły sprawdź temat certyfikatu.

• Logując się do serwera zaplecza (Linux): uruchom to polecenie OpenSSL, określając właściwą nazwę pliku certyfikatu openssl x509 -in certificate.crt -subject -noout

Certyfikat zaplecza wygasł

Komunikat: Certyfikat zaplecza jest nieprawidłowy. Bieżąca data nie mieści się w zakresie dat "Ważny od" i "Ważny do" w certyfikacie.

Przyczyna: Wygasły certyfikat jest uznawany za niebezpieczny, dlatego serwer wewnętrznej bazy danych z wygasłym certyfikatem jest oznaczony przez bramę aplikacji jako znajdujący się w złej kondycji.

Rozwiązanie: rozwiązanie zależy od tego, która część łańcucha certyfikatów wygasła na serwerze zaplecza.

W przypadku jednostki SKU w wersji 2

• Wygasły certyfikat liścia (znany również jako domena lub serwer) — odnawianie certyfikatu serwera za pomocą dostawcy certyfikatów i instalowanie nowego certyfikatu na serwerze zaplecza. Upewnij się, że zainstalowano kompletny łańcuch certyfikatów składający się z .Leaf (topmost) > Intermediate(s) > Root Na podstawie typu urzędu certyfikacji możesz wykonać następujące akcje w bramie.

  • Publicznie znany urząd certyfikacji: jeśli wystawca certyfikatu jest dobrze znanym urzędem certyfikacji, nie musisz podejmować żadnych działań w bramie aplikacji.
  • Prywatny urząd certyfikacji: jeśli certyfikat liścia jest wystawiony przez prywatny urząd certyfikacji, należy sprawdzić, czy certyfikat głównego urzędu certyfikacji podpisywania uległ zmianie. W takich przypadkach należy przekazać nowy certyfikat głównego urzędu certyfikacji (. CER) ze skojarzonym ustawieniem zaplecza bramy.

• Wygasły certyfikat pośredni lub główny — zazwyczaj te certyfikaty mają stosunkowo przedłużone okresy ważności (dziesięć lub dwa). Po wygaśnięciu certyfikatu głównego/pośredniego zalecamy sprawdzenie dostawcy certyfikatów pod kątem odnowionych plików certyfikatów. Upewnij się, że zainstalowano ten zaktualizowany i kompletny łańcuch certyfikatów składający się Leaf (topmost) > Intermediate(s) > Root na serwerze zaplecza.

  • Jeśli certyfikat główny pozostanie niezmieniony lub jeśli wystawca jest dobrze znanym urzędem certyfikacji, nie musisz podejmować żadnych działań w bramie aplikacji.
  • W przypadku korzystania z prywatnego urzędu certyfikacji, jeśli certyfikat głównego urzędu certyfikacji lub katalog główny odnowionego certyfikatu pośredniego uległ zmianie, należy przekazać nowy certyfikat główny do ustawienia zaplecza bramy aplikacji.

W przypadku jednostki SKU w wersji 1

• Odnów wygasły certyfikat liścia (znany również jako domena lub serwer) przy użyciu urzędu certyfikacji i przekaż ten sam certyfikat liścia (. CER) do skojarzonego ustawienia zaplecza bramy aplikacji.

Nie można odnaleźć certyfikatu pośredniego

Komunikat:Brak certyfikatu pośredniego w łańcuchu certyfikatów przedstawionym przez serwer zaplecza. Upewnij się, że łańcuch certyfikatów został ukończony i poprawnie uporządkowany na serwerze zaplecza.

Przyczyna: Certyfikaty pośrednie nie są zainstalowane w łańcuchu certyfikatów na serwerze zaplecza.

Rozwiązanie: Certyfikat pośredni jest używany do podpisywania certyfikatu liścia i dlatego jest potrzebny do ukończenia łańcucha. Skontaktuj się ze swoim urzędem certyfikacji w celu uzyskania niezbędnych certyfikatów pośrednich i zainstaluj je na serwerze zaplecza. Ten łańcuch musi zaczynać się od certyfikatu typu liść, następnie certyfikatów pośrednich, a na końcu certyfikatu głównego urzędu certyfikacji. Zalecamy zainstalowanie pełnego łańcucha na serwerze zaplecza, w tym certyfikatu głównego urzędu certyfikacji. Dla porównania, spójrz na przykład łańcucha certyfikatów w sekcji Liść musi być najwyższy w łańcuchu.

Te obrazy pokazują różnicę między certyfikatami z podpisem własnym.

Nie można odnaleźć certyfikatu liścia lub serwera

Komunikat:Brak certyfikatu liścia w łańcuchu certyfikatów przedstawionym przez serwer zaplecza. Upewnij się, że łańcuch został ukończony i poprawnie uporządkowany na serwerze zaplecza.

Przyczyna: Brak certyfikatu typu liść (znanego również jako domena lub serwer) w łańcuchu certyfikatów na serwerze wewnętrznej bazy danych.

Rozwiązanie: certyfikat liścia można pobrać z urzędu certyfikacji. Zainstaluj ten certyfikat typu liść i wszystkie jego certyfikaty podpisywania (certyfikaty pośredniego i głównego urzędu certyfikacji) na serwerze wewnętrznej bazy danych. Ten łańcuch musi zaczynać się od certyfikatu typu liść, następnie certyfikatów pośrednich, a na końcu certyfikatu głównego urzędu certyfikacji. Zalecamy zainstalowanie pełnego łańcucha na serwerze zaplecza, w tym certyfikatu głównego urzędu certyfikacji. Dla porównania, spójrz na przykład łańcucha certyfikatów w sekcji Liść musi być najwyższy w łańcuchu.

Certyfikat serwera nie jest wystawiany przez publicznie znany urząd certyfikacji

Komunikat: Certyfikat serwera zaplecza nie jest podpisany przez dobrze znany urząd certyfikacji. Aby można było używać nieznanych certyfikatów urzędu certyfikacji, należy przekazać jego certyfikat główny do ustawienia zaplecza bramy aplikacji.

Przyczyna: Wybrano "dobrze znany certyfikat urzędu certyfikacji" w ustawieniu zaplecza, ale certyfikat główny przedstawiony przez serwer zaplecza nie jest publicznie znany.

Rozwiązanie: jeśli certyfikat liścia jest wystawiany przez prywatny urząd certyfikacji, certyfikat głównego urzędu certyfikacji podpisywania musi zostać przekazany do skojarzonego ustawienia zaplecza bramy aplikacji. Dzięki temu Twoja brama aplikacji może ustanowić zaufane połączenie z tym serwerem zaplecza. Aby rozwiązać ten problem, przejdź do skojarzonego ustawienia zaplecza, wybierz pozycję „nie jest dobrze znanym urzędem certyfikacji” i przekaż certyfikat głównego urzędu certyfikacji (.CER). Aby zidentyfikować i pobrać certyfikat główny, możesz wykonać te same kroki co opisane w sekcji Niezgodność zaufanego certyfikatu głównego.

Certyfikat pośredniczący nie jest podpisany przez publicznie znany urząd certyfikacji.

Komunikat:Certyfikat pośredni nie jest podpisany przez dobrze znany urząd certyfikacji. Upewnij się, że łańcuch certyfikatów został ukończony i poprawnie uporządkowany na serwerze zaplecza.

Przyczyna: Wybrano "dobrze znany certyfikat urzędu certyfikacji" w ustawieniu zaplecza, ale certyfikat pośredni przedstawiony przez serwer zaplecza nie jest podpisany przez żaden publicznie znany urząd certyfikacji.

Rozwiązanie: po wystawieniu certyfikatu przez prywatny urząd certyfikacji certyfikat musi zostać przekazany certyfikat głównego urzędu certyfikacji podpisywania do skojarzonego ustawienia zaplecza bramy aplikacji. Dzięki temu Twoja brama aplikacji może ustanowić zaufane połączenie z tym serwerem zaplecza. Aby rozwiązać ten problem, skontaktuj się z prywatnym urzędem certyfikacji, aby uzyskać odpowiedni certyfikat głównego urzędu certyfikacji (. CER) i przekaż ten plik . Plik CER do ustawienia zaplecza bramy aplikacji, wybierając pozycję "nie jest dobrze znanym urzędem certyfikacji". W celu łatwej weryfikacji zalecamy też zainstalowanie pełnego łańcucha na serwerze zaplecza, w tym certyfikatu głównego urzędu certyfikacji.

Niezgodność zaufanego certyfikatu głównego (brak certyfikatu głównego na serwerze zaplecza)

Komunikat: Certyfikat pośredniczący nie jest podpisany przez żadne certyfikaty główne przekazane do bramy aplikacji. Upewnij się, że łańcuch certyfikatów został ukończony i poprawnie uporządkowany na serwerze zaplecza.

Przyczyna: Żaden z certyfikatów głównego urzędu certyfikacji przekazanych do skojarzonego ustawienia zaplecza nie podpisał certyfikatu pośredniego zainstalowanego na serwerze zaplecza. Serwer zaplecza ma zainstalowane tylko certyfikaty typu liść i certyfikaty pośrednie.

Rozwiązanie: Certyfikat liścia jest podpisany przez certyfikat pośredni, który jest podpisany przez certyfikat głównego urzędu certyfikacji. W przypadku korzystania z certyfikatu z prywatnego urzędu certyfikacji (CA) należy przekazać odpowiedni certyfikat głównego urzędu certyfikacji do bramy aplikacji. Skontaktuj się z swoim prywatnym urzędem certyfikacji, aby uzyskać odpowiedni certyfikat głównego urzędu certyfikacji (. CER) i przekaż ten plik CER do ustawienia zaplecza bramy aplikacji.

Niezgodność zaufanego certyfikatu głównego (certyfikat główny jest dostępny na serwerze zaplecza)

Komunikat: Certyfikat główny certyfikatu serwera używanego przez zaplecze nie jest zgodny z zaufanym certyfikatem głównym dodanym do bramy aplikacji. Upewnij się, że dodano prawidłowy certyfikat główny, aby zezwolić na listę zaplecza.

Przyczyna: ten błąd występuje, gdy żadne z certyfikatów głównych przekazanych do ustawienia zaplecza bramy aplikacji jest zgodne z certyfikatem głównym obecnym na serwerze zaplecza.

Rozwiązanie: dotyczy to certyfikatu serwera zaplecza wystawionego przez prywatny urząd certyfikacji lub jest z podpisem własnym. Zidentyfikuj i przekaż odpowiedni certyfikat głównego urzędu certyfikacji do skojarzonego ustawienia zaplecza.

Wskazówki: Aby zidentyfikować i pobrać certyfikat główny, możesz użyć dowolnej z tych metod.

• Za pomocą przeglądarki: uzyskaj bezpośredni dostęp do serwera zaplecza (a nie za pośrednictwem usługi Application Gateway) i kliknij kłódkę certyfikatu na pasku adresu, aby wyświetlić szczegóły certyfikatu.

  1. Wybierz certyfikat główny w łańcuchu i kliknij pozycję Eksportuj. Domyślnie będzie to . Plik CRT.
  2. Otwórz ten plik . Plik CRT.
  3. Przejdź do karty Szczegóły i kliknij pozycję "Kopiuj do pliku",
  4. Na stronie Kreator eksportu certyfikatów kliknij przycisk Dalej.
  5. Wybierz pozycję "Kodowane w formacie Base-64 X.509 (. CER) i kliknij przycisk Dalej,
  6. Nadaj nowej nazwie pliku i kliknij przycisk Dalej.
  7. Kliknij przycisk Zakończ, aby uzyskać element . Plik CER.
  8. Przekaż ten certyfikat główny (. CER) prywatnego urzędu certyfikacji do ustawienia zaplecza bramy aplikacji.

• Logując się do serwera zaplecza (Windows)

  1. Zaloguj się do maszyny, na której jest hostowana aplikacja.
  2. Wybierz pozycję Win+R lub kliknij prawym przyciskiem myszy przycisk Start, a następnie wybierz polecenie Uruchom.
  3. Wprowadź ciąg certlm.msc i wybierz klawisz Enter. Możesz również wyszukać Menedżera certyfikatów w menu Start.
  4. Znajdź certyfikat, zazwyczaj w obszarze Certyfikaty — Komputer lokalny\Osobiste\Certyfikaty i otwórz go.
  5. Wybierz certyfikat główny, a następnie wybierz pozycję Wyświetl certyfikat.
  6. We właściwościach certyfikatu wybierz kartę Szczegóły i kliknij pozycję "Kopiuj do pliku",
  7. Na stronie Kreator eksportu certyfikatów kliknij przycisk Dalej.
  8. Wybierz pozycję "Kodowane w formacie Base-64 X.509 (. CER) i kliknij przycisk Dalej,
  9. Nadaj nowej nazwie pliku i kliknij przycisk Dalej.
  10. Kliknij przycisk Zakończ, aby uzyskać element . Plik CER.
  11. Przekaż ten certyfikat główny (. CER) prywatnego urzędu certyfikacji do ustawienia zaplecza bramy aplikacji.

Liść musi być najbardziej górny w łańcuchu.

Komunikat: Certyfikat liścia nie jest najwyższym certyfikatem w łańcuchu przedstawionym przez serwer zaplecza. Upewnij się, że łańcuch certyfikatów jest poprawnie uporządkowany na serwerze zaplecza.

Przyczyna: Certyfikat liścia (znany również jako domena lub serwer) nie jest zainstalowany w prawidłowej kolejności na serwerze zaplecza.

Rozwiązanie: Instalacja certyfikatu na serwerze zaplecza musi zawierać uporządkowaną listę certyfikatów składających się z certyfikatu liścia i wszystkich certyfikatów podpisywania (certyfikaty pośrednie i główne urzędu certyfikacji). Łańcuch ten musi zaczynać się od certyfikatu typu liść, następnie certyfikatu(-ów) pośredniego(-ych), a na końcu certyfikatu głównego urzędu certyfikacji. Zalecamy zainstalowanie pełnego łańcucha na serwerze zaplecza, w tym certyfikatu głównego urzędu certyfikacji.

Biorąc pod uwagę przykład instalacji certyfikatu serwera wraz z certyfikatami pośredniego i głównego urzędu certyfikacji, oznaczony jako głębokości (0, 1, 2 itd.) w programie OpenSSL. Możesz sprawdzić to samo dla certyfikatu serwera zaplecza przy użyciu następujących poleceń OpenSSL.
s_client -connect <FQDN>:443 -showcerts
LUB
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Weryfikacja certyfikatu nie powiodła się

Komunikat: Nie można zweryfikować ważności certyfikatu zaplecza. Aby sprawdzić przyczynę, sprawdź diagnostykę protokołu OpenSSL dla komunikatu skojarzonego z kodem błędu {errorCode}

Przyczyna: Ten błąd występuje, gdy usługa Application Gateway nie może zweryfikować ważności certyfikatu.

Rozwiązanie: Aby rozwiązać ten problem, sprawdź, czy certyfikat na serwerze został prawidłowo utworzony. Możesz na przykład użyć protokołu OpenSSL do zweryfikowania certyfikatu i jego właściwości, a następnie spróbować ponownie załadować certyfikat do ustawień protokołu HTTP usługi Azure Application Gateway.

Stan kondycji zaplecza: Nieznany

Aktualizacje do wpisów DNS puli zaplecza

Komunikat: nie można pobrać stanu kondycji zaplecza. Dzieje się tak, gdy sieciowa grupa zabezpieczeń/trasa zdefiniowana przez użytkownika/zapora w podsieci bramy aplikacji blokuje ruch na portach 65503–65534 w przypadku jednostki SKU w wersji 1, a porty 65200–65535 w przypadku jednostki SKU w wersji 2 lub jeśli nazwa FQDN skonfigurowana w puli zaplecza nie może zostać rozpoznana jako adres IP. Aby dowiedzieć się więcej, odwiedź stronę — https://aka.ms/UnknownBackendHealth.

Przyczyna: W przypadku obiektów docelowych zaplecza opartych na w pełni kwalifikowanej nazwy domeny nazwa FQDN usługa Application Gateway buforuje i używa ostatniego dobrego adresu IP, jeśli nie otrzyma odpowiedzi na kolejne wyszukiwanie DNS. Operacja PUT na bramie w tym stanie spowoduje całkowite wyczyszczenie pamięci podręcznej DNS. W związku z tym nie będzie żadnego adresu docelowego, z którym brama może się połączyć.

Rozwiązanie: Sprawdź i napraw serwery DNS, aby upewnić się, że obsługuje odpowiedź dla danego wyszukiwania DNS nazwy FDQN. Należy również sprawdzić, czy serwery DNS są dostępne za pośrednictwem sieci wirtualnej bramy aplikacji.

Inne przyczyny

Jeśli kondycja zaplecza jest wyświetlana jako Nieznany, widok portalu będzie wyglądać podobnie do poniższego zrzutu ekranu:

To zachowanie może wystąpić z jednej lub kilku następujących przyczyn:

1. Sieciowa grupa zabezpieczeń w podsieci usługi Application Gateway blokuje dostęp przychodzący do portów 65503-65534 (jednostka SKU w wersji 1) lub 65200-65535 (jednostka SKU w wersji 2) z "Internetu".
2. Trasa zdefiniowana przez użytkownika w podsieci usługi Application Gateway jest ustawiona na trasę domyślną (0.0.0.0/0), a następny przeskok nie jest określony jako "Internet".
3. Trasa domyślna jest ogłaszana przez połączenie ExpressRoute/VPN z siecią wirtualną za pośrednictwem protokołu BGP.
4. Niestandardowy serwer DNS jest skonfigurowany w sieci wirtualnej, która nie może rozpoznać nazw domen publicznych.
5. Usługa Application Gateway znajduje się w złej kondycji.

Rozwiązanie 2.

1. Sprawdź, czy sieciowa grupa zabezpieczeń blokuje dostęp do portów 65503-65534 (jednostka SKU w wersji 1) lub 65200-65535 (jednostka SKU w wersji 2) z Internetu:

   a. Na karcie Przegląd usługi Application Gateway wybierz link Sieć wirtualna/Podsieć. b. Na karcie Podsieci sieci wirtualnej wybierz podsieć, w której wdrożono usługę Application Gateway. c. Sprawdź, czy skonfigurowano dowolną sieciową grupę zabezpieczeń. d. Jeśli sieciowa grupa zabezpieczeń jest skonfigurowana, wyszukaj ten zasób sieciowej grupy zabezpieczeń na karcie Wyszukiwanie lub w obszarze Wszystkie zasoby. e. W sekcji Reguły ruchu przychodzącego dodaj regułę ruchu przychodzącego, aby zezwolić na docelowy zakres portów 65503-65534 dla jednostki SKU w wersji 1 lub 65200-65535 v2 z zestawem źródłowym jako tag usługi GatewayManager. f. Wybierz pozycję Zapisz i sprawdź, czy możesz wyświetlić zaplecze jako w dobrej kondycji. Alternatywnie możesz to zrobić za pomocą programu PowerShell/interfejsu wiersza polecenia.

2. Sprawdź, czy trasa zdefiniowana przez użytkownika ma trasę domyślną (0.0.0.0/0) z następnym przeskokiem nie ustawioną jako Internet:

   a. Wykonaj kroki 1a i 1b, aby określić podsieć. b. Sprawdź, czy skonfigurowano trasę zdefiniowaną przez użytkownika. Jeśli istnieje, wyszukaj zasób na pasku wyszukiwania lub w obszarze Wszystkie zasoby. c. Sprawdź, czy istnieją trasy domyślne (0.0.0.0.0/0) z następnym przeskokiem nie ustawiono jako Internet. Jeśli ustawienie to urządzenie wirtualne lub brama sieci wirtualnej, należy upewnić się, że urządzenie wirtualne lub urządzenie lokalne może prawidłowo kierować pakiet z powrotem do miejsca docelowego Internetu bez modyfikowania pakietu. Jeśli sondy są kierowane przez urządzenie wirtualne i modyfikowane, zasób zaplecza wyświetli kod stanu 200 , a stan kondycji usługi Application Gateway może być wyświetlany jako Nieznany. Nie wskazuje to błędu. Ruch nadal powinien być kierowany przez usługę Application Gateway bez problemu. d. W przeciwnym razie zmień następny przeskok do Internetu, wybierz pozycję Zapisz i sprawdź kondycję zaplecza.

3. Trasa domyślna anonsowana przez połączenie usługi ExpressRoute/VPN z siecią wirtualną za pośrednictwem protokołu BGP (Border Gateway Protocol):

   a. Jeśli masz połączenie usługi ExpressRoute/VPN z siecią wirtualną za pośrednictwem protokołu BGP, a jeśli anonsujesz trasę domyślną, upewnij się, że pakiet jest kierowany z powrotem do miejsca docelowego internetu bez modyfikowania go. Aby sprawdzić, możesz użyć opcji Rozwiązywanie problemów z Połączenie ion w portalu usługi Application Gateway. b. Wybierz miejsce docelowe ręcznie jako dowolny adres IP routingu internetowego, taki jak 1.1.1.1. Ustaw port docelowy jako dowolny i zweryfikuj łączność. c. Jeśli następny przeskok to brama sieci wirtualnej, może istnieć trasa domyślna anonsowana za pośrednictwem usługi ExpressRoute lub sieci VPN.

4. Jeśli w sieci wirtualnej skonfigurowano niestandardowy serwer DNS, sprawdź, czy serwery mogą rozpoznawać domeny publiczne. Rozpoznawanie nazw domen publicznych może być wymagane w scenariuszach, w których usługa Application Gateway musi skontaktować się z domenami zewnętrznymi, takimi jak serwery OCSP (protokół stanu certyfikatu online) lub sprawdzić stan odwołania certyfikatu.

5. Aby sprawdzić, czy usługa Application Gateway jest w dobrej kondycji i działa, przejdź do opcji Resource Health w portalu i sprawdź, czy stan jest w dobrej kondycji. Jeśli widzisz stan złej kondycji lub obniżonej wydajności, skontaktuj się z pomocą techniczną.

6. Jeśli ruch internetowy i prywatny przechodzi przez usługę Azure Firewall hostowaną w zabezpieczonym koncentratorze wirtualnym (przy użyciu usługi Azure Virtual WAN Hub):

   a. Aby upewnić się, że brama aplikacji może wysyłać ruch bezpośrednio do Internetu, skonfiguruj następującą trasę zdefiniowaną przez użytkownika:

   Prefiks adresu: 0.0.0.0/0
   Następny przeskok: Internet

   b. Aby upewnić się, że brama aplikacji może wysyłać ruch do puli zaplecza za pośrednictwem usługi Azure Firewall w koncentratorze usługi Virtual WAN, skonfiguruj następującą trasę zdefiniowaną przez użytkownika:

   Prefiks adresu: podsieć puli zaplecza
   Następny przeskok: prywatny adres IP usługi Azure Firewall

Następne kroki

Dowiedz się więcej na temat diagnostyki i rejestrowania usługi Application Gateway.