Share via

A háttérrendszer állapotával kapcsolatos problémák elhárítása az Application Gatewayben

  • Cikk

Áttekintés

Alapértelmezés szerint az Azure Application Gateway a háttérkiszolgálókon teszteket végezve ellenőrzi az állapotukat, hogy készen állnak-e a kérések kiszolgálására. A felhasználók egyéni mintavételeket is létrehozhatnak, hogy megemlítsék a gazdagép nevét, a mintavételhez használandó útvonalat és az állapotkódokat, hogy kifogástalan állapotúként fogadják el őket. Ha a háttérkiszolgáló nem válaszol sikeresen, az Application Gateway mindig Nem kifogástalan állapotúként jelöli meg a kiszolgálót, és nem továbbítja a kéréseket a kiszolgálónak. Miután a kiszolgáló sikeresen válaszol, az Application Gateway folytatja a kérések továbbítását.

Háttérrendszer állapotának ellenőrzése

A háttérkészlet állapotának ellenőrzéséhez használhatja a Háttéralkalmazás állapotadatai lapot az Azure Portalon. Vagy használhatja az Azure PowerShellt, a CLI-t vagy a REST API-t.

A metódusok bármelyike által lekért állapot az alábbi állapotok bármelyike lehet:

  • Kifogástalan
  • Nem kifogástalan
  • Ismeretlen

Az Application Gateway továbbítja a kérést egy kiszolgálónak a háttérkészletből, ha állapota kifogástalan. Ha a háttérkészlet összes kiszolgálója nem kifogástalan vagy ismeretlen, az ügyfelek problémákba ütközhetnek a háttéralkalmazás elérésekor. További információ a Háttérállapot által jelentett különböző üzenetekről, azok okairól és azok megoldásáról.

Feljegyzés

Ha a felhasználó nem rendelkezik engedéllyel a háttérrendszer állapotának megtekintéséhez, No results. megjelenik.

Háttérrendszer állapota: Nem kifogástalan

Ha a háttérrendszer állapota nem megfelelő, a portálnézet a következő képernyőképhez hasonlít:

Application Gateway backend health - Unhealthy

Ha Azure PowerShell-, CLI- vagy Azure REST API-lekérdezést használ, a következő példához hasonló választ kap:

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

Miután a háttérkészlet összes kiszolgálója sérült háttérkiszolgálói állapotot kap, a rendszer nem továbbítja a kéréseket a kiszolgálóknak, és az Application Gateway „502 Hibás átjáró” hibát ad vissza a kérelmező ügyfélnek. A probléma elhárításához ellenőrizze a Háttérállapot lap Részletek oszlopát.

A Részletek oszlopban megjelenő üzenet részletesebb információkat nyújt a problémáról, és ezek alapján megkezdheti a probléma elhárítását.

Feljegyzés

Az alapértelmezett mintavételi kérelmet a rendszer a következő protokollformátumban> küldi <el: ://127.0.0.1:<port>. Például http://127.0.0.1:80 egy HTTP-mintavételhez a 80-as porton. Csak a 200 és 399 között található HTTP-állapotkódok tekinthetők kifogástalannak. A protokollt és a célportot a HTTP-beállítások öröklik. Ha azt szeretné, hogy az Application Gateway egy másik protokollon, gazdagépnéven vagy elérési úton szondázzon, és egy másik állapotkódot kifogástalan állapotúként ismer fel, konfiguráljon egy egyéni mintavételt, és társítsa a HTTP-beállításokkal.

Hibaüzenetek

Háttérkiszolgáló időtúllépése

Üzenet: A háttéralkalmazás számára az alkalmazásátjáró állapottesztjére való reagáláshoz szükséges idő meghaladja a teszt beállításában megadott időkorlátot.

Ok: Miután az Application Gateway HTTP(S) teszt kérést küld a háttérkiszolgálónak, egy konfigurált időtartamig válaszra vár a háttérkiszolgálótól. Ha a háttérkiszolgáló nem válaszol a konfigurált időszakon (az időtúllépés értékén) belül, akkor a rendszer nem megfelelő állapotúként jelöli meg, amíg újra nem kezd válaszolni a konfigurált időtúllépés értékén belül.

Megoldás: Ellenőrizze, hogy a háttérkiszolgáló vagy alkalmazás miért nem válaszol a konfigurált időtúllépési értéken belül, és ellenőrizze az alkalmazásközi függőségeket is. Ellenőrizze például, hogy az adatbázisnak vannak-e olyan problémái, amelyek késleltethetik a válaszadást. Ha tisztában van az alkalmazás viselkedésével, és csak az időkorlát elérése után kell válaszolnia, növelje az időkorlát értékét az egyéni tesztelési beállításokban. Az időkorlát értékének módosításához egyéni tesztet kell használnia. Az egyéni mintavétel konfigurálásáról további információt a dokumentáció oldalán talál.

Az időtúllépési érték növeléséhez kövesse az alábbi lépéseket:

  1. Lépjen közvetlenül a háttérkiszolgálóra, és ellenőrizze, hogy mennyi idő alatt válaszoljon a kiszolgáló az adott lapon. Bármilyen eszközzel hozzáférhet a háttérkiszolgálóhoz, beleértve a fejlesztői eszközöket használó böngészőt is.
  2. Miután rájött, hogy mennyi idő alatt válaszoljon az alkalmazás, válassza az Állapotminták lapot, majd válassza ki a HTTP-beállításokhoz társított mintavételt.
  3. Adja meg az alkalmazás válaszidejét meghaladó időtúllépési értéket másodpercben.
  4. Mentse az egyéni mintavételi beállításokat, és ellenőrizze, hogy a háttérrendszer állapota kifogástalan állapotú-e.

DNS-feloldási hiba

Üzenet: Az Application Gateway nem tudott mintavételt létrehozni ehhez a háttérrendszerhez. Ez általában akkor fordul elő, ha a háttérrendszer teljes tartományneve nem lett megfelelően megadva. 

Ok: Ha a háttérkészlet IP-cím, teljes tartománynév (teljes tartománynév) vagy App Service típusú, az Application Gateway a DNS-n keresztül megadott teljes tartománynév (egyéni vagy Azure alapértelmezett) IP-címére oldódik fel. Az application gateway ezután megpróbál csatlakozni a kiszolgálóhoz a HTTP-beállításokban említett TCP-porton. Ha azonban megjelenik ez az üzenet, az azt jelzi, hogy az Application Gateway nem tudta feloldani a megadott teljes tartománynév IP-címét.

Megoldás:

  1. Ellenőrizze, hogy a háttérkészletben megadott teljes tartománynév helyes és nyilvános tartományé legyen, majd próbálja meg feloldani a helyi gépről.
  2. Ha meg tudja oldani az IP-címet, a virtuális hálózat DNS-konfigurációjával kapcsolatban hiba lehet.
  3. Ellenőrizze, hogy a virtuális hálózat egyéni DNS-kiszolgálóval van-e konfigurálva. Ha igen, ellenőrizze a DNS-kiszolgálót, hogy miért nem oldható fel a megadott teljes tartománynév IP-címére.
  4. Ha alapértelmezett Azure DNS-t használ, kérdezze meg a tartománynévregisztrálót arról, hogy a megfelelő A rekord vagy CNAME rekordleképezés befejeződött-e.
  5. Ha a tartomány privát vagy belső, próbálja meg feloldani egy virtuális gépről ugyanabban a virtuális hálózaton. Ha meg tudja oldani, indítsa újra az Application Gatewayt, és ellenőrizze újra. Az Application Gateway újraindításához le kell állítania és el kell indítania az ezekben a csatolt erőforrásokban leírt PowerShell-parancsokat.

TCP-csatlakozási hiba

Üzenet: Az Application Gateway nem tudott csatlakozni a háttéralkalmazáshoz. Ellenőrizze, hogy a háttéralkalmazás válaszol-e a teszteléshez használt porton. Azt is ellenőrizze, hogy az NSG/UDR/Tűzfal blokkolja-e a háttérkiszolgáló Ip-címéhez és portjához való hozzáférést.

Ok: A DNS-feloldási fázis után az Application Gateway megpróbál csatlakozni a háttérkiszolgálóhoz a HTTP-beállításokban konfigurált TCP-porton. Ha az Application Gateway nem tud TCP-munkamenetet létrehozni a megadott porton, akkor a teszt nem kifogástalanként lesz megjelölve ezzel az üzenettel.

Megoldás: Ha ezt a hibát kapja, kövesse az alábbi lépéseket:

  1. Ellenőrizze, hogy tud-e csatlakozni a háttérkiszolgálóhoz a HTTP-beállításokban említett porton böngésző vagy PowerShell használatával. Futtassa például a következő parancsot: Test-NetConnection -ComputerName www.bing.com -Port 443.

  2. Ha az említett port nem a kívánt port, adja meg az Application Gateway megfelelő portszámát a háttérkiszolgálóhoz való csatlakozáshoz.

  3. Ha a helyi gépről sem tud csatlakozni a porthoz, akkor:

    a. Ellenőrizze a háttérkiszolgáló hálózati adapterének és alhálózatának hálózati biztonsági csoportjának (NSG) beállításait, és hogy engedélyezettek-e a konfigurált port bejövő kapcsolatai. Ha nem, hozzon létre egy új szabályt a kapcsolatok engedélyezéséhez. Az NSG-szabályok létrehozásának módjáról a dokumentációs oldalon tájékozódhat.

    b. Ellenőrizze, hogy az Application Gateway alhálózat NSG-beállításai engedélyezik-e a kimenő nyilvános és privát forgalmat, hogy létre lehessen hozni a kapcsolatot. Az NSG-szabályok létrehozásáról a 3a. lépésben megadott dokumentumlapon tájékozódhat.

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

    c. Ellenőrizze az Application Gateway és a háttérkiszolgáló alhálózatának felhasználói útvonalbeállításait az útválasztási rendellenességekkel kapcsolatban. Győződjön meg arról, hogy az UDR nem a háttérbeli alhálózattól irányítja a forgalmat. Ellenőrizze például, hogy az Azure ExpressRoute-on és/vagy VPN-en keresztül az Application Gateway alhálózatán meghirdetett hálózati virtuális berendezésekhez vagy alapértelmezett útvonalakhoz vezet-e útvonalakat.

    d. A hálózati adapter érvényes útvonalainak és szabályainak ellenőrzéséhez a következő PowerShell-parancsokat használhatja:

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

  4. Ha nem találja az NSG-vel vagy az UDR-vel kapcsolatos problémákat, ellenőrizze a háttérkiszolgálón az alkalmazásokkal kapcsolatos problémákat, amelyek megakadályozzák, hogy az ügyfelek TCP-munkamenetet hozzanak létre a konfigurált portokon. Néhány dolog, amit ellenőrizni kell:

    a. Nyisson meg egy parancssort (Win+R -> cmd), írja be a netstat parancsot, és válassza az Enter lehetőséget.

    b. Ellenőrizze, hogy a kiszolgáló figyeli-e a konfigurált portot. Példa:

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

    c. Ha nem figyeli a konfigurált portot, ellenőrizze a webkiszolgáló beállításait. Például: helykötések az IIS-ben, kiszolgálóblokk az NGINX-ben és az Apache virtuális gazdagépe.

    d. Ellenőrizze az operációs rendszer tűzfalbeállításait, hogy engedélyezve legyen-e a portra irányuló bejövő forgalom.

A HTTP-állapotkód eltérése

Üzenet: A háttérrendszer HTTP-válaszának állapotkódja nem egyezett meg a mintavételi beállítással. Várt:{HTTPStatusCode0} érkezett:{HTTPStatusCode1}.

Cause: After the TCP connection has been established and a TLS handshake is done (if TLS is enabled), Application Gateway will send the probe as an HTTP GET request to the backend server. A korábban ismertetett módon az alapértelmezett mintavétel a következő lesz <protocol>://127.0.0.1:<port>/, és a 200–399 tartomány válaszállapot-kódjait kifogástalannak tekinti. Ha a kiszolgáló bármilyen más állapotkódot ad vissza, akkor az üzenet nem megfelelő állapotúként van megjelölve.

Megoldás: A háttérkiszolgáló válaszkódjától függően a következő lépéseket hajthatja végre. A gyakori állapotkódok közül néhányat itt talál:

Hiba Műveletek
A mintavétel állapotkódja nem egyezik: 401 érkezett Ellenőrizze, hogy a háttérkiszolgáló hitelesítést igényel-e. Az Application Gateway-mintavételek nem tudnak hitelesítő adatokat átadni a hitelesítéshez. Engedélyezze a "HTTP 401" értéket egy mintavételi állapotkódban, vagy egy olyan elérési utat válasszon, ahol a kiszolgáló nem igényel hitelesítést.
A mintavétel állapotkódja nem egyezik: 403-at kapott Hozzáférés tiltott. Ellenőrizze, hogy engedélyezett-e az elérési út elérése a háttérkiszolgálón.
A mintavétel állapotkódja nem egyezik: 404 érkezett A lap nem található. Ellenőrizze, hogy a gazdagépnév elérési útja elérhető-e a háttérkiszolgálón. Módosítsa a gazdagép nevét vagy elérési útját egy akadálymentes értékre.
A mintavétel állapotkódja nem egyezik: 405 érkezett Az Application Gateway mintavételi kérelmei a HTTP GET metódust használják. Ellenőrizze, hogy a kiszolgáló engedélyezi-e ezt a módszert.
A mintavétel állapotkódja nem egyezik: 500 érkezett Belső kiszolgálóhiba. Ellenőrizze a háttérkiszolgáló állapotát, és hogy a szolgáltatások futnak-e.
A mintavétel állapotkódja nem egyezik: 503-at kapott A szolgáltatás nem érhető el. Ellenőrizze a háttérkiszolgáló állapotát, és hogy a szolgáltatások futnak-e.

Ha úgy gondolja, hogy a válasz jogos, és azt szeretné, hogy az Application Gateway más állapotkódokat is elfogadjon kifogástalan állapotként, létrehozhat egy egyéni mintavételt. Ez a megközelítés olyan helyzetekben hasznos, amikor a háttérwebhellyel hitelesítésre van szükség. Mivel a mintavételi kérelmek nem rendelkeznek felhasználói hitelesítő adatokkal, sikertelenek lesznek, és a háttérkiszolgáló egy HTTP 401-állapotkódot ad vissza.

Egyéni mintavétel létrehozásához kövesse az alábbi lépéseket.

A HTTP-válasz törzsének eltérése

Üzenet: A háttérrendszer HTTP-válaszának törzse nem egyezett a mintavételi beállítással. A kapott választörzs nem tartalmazza a(z) {string} karakterláncot.

Ok: Egyéni szonda létrehozásakor a választestben található karakterlánc megfeleltetésével jelölhet meg egy háttértár-kiszolgálót Egészségesnek. Beállíthatja például, hogy az Application Gateway sztringként fogadja el a „jogosulatlan” értéket. Ha a mintavételi kérelem háttérkiszolgálói válasza nem engedélyezett sztringet tartalmaz, akkor kifogástalan állapotúként jelöli meg. Ellenkező esetben a megadott üzenet nem megfelelő állapotúként van megjelölve.

Megoldás: A probléma megoldásához kövesse az alábbi lépéseket:

  1. Lépjen a háttérkiszolgálóhoz helyileg vagy a mintavételi útvonal egyik ügyfélszámítógépéről, és ellenőrizze a válasz törzsét.
  2. Ellenőrizze, hogy az Application Gateway egyéni mintavételi konfigurációjának választörzse megegyezik-e a konfiguráltval.
  3. Ha nem egyeznek, módosítsa a mintavételi konfigurációt, hogy a megfelelő sztringértéket fogadja el.

További információ az Application Gateway mintavételezéséről.

Feljegyzés

Az összes TLS-hez kapcsolódó hibaüzenet esetén az SNI viselkedéséről és a v1 és a v2 termékváltozat közötti különbségekről a TLS áttekintési oldalán tájékozódhat.

A köznapi név (CN) nem egyezik

Üzenet: (V2 esetén) A háttérkiszolgáló által bemutatott levéltanúsítvány köznapi neve nem egyezik az Application Gateway mintavételi vagy háttérbeállítási állomásnevével.
(V1 esetén) A háttértanúsítvány köznapi neve (CN) nem egyezik.

Cause: (For V2) This occurs when you have selected HTTPS protocol in the backend setting, and neither the Custom Probe’s nor Backend Setting’s hostname (in that order) matches the Common Name (CN) of the backend server’s certificate.
(V1 esetén) A háttérkészlet-cél teljes tartományneve nem egyezik meg a háttérkiszolgáló tanúsítványának köznapi nevével (CN).

Megoldás: A gazdagépnév adatai kritikus fontosságúak a háttérbeli HTTPS-kapcsolat esetében, mivel ez az érték a kiszolgálónév-jelzés (SNI) beállítására szolgál a TLS-kézfogás során. Ezt a problémát az átjáró konfigurációja alapján az alábbi módokon háríthatja el.

V2 esetén

  • Ha alapértelmezett mintavételt használ – Az application gateway társított háttérbeállításában megadhatja a gazdagépnevet. A háttérbeállításban kiválaszthatja a "Felülbírálás adott gazdagépnévvel" vagy a "Gazdagépnév kiválasztása a háttérbeli célból" lehetőséget.
  • Ha egyéni mintavételt használ – Egyéni mintavételhez, a "gazdagép" mezővel megadhatja a háttérkiszolgáló tanúsítványának általános nevét. Másik lehetőségként, ha a háttérbeállítás már konfigurálva van ugyanazzal a gazdagépnévvel, a mintavételi beállítások között választhatja a "Gazdagépnév kiválasztása háttérbeállításból" lehetőséget.

V1 esetén ellenőrizze, hogy a háttérkészlet-tároló teljes tartományneve megegyezik-e a köznapi névvel (CN).

Tippek: A háttérkiszolgáló(k) tanúsítványának köznapi nevének (CN) meghatározásához az alábbi módszerek bármelyikét használhatja. Azt is vegye figyelembe, hogy az RFC 6125 szerint, ha létezik san, az SNI-ellenőrzés csak ezen a mezőn történik. A köznapi név mező akkor egyezik meg, ha nincs san a tanúsítványban.

  • Böngésző vagy bármely ügyfél használatával: Közvetlenül (nem az Application Gatewayen keresztül) nyissa meg a háttérkiszolgálót, és kattintson a címsávon található tanúsítvány lakatára a tanúsítvány részleteinek megtekintéséhez. Ezt a "Kibocsátva" szakaszban találja. Screenshot that shows certificate details in a browser.

  • A háttérkiszolgálóra (Windows) való bejelentkezéssel:

    1. Jelentkezzen be abba a gépre, ahol az alkalmazás üzemel.
    2. Válassza a Win+R lehetőséget, vagy kattintson a jobb gombbal a Start gombra, és válassza a Futtatás lehetőséget.
    3. Írja be a certlm.msc értéket, és válassza az Enter lehetőséget. A Start menüben a Tanúsítványkezelőt is megkeresheti.
    4. Keresse meg a tanúsítványt (általában a Tanúsítványok – Helyi számítógép\Személyes\Tanúsítványok területen), és nyissa meg a tanúsítványt.
    5. A Részletek lapon ellenőrizze a tanúsítvány tulajdonosát.

  • A háttérkiszolgálóra (Linux) való naplózással: Futtassa ezt az OpenSSL parancsot a megfelelő tanúsítványfájlnév megadásával openssl x509 -in certificate.crt -subject -noout

A háttértanúsítvány lejárt

Üzenet: A háttértanúsítvány érvénytelen. Az aktuális dátum nem szerepel a tanúsítvány "Érvényesség innen" és "Érvényes a következőhöz" dátumtartományában.

Cause: An expired certificate is deemed unsafe and hence the application gateway marks the backend server with an expired certificate as unhealthy.

Megoldás: A megoldás attól függ, hogy a tanúsítványlánc mely része járt le a háttérkiszolgálón.

V2 termékváltozat esetén:

  • Lejárt levéltanúsítvány (más néven tartomány vagy kiszolgáló) – Újítsa meg a kiszolgálótanúsítványt a tanúsítványszolgáltatóval, és telepítse az új tanúsítványt a háttérkiszolgálóra. Győződjön meg arról, hogy telepítette a teljes tanúsítványláncot, amely a következőből Leaf (topmost) > Intermediate(s) > Rootáll: . A hitelesítésszolgáltató (CA) típusától függően az alábbi műveleteket hajthatja végre az átjárón.

    • Nyilvánosan ismert hitelesítésszolgáltató: Ha a tanúsítványkibocsátó egy jól ismert hitelesítésszolgáltató, nem kell semmilyen műveletet elvégeznie az Application Gatewayen.
    • Privát hitelesítésszolgáltató: Ha a levéltanúsítványt egy magánhálózati hitelesítésszolgáltató állítja ki, ellenőriznie kell, hogy az aláíró legfelső szintű hitelesítésszolgáltató tanúsítványa megváltozott-e. Ilyen esetekben fel kell töltenie az új legfelső szintű hitelesítésszolgáltatói tanúsítványt (. CER) az átjáró társított háttérbeállítására.

  • Lejárt köztes vagy főtanúsítvány – Ezek a tanúsítványok általában viszonylag hosszabb érvényességi időszakokkal rendelkeznek (egy vagy két évtized). Ha a főtanúsítvány/köztes tanúsítvány lejár, javasoljuk, hogy ellenőrizze a tanúsítványszolgáltatónál a megújított tanúsítványfájlokat. Győződjön meg arról, hogy telepítette ezt a frissített és teljes tanúsítványláncot, amely a háttérkiszolgálón található Leaf (topmost) > Intermediate(s) > Root .

    • Ha a főtanúsítvány változatlan marad, vagy ha a kiállító egy jól ismert hitelesítésszolgáltató, akkor NEM kell semmilyen műveletet elvégeznie az application gatewayen.
    • Magánhálózati hitelesítésszolgáltató használata esetén, ha a legfelső szintű hitelesítésszolgáltató tanúsítványa vagy a megújított köztes tanúsítvány gyökere megváltozott, fel kell töltenie az új főtanúsítványt az Application Gateway háttérbeállításába.

V1 termékváltozat esetén:

  • Újítsa meg a lejárt levéltanúsítványt (más néven tartományt vagy kiszolgálót) a hitelesítésszolgáltatóval, és töltse fel ugyanazt a levéltanúsítványt (. CER) az application gateway társított háttérbeállításához.

A köztes tanúsítvány nem található

Üzenet: A köztes tanúsítvány hiányzik a háttérkiszolgáló által bemutatott tanúsítványláncból. Győződjön meg arról, hogy a tanúsítványlánc befejeződött és megfelelően van rendezve a háttérkiszolgálón.

Ok: A köztes tanúsítvány(ok) nincs telepítve a háttérkiszolgáló tanúsítványláncában.

Megoldás: A levéltanúsítvány aláírására egy köztes tanúsítvány szolgál, ezért a lánc befejezéséhez szükséges. Egyeztessen a hitelesítésszolgáltatóval (CA-val) a szükséges köztes tanúsítvány(ok)ról, és telepítse (őket) a háttérkiszolgálóra. Ennek a láncnak a levéltanúsítvánnyal kell kezdődnie, ezt követi(k) a köztes tanúsítvány(ok), majd a legfelső szintű hitelesítésszolgáltatói tanúsítványa. Javasoljuk, hogy telepítse a teljes láncot a háttérkiszolgálóra, beleértve a legfelső szintű hitelesítésszolgáltatói tanúsítványt is. Referenciaként tekintse meg a tanúsítványlánc példáját a Levélnek a legfelső láncnak kell lennie című témakör alatt.

Feljegyzés

A NEM hitelesítésszolgáltatónak számító önaláírt tanúsítványok szintén ugyanazt a hibát eredményezik. Ennek az az oka, hogy az Application Gateway az ilyen önaláírt tanúsítványt "Leaf" tanúsítványnak tekinti, és megkeresi annak aláíró köztes tanúsítványát. Ezt a cikket követve helyesen hozhat létre önaláírt tanúsítványt.

Ezek a képek az önaláírt tanúsítványok közötti különbséget mutatják. Screenshot showing difference between self-signed certificates.

A levél- vagy kiszolgálótanúsítvány nem található

Üzenet: A levéltanúsítvány hiányzik a háttérkiszolgáló által bemutatott tanúsítványláncból. Győződjön meg arról, hogy a lánc befejeződött és megfelelően van rendezve a háttérkiszolgálón.

Cause: The Leaf (also known as Domain or Server) certificate is missing from the certificate chain on the backend server.

Megoldás: A levéltanúsítványt a hitelesítésszolgáltatótól (CA) szerezheti be. Telepítse ezt a levéltanúsítványt és annak összes aláíró tanúsítványát (köztes és fő hitelesítésszolgáltatói tanúsítványokat) a háttérkiszolgálóra. Ennek a láncnak a levéltanúsítvánnyal kell kezdődnie, ezt követi(k) a köztes tanúsítvány(ok), majd a legfelső szintű hitelesítésszolgáltatói tanúsítványa. Javasoljuk, hogy telepítse a teljes láncot a háttérkiszolgálóra, beleértve a legfelső szintű hitelesítésszolgáltatói tanúsítványt is. Referenciaként tekintse meg a tanúsítványlánc példáját a Levélnek a legfelső láncnak kell lennie című témakör alatt.

A kiszolgálótanúsítványt nem nyilvánosan ismert hitelesítésszolgáltató állítja ki

Üzenet: A háttérkiszolgáló tanúsítványát nem egy jól ismert hitelesítésszolgáltató (CA) írja alá. Ismeretlen hitelesítésszolgáltatói tanúsítványok használatához a főtanúsítványt fel kell tölteni az Application Gateway háttérbeállításába.

Ok: A háttérbeállításban a "jól ismert hitelesítésszolgáltatói tanúsítványt" választotta, de a háttérkiszolgáló által bemutatott főtanúsítvány nyilvánosan nem ismert.

Megoldás: Ha a levéltanúsítványt egy magánhálózati hitelesítésszolgáltató állítja ki, az aláíró legfelső szintű hitelesítésszolgáltató tanúsítványát fel kell tölteni az Application Gateway társított háttérbeállításába. Ez lehetővé teszi, hogy az Application Gateway megbízható kapcsolatot létesítsen a háttérkiszolgálóval. A probléma megoldásához lépjen a társított háttérrendszer-beállításra, válassza a „nem egy jól ismert hitelesítésszolgáltató” lehetőséget, és töltse fel a legfelső szintű hitelesítésszolgáltatói tanúsítványt (.CER). A főtanúsítvány azonosításához és letöltéséhez kövesse a Megbízható főtanúsítvány eltérése című szakaszban ismertetett lépéseket.

A köztes tanúsítványt nem egy nyilvánosan ismert hitelesítésszolgáltató írja alá.

Üzenet: A köztes tanúsítványt nem egy jól ismert hitelesítésszolgáltató (CA) írja alá. Győződjön meg arról, hogy a tanúsítványlánc befejeződött és megfelelően van rendezve a háttérkiszolgálón.

Ok: A háttérbeállításban a "jól ismert hitelesítésszolgáltatói tanúsítványt" választotta, de a háttérkiszolgáló által bemutatott köztes tanúsítványt egyetlen nyilvánosan ismert hitelesítésszolgáltató sem írja alá.

Megoldás: Ha egy tanúsítványt egy magánhálózati hitelesítésszolgáltató állít ki, az aláíró legfelső szintű hitelesítésszolgáltató tanúsítványát fel kell tölteni az Application Gateway társított háttérbeállításába. Ez lehetővé teszi, hogy az Application Gateway megbízható kapcsolatot létesítsen a háttérkiszolgálóval. A probléma megoldásához forduljon a magánhálózati hitelesítésszolgáltatóhoz a megfelelő legfelső szintű hitelesítésszolgáltatói tanúsítvány beszerzéséhez (. CER) és töltse fel. CER-fájl az application gateway háttérbeállításához a "nem egy jól ismert hitelesítésszolgáltató" lehetőség kiválasztásával. Javasoljuk, hogy telepítse a teljes láncot a háttérkiszolgálóra, beleértve a legfelső szintű hitelesítésszolgáltatói tanúsítványt is az egyszerű megerősítés érdekében.

Megbízható főtanúsítvány eltérése (nincs főtanúsítvány a háttérkiszolgálón)

Üzenet: A köztes tanúsítványt nem írták alá az Application Gatewayre feltöltött főtanúsítványok. Győződjön meg arról, hogy a tanúsítványlánc befejeződött és megfelelően van rendezve a háttérkiszolgálón.

Cause: None of the Root CA certificates uploaded to the associated Backend Setting have signed the Intermediate certificate installed on the backend server. A háttérkiszolgálóra csak a Levél és a Köztes tanúsítványok vannak telepítve.

Megoldás: A Levéltanúsítványt egy köztes tanúsítvány írja alá, amelyet egy legfelső szintű hitelesítésszolgáltatói tanúsítvány ír alá. Magántanúsítvány (CA) használata esetén fel kell töltenie a megfelelő legfelső szintű hitelesítésszolgáltatói tanúsítványt az application gatewayre. Lépjen kapcsolatba a magánhálózati hitelesítésszolgáltatóval a megfelelő legfelső szintű hitelesítésszolgáltatói tanúsítvány beszerzéséhez (.CER) és töltse fel ezt a CER-fájlt az application gateway háttérbeállításába.

Megbízható főtanúsítvány eltérése (a főtanúsítvány elérhető a háttérkiszolgálón)

Üzenet: A háttérrendszer által használt kiszolgálói tanúsítvány főtanúsítványa nem egyezik az Application Gatewayhez hozzáadott megbízható főtanúsítványsal. Győződjön meg arról, hogy a megfelelő főtanúsítványt adja hozzá a háttérrendszer engedélyezéséhez.

Cause: This error occurs when none of the Root certificates uploaded to your application gateway’s backend setting matches the Root certificate present on the backend server.

Megoldás: Ez egy magántanúsítvány (CA) által kiadott háttérkiszolgáló-tanúsítványra vonatkozik, vagy önaláírt tanúsítvány. Azonosítsa és töltse fel a megfelelő legfelső szintű hitelesítésszolgáltatói tanúsítványt a társított háttérbeállításba.

Tippek: A főtanúsítvány azonosításához és letöltéséhez az alábbi módszerek bármelyikét használhatja.

  • Böngésző használata: Közvetlenül (nem az Application Gatewayen keresztül) nyissa meg a háttérkiszolgálót, és a címsávon kattintson a tanúsítvány lakatára a tanúsítvány részleteinek megtekintéséhez.

    1. Válassza ki a főtanúsítványt a láncban, és kattintson az Exportálás gombra. Alapértelmezés szerint ez egy . CRT-fájl.
    2. Nyissa meg. CRT-fájl.
    3. Lépjen a Részletek lapra, és kattintson a "Másolás fájlba" elemre,
    4. A Tanúsítványexportálási varázsló lapján kattintson a Tovább gombra,
    5. Válassza a "Base-64 kódolású X.509 (. CER) és kattintson a Tovább gombra,
    6. Adjon meg egy új fájlnevet, és kattintson a Tovább gombra,
    7. Kattintson a Befejezés gombra a beolvasáshoz. CER-fájl.
    8. Töltse fel ezt a főtanúsítványt (. HITELESÍTÉSSZOLGÁLTATÓ) az Application Gateway háttérbeállításához.

  • A háttérkiszolgálóra (Windows) való bejelentkezéssel

    1. Jelentkezzen be abba a gépre, ahol az alkalmazás üzemel.
    2. Válassza a Win+R billentyűkombinációt, vagy kattintson a jobb gombbal a Start gombra, majd válassza a Futtatás parancsot.
    3. Írja be a certlm.msc értéket, és válassza az Enter lehetőséget. A Start menüben a Tanúsítványkezelőt is megkeresheti.
    4. Keresse meg a tanúsítványt, általában a Tanúsítványok – Helyi számítógép\Személyes\Tanúsítványok területen, és nyissa meg.
    5. Válassza ki a főtanúsítványt, majd válassza a Tanúsítvány megtekintése lehetőséget.
    6. A Tanúsítvány tulajdonságai területen válassza a Részletek lapot, és kattintson a "Másolás fájlba" elemre.
    7. A Tanúsítványexportálási varázsló lapján kattintson a Tovább gombra,
    8. Válassza a "Base-64 kódolású X.509 (. CER) és kattintson a Tovább gombra,
    9. Adjon meg egy új fájlnevet, és kattintson a Tovább gombra,
    10. Kattintson a Befejezés gombra a beolvasáshoz. CER-fájl.
    11. Töltse fel ezt a főtanúsítványt (. HITELESÍTÉSSZOLGÁLTATÓ) az Application Gateway háttérbeállításához.

A levélnek a legfelül kell lennie a láncban.

Üzenet: A Levéltanúsítvány nem a legfelső tanúsítvány a háttérkiszolgáló által bemutatott láncban. Győződjön meg arról, hogy a tanúsítványlánc megfelelően van rendezve a háttérkiszolgálón.

Ok: A levéltanúsítvány (más néven tartomány vagy kiszolgáló) nincs a megfelelő sorrendben telepítve a háttérkiszolgálón.

Megoldás: A háttérkiszolgálón a tanúsítvány telepítésének tartalmaznia kell a levéltanúsítványt és annak összes aláíró tanúsítványát (köztes és legfelső szintű hitelesítésszolgáltatói tanúsítványokat) tartalmazó rendezett tanúsítványlistát. Ennek a láncnak a levéltanúsítvánnyal kell kezdődnie, ezt követi(k) a köztes tanúsítvány(ok), majd a legfelső szintű hitelesítésszolgáltatói tanúsítványa. Javasoljuk, hogy telepítse a teljes láncot a háttérkiszolgálóra, beleértve a legfelső szintű hitelesítésszolgáltatói tanúsítványt is.

A megadott példa egy kiszolgálótanúsítvány telepítésére a köztes és a legfelső szintű hitelesítésszolgáltatói tanúsítványokkal együtt, mélységként (0, 1, 2 stb.) jelölve az OpenSSL-ben. Ugyanezt az alábbi OpenSSL-parancsokkal ellenőrizheti a háttérkiszolgáló tanúsítványához.
s_client -connect <FQDN>:443 -showcerts
VAGY
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Screenshot showing typical chain of certificates.

A tanúsítvány ellenőrzése nem sikerült

Üzenet: A háttértanúsítvány érvényességét nem sikerült ellenőrizni. Az ok kiderítéséhez ellenőrizze az OpenSSL-diagnosztikát a(z) {errorCode} hibakódhoz társított üzenethez

Cause: This error occurs when Application Gateway can't verify the validity of the certificate.

Megoldás: A probléma megoldásához ellenőrizze, hogy a tanúsítvány megfelelően lett-e létrehozva a kiszolgálón. Például az OpenSSL használatával ellenőrizheti a tanúsítványt és annak tulajdonságait, majd megpróbálhatja újra feltölteni azt az Application Gateway HTTP-beállításainál.

Háttérrendszer állapota: Ismeretlen

Frissítések a háttérkészlet DNS-bejegyzéseihez

Üzenet: A háttérrendszer állapotának lekérése nem sikerült. Ez akkor fordul elő, ha az Application Gateway alhálózatán található NSG/UDR/Firewall blokkolja a forgalmat a 65503-65534-es portokon az 1-es verzió termékváltozata esetén, a 65200-65535-ös portot pedig a v2 termékváltozat esetében, vagy ha a háttérkészletben konfigurált teljes tartománynév nem oldható fel IP-címmel. További információkért látogasson el - https://aka.ms/UnknownBackendHealth.

Ok: FQDN -alapú (teljes tartománynév)-alapú háttérbeli célok esetén az Application Gateway gyorsítótárazza és az utolsó ismert jó IP-címet használja, ha nem kap választ a későbbi DNS-keresésre. Az ebben az állapotban lévő átjárón végzett PUT művelet teljesen törli a DNS-gyorsítótárát. Ennek eredményeképpen nem lesz olyan célcím, amelyhez az átjáró hozzáférhet.

Megoldás: Ellenőrizze és javítsa ki a DNS-kiszolgálókat, és győződjön meg arról, hogy az adott FDQN DNS-keresésére választ ad. Azt is ellenőriznie kell, hogy a DNS-kiszolgálók elérhetők-e az application gateway virtuális hálózatán keresztül.

Egyéb okok

Ha a háttérrendszer állapota Ismeretlenként jelenik meg, a portálnézet a következő képernyőképhez fog hasonlítni:

Application Gateway backend health - Unknown

Ez a viselkedés következő okok valamelyike miatt történhet:

  1. Az Application Gateway alhálózatán található NSG blokkolja a 65503-65534-65534-65534 -65200-65535 (v2 termékváltozat) portok bejövő elérését az "internetről".
  2. Az Application Gateway alhálózatán lévő UDR az alapértelmezett útvonalra van állítva (0.0.0.0/0), a következő ugrás pedig nincs megadva internetként.
  3. Az alapértelmezett útvonalat a virtuális hálózat ExpressRoute- vagy VPN-kapcsolata hirdeti meg a BGP-n keresztül.
  4. Az egyéni DNS-kiszolgáló olyan virtuális hálózaton van konfigurálva, amely nem tudja feloldani a nyilvános tartományneveket.
  5. Az Application Gateway állapota Nem megfelelő.

Solution

  1. Ellenőrizze, hogy az NSG blokkolja-e a 65503-65534 -65534-65534 -65200-65535 (v2 termékváltozat) internetről való elérését:

    a. Az Application Gateway Áttekintés lapján válassza a Virtuális hálózat/Alhálózat hivatkozást. b. A virtuális hálózat Alhálózatok lapján válassza ki azt az alhálózatot, amelyben az Application Gateway üzembe lett helyezve. c. Ellenőrizze, hogy az NSG konfigurálva van-e. d. Ha egy NSG van konfigurálva, keresse meg az adott NSG-erőforrást a Keresés lapon vagy a Minden erőforrás területen. e. A Bejövő szabályok szakaszban adjon hozzá egy bejövő szabályt, amely engedélyezi a 65503-65534-es célporttartományt az 1-es verziójú termékváltozathoz vagy a 65200-65535 v2 termékváltozathoz, amelynek forráskészleteGatewayManager szolgáltatáscímke. f. Válassza a Mentés lehetőséget, és ellenőrizze, hogy a háttérrendszer kifogástalan állapotú-e. Ezt a PowerShell/CLI használatával is megteheti.

  2. Ellenőrizze, hogy az UDR rendelkezik-e alapértelmezett útvonallal (0.0.0.0/0), és a következő ugrás nem internetként van beállítva:

    a. Az alhálózat meghatározásához kövesse az 1a. és az 1b. lépést. b. Ellenőrizze, hogy konfigurálva van-e UDR. Ha van ilyen, keresse meg az erőforrást a keresősávon vagy a Minden erőforrás területen. c. Ellenőrizze, hogy vannak-e alapértelmezett útvonalak (0.0.0.0/0), és a következő ugrás nem internetként van beállítva. Ha a beállítás virtuális berendezés vagy virtuális hálózati átjáró, győződjön meg arról, hogy a virtuális berendezés vagy a helyszíni eszköz megfelelően vissza tudja irányítani a csomagot az internetes célhelyre a csomag módosítása nélkül. Ha a mintavételeket egy virtuális berendezésen keresztül irányítják, és módosítják, a háttérerőforrás egy 200-as állapotkódot jelenít meg, és az Application Gateway állapota ismeretlenként jelenik meg. Ez nem jelez hibát. A forgalomnak továbbra is problémamentesen kell haladnia az Application Gatewayen keresztül. d. Ellenkező esetben módosítsa a következő ugrást az internetre, válassza a Mentés lehetőséget, és ellenőrizze a háttérrendszer állapotát.

  3. Az ExpressRoute/VPN-kapcsolat által meghirdetett alapértelmezett útvonal a BGP-n keresztüli virtuális hálózathoz (Border Gateway Protocol):

    a. Ha ExpressRoute-/VPN-kapcsolattal rendelkezik a BGP-n keresztüli virtuális hálózathoz, és ha alapértelmezett útvonalat hirdet, meg kell győződnie arról, hogy a csomag vissza lesz irányítva az internetes célhelyre módosítás nélkül. A Csatlakozás ion hibaelhárítási lehetőségével ellenőrizheti az Application Gateway portálon. b. Válassza ki manuálisan a célhelyet az 1.1.1.1-hez hasonló internetes ip-címként. Állítsa be a célportot bármiként, és ellenőrizze a kapcsolatot. c. Ha a következő ugrás a virtuális hálózati átjáró, előfordulhat, hogy az ExpressRoute-on vagy VPN-en keresztül meghirdetett alapértelmezett útvonal van meghirdetve.

  4. Ha a virtuális hálózaton egyéni DNS-kiszolgáló van konfigurálva, ellenőrizze, hogy a kiszolgálók feloldhatják-e a nyilvános tartományokat. Előfordulhat, hogy nyilvános tartománynévfeloldásra van szükség olyan esetekben, amikor az Application Gatewaynek külső tartományokat kell elérnie, például OCSP (Online tanúsítványállapot-protokoll) kiszolgálókat, vagy ellenőriznie kell a tanúsítvány visszavonási állapotát.

  5. Ha ellenőrizni szeretné, hogy az Application Gateway kifogástalan állapotban van-e és fut-e, lépjen a portál Resource Health beállítására, és ellenőrizze, hogy az állapot kifogástalan-e. Ha nem megfelelő vagy csökkentett állapotú állapotot lát, forduljon az ügyfélszolgálathoz.

  6. Ha az internet- és magánforgalom biztonságos virtuális központban (az Azure Virtual WAN Hub használatával) üzemeltetett Azure Firewallon halad át:

    a. Annak érdekében, hogy az Application Gateway közvetlenül az internetre küldjön forgalmat, konfigurálja a következő felhasználó által megadott útvonalat:

    Címelőtag: 0.0.0.0/0
    Következő ugrás: Internet

    b. Annak érdekében, hogy az Application Gateway forgalmat küldjön a háttérkészletbe a Virtual WAN-központban található Azure Firewallon keresztül, konfigurálja a következő felhasználó által megadott útvonalat:

    Címelőtag: Háttérkészlet alhálózata
    Következő ugrás: Az Azure Firewall privát IP-címe

Következő lépések

További információ az Application Gateway diagnosztikáról és naplózásról.