Risolvere i problemi di integrità del back-end nel gateway applicazione

Panoramica

Per impostazione predefinita, il gateway applicazione di Azure verifica tramite probe i server back-end per controllarne lo stato integrità e determinare se sono pronti per gestire le richieste. Gli utenti possono anche creare probe personalizzati per indicare il nome host, il percorso da verificare tramite probe e i codici di stato da accettare come integri. In ogni caso, se il server back-end non risponde correttamente, il gateway applicazione contrassegna il server come non integro e interrompe l'inoltro delle richieste al server. Quando il server inizia a rispondere correttamente, il gateway applicazione riprende l'inoltro delle richieste.

Come controllare l'integrità del back-end

Per controllare l'integrità del pool back-end, è possibile usare la pagina Integrità back-end nel portale di Azure. In alternativa, è possibile usare Azure PowerShell l'interfaccia della riga di comando di Azure o l'API REST.

Lo stato recuperato da uno di questi metodi può essere uno qualsiasi dei seguenti stati:

• Healthy
• Unhealthy
• Sconosciuto

Il gateway applicazione inoltra una richiesta a un server dal pool back-end se lo stato è integro. Se tutti i server in un pool back-end non sono integri o sconosciuti, i client potrebbero riscontrare problemi di accesso all'applicazione back-end. Leggere ulteriormente per comprendere i diversi messaggi segnalati da Integrità back-end, le relative cause e la relativa risoluzione.

Nota

Se l'utente non dispone dell'autorizzazione per visualizzare gli stati di integrità back-end, viene visualizzato l'output No results. .

Stato di integrità back-end: non integro

Se lo stato di integrità del back-end non è integro, la visualizzazione del portale è simile alla schermata seguente:

Se si usa una query di Azure PowerShell, dell'interfaccia della riga di comando o dell'API REST di Azure, si ottiene una risposta simile all'esempio seguente:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

Se si riceve lo stato Non integro per un server back-end per tutti i server in un pool back-end, le richieste non vengono inoltrate ai server e il gateway applicazione restituisce l'errore "502 Gateway non valido" al client richiedente. Per risolvere il problema, controllare la colonna Dettagli nella scheda Integrità back-end.

Il messaggio visualizzato nella colonna dettagli fornisce informazioni più dettagliate sul problema e, in base a tali dettagli, è possibile iniziare a risolvere il problema.

Nota

La richiesta di probe predefinita viene inviata nel formato <protocollo>://127.0.0.1:<porta>. Ad esempio, http://127.0.0.1:80 per un probe HTTP sulla porta 80. Solo i codici di stato HTTP da 200 a 399 vengono considerati integri. Il protocollo e la porta di destinazione vengono ereditati dalle impostazioni HTTP. Se si vuole che il gateway applicazione verifichi tramite probe un altro protocollo, nome host o percorso e riconosca un codice di stato diverso come integro, configurare un probe personalizzato e associarlo alle impostazioni HTTP.

Messaggi di errore

Timeout del server back-end

Messaggio : il tempo impiegato dal back-end per rispondere al probe di integrità del gateway applicazione è maggiore della soglia di timeout nell'impostazione del probe.

Causa: dopo che il gateway applicazione ha inviato una richiesta di probe HTTP(S) al server back-end, attende una risposta dal server back-end per un periodo di tempo configurato. Se il server back-end non risponde entro questo periodo (il valore di timeout), viene contrassegnato come Non integro finché non risponde entro il periodo di timeout configurato.

Risoluzione: verificare il motivo per cui l'applicazione o il server back-end non risponde entro il periodo di timeout configurato e controllare anche le dipendenze dell'applicazione. Verificare, ad esempio, se nel database sono presenti problemi che possono causare un ritardo nella risposta. Se si conosce il comportamento dell'applicazione e questa risponde solo dopo il valore di timeout, aumentare questo valore dalle impostazioni del probe personalizzato. Per modificare il valore di timeout, deve essere disponibile un probe personalizzato. Per informazioni su come configurare un probe personalizzato, vedere la pagina della documentazione.

Per aumentare il valore di timeout, seguire questa procedura:

1. Accedere direttamente al server back-end e controllare il tempo impiegato dal server per rispondere nella pagina. È possibile usare qualsiasi strumento per accedere al server back-end, incluso un browser con gli strumenti di sviluppo.
2. Dopo aver scoperto il tempo impiegato per rispondere all'applicazione, selezionare la scheda Probe di integrità e quindi selezionare il probe associato alle impostazioni HTTP.
3. Immettere qualsiasi valore di timeout maggiore del tempo di risposta dell'applicazione, in secondi.
4. Salvare le impostazioni del probe personalizzato e verificare se lo stato integrità del back-end è ora Integro.

Errore di risoluzione DNS

Messaggio: Application Gateway could not create a probe for this backend. Ciò si verifica in genere quando l'FQDN del back-end non viene immesso correttamente. 

Causa: se il pool back-end è di tipo Indirizzo IP, FQDN (nome di dominio completo) o servizio app, gateway applicazione viene risolto nell'indirizzo IP del nome di dominio completo immesso tramite DNS (impostazione predefinita di Azure o personalizzata). Il gateway applicazione tenta quindi di connettersi al server sulla porta TCP menzionata nelle impostazioni HTTP. Tuttavia, se viene visualizzato questo messaggio, è possibile che il gateway applicazione non sia riuscito a risolvere l'indirizzo IP dell'FQDN immesso.

Risoluzione:

1. Verificare che l'FQDN immesso nel pool back-end sia corretto e che sia un dominio pubblico, quindi provare a risolverlo dal computer locale.
2. Se è possibile risolvere l'indirizzo IP, può essersi verificato un problema relativo alla configurazione DNS nella rete virtuale.
3. Verificare se la rete virtuale è configurata con un server DNS personalizzato. Se sì, verificare il motivo per cui il server DNS non può essere risolto nell'indirizzo IP dell'FQDN specificato.
4. Se si usa IL DNS predefinito di Azure, verificare che il mapping di record A o record CNAME appropriato sia completo con il registrar.
5. Se il dominio è privato o interno, provare a risolverlo da una macchina virtuale nella stessa rete virtuale. Se è possibile risolverlo, riavviare il gateway applicazione e verificare di nuovo. Per riavviare il gateway applicazione, è necessario arrestarlo e avviarlo usando i comandi di PowerShell descritti in queste risorse collegate.

Errore di connessione TCP

Messaggio: il gateway applicazione non è riuscito a connettersi al back-end. Verificare che il back-end risponda sulla porta usata per il probe. Verificare anche se un NSG, un percorso definito dall'utente o un firewall blocca l'accesso all'indirizzo IP e alla porta del back-end.

Causa: dopo la fase di risoluzione DNS, gateway applicazione tenta di connettersi al server back-end sulla porta TCP configurata nelle impostazioni HTTP. Se il gateway applicazione non riesce a stabilire una sessione di connessione TCP sulla porta specificata, il probe viene contrassegnato come non integro con questo messaggio.

Soluzione: Se viene visualizzato questo errore, seguire questa procedura:

1. Verificare se è possibile connettersi al server back-end sulla porta indicata nelle impostazioni HTTP usando un browser o PowerShell. Ad esempio, eseguire questo comando: Test-NetConnection -ComputerName www.bing.com -Port 443.

2. Se la porta indicata non è la porta desiderata, immettere il numero di porta corretto per gateway applicazione per connettersi al server back-end.

3. Se non è possibile connettersi sulla porta neanche dal computer locale, eseguire le operazioni seguenti:

   a. Controllare le impostazioni del gruppo di sicurezza di rete (NSG) della scheda di rete e della subnet del server back-end e se sono consentite le connessioni in ingresso alla porta configurata. In caso negativo, creare una nuova regola per consentire le connessioni. Per informazioni su come creare regole dei gruppi di sicurezza di rete, vedere la pagina della documentazione.

   b. Verificare se le impostazioni dell'NSG della subnet del gateway applicazione consentono il traffico pubblico e privato in uscita, in modo che sia possibile stabilire una connessione. Vedere la pagina della documentazione indicata nel passaggio 3a per altre informazioni su come creare regole per i gruppi di sicurezza di rete.

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

   c. Controllare le impostazioni delle route definite dall'utente del gateway applicazione e la subnet del server back-end per individuare eventuali anomalie di routing. Verificare che la route definita dall'utente non indirizzi il traffico al di fuori della subnet back-end. Ad esempio, verificare se alla subnet del gateway applicazione vengono annunciate route verso appliance virtuali di rete o route predefinite tramite ExpressRoute di Azure e/o VPN.

   d. Per verificare le route e le regole valide per una scheda di rete, è possibile usare i comandi di PowerShell seguenti:

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

4. Se non si riscontrano problemi relativi a NSG o route definite dall'utente, controllare la presenza di problemi relativi all'applicazione nel server back-end che impediscono ai client di stabilire una sessione TCP sulle porte configurate. Alcuni controlli da eseguire:

   a. Aprire un prompt dei comandi (Win+R -> cmd), immettere netstate selezionare INVIO.

   b. Controllare se il server è in ascolto sulla porta configurata. Ad esempio:

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

   c. Se non è in ascolto sulla porta configurata, controllare le impostazioni del server Web. Ad esempio: binding del sito in IIS, blocco del server in NGINX e host virtuale in Apache.

   d. Controllare le impostazioni del firewall del sistema operativo per assicurarsi che sia consentito il traffico in ingresso verso la porta.

Mancata corrispondenza del codice di stato HTTP

Messaggio: il codice di stato della risposta HTTP del back-end non corrisponde all'impostazione del probe. Expected:{HTTPStatusCode0} Received:{HTTPStatusCode1} (Il codice di stato della risposta HHTP del back-end non corrisponde all'impostazione del probe. Previsto: {HTTPStatusCode0} Ricevuto: {HTTPStatusCode1}).

Causa: dopo aver stabilito la connessione TCP e aver eseguito un handshake TLS (se TLS è abilitato), gateway applicazione invia il probe come richiesta HTTP GET al server back-end. Come descritto in precedenza, il probe predefinito è impostato su <protocol>://127.0.0.1:<port>/e considera i codici di stato della risposta nell'intervallo da 200 a 399 come Integro. Se il server restituisce qualsiasi altro codice di stato, viene contrassegnato come Non integro con questo messaggio.

Soluzione: a seconda del codice di risposta del server back-end, è possibile completare i passaggi seguenti. Di seguito sono elencati alcuni codici di stato comuni:

Errore	Azioni
Mancata corrispondenza del codice di stato del probe: ricevuto 401	Verificare se il server back-end richiede l'autenticazione. I probe del gateway applicazione non possono passare le credenziali per l'autenticazione. Consentire “HTTP 401” in una corrispondenza del codice di stato del probe o eseguire una verifica tramite probe in un percorso in cui il server non richiede l'autenticazione.
Mancata corrispondenza del codice di stato del probe: ricevuto 403	Accesso negato. Controllare se l'accesso al percorso è consentito nel server back-end.
Mancata corrispondenza del codice di stato del probe: ricevuto 404	Pagina non trovata. Controllare se il percorso del nome host è accessibile nel server back-end. Modificare i parametri del nome host o del percorso in un valore accessibile.
Mancata corrispondenza del codice di stato del probe: ricevuto 405	Le richieste di probe per il gateway applicazione usano il metodo HTTP GET. Verificare se il server consente questo metodo.
Mancata corrispondenza del codice di stato del probe: ricevuto 500	Errore interno del server. Verificare l'integrità del server back-end e se i servizi sono in esecuzione.
Mancata corrispondenza del codice di stato del probe: ricevuto 503	servizio non disponibile. Verificare l'integrità del server back-end e se i servizi sono in esecuzione.

In alternativa, se si ritiene che la risposta sia legittima e si vuole che il gateway applicazione accetti altri codici di stato come integri, è possibile creare un probe personalizzato. Questo approccio è utile in situazioni in cui il sito Web back-end richiede l'autenticazione. Poiché le richieste di probe non contengono credenziali utente, avranno esito negativo e viene restituito un codice di stato HTTP 401 dal server back-end.

Per creare un probe personalizzato, seguire questa procedura.

Mancata corrispondenza del corpo della risposta HTTP

Messaggio: il corpo della risposta HTTP del back-end non corrisponde all'impostazione del probe. Il corpo della risposta ricevuta non contiene {string}.

Causa: quando si crea un probe personalizzato, è possibile contrassegnare un server back-end come Integro attraverso la corrispondenza di una stringa dal corpo della risposta. Ad esempio, è possibile configurare il gateway applicazione in modo da accettare "non autorizzato" come stringa per la corrispondenza. Se la risposta del server back-end per la richiesta probe contiene la stringa non autorizzata, lo contrassegna come Integro. In caso contrario, viene contrassegnato come Non integro con il messaggio specificato.

Soluzione: Per risolvere il problema, seguire questa procedura:

1. Accedere al server back-end in locale o da un computer client nel percorso di probe e controllare il corpo della risposta.
2. Verificare che il corpo della risposta nella configurazione del probe personalizzato del gateway applicazione corrisponda a quanto configurato.
3. In caso di mancata corrispondenza, modificare la configurazione del probe in modo che includa il corretto valore della stringa da accettare.

Per altre informazioni, vedere Corrispondenza del probe del gateway applicazione.

Nota

Per tutti i messaggi di errore correlati a TLS e per altre informazioni sul comportamento dell'indicazione nome server e sulle differenze tra lo SKU V1 e V2, vedere la pagina Panoramica di TLS.

Il nome comune (CN) non corrisponde

Messaggio: (per V2) Il nome comune del certificato foglia presentato dal server back-end non corrisponde al probe o all'impostazione back-end del nome host del gateway applicazione.
(per V1) Il nome comune (CN) del certificato back-end non corrisponde.

Causa: (Per V2) Questo problema si verifica quando si seleziona il protocollo HTTPS nell'impostazione back-end e né il nome host dell'impostazione del probe personalizzato (in tale ordine) corrisponde al nome comune (CN) del certificato del server back-end.
(Per V1) Il nome di dominio completo della destinazione del pool back-end non corrisponde al nome comune del certificato del server back-end.

Soluzione: le informazioni sul nome host sono fondamentali per la connessione HTTPS back-end perché tale valore viene usato per impostare Indicazione nome server (SNI) durante l'handshake TLS. È possibile risolvere questo problema nei modi seguenti in base alla configurazione del gateway.

Per V2,

• Se si usa un probe predefinito: è possibile specificare un nome host nell'impostazione back-end associata del gateway applicazione. È possibile selezionare "Esegui override con un nome host specifico" o "Pick hostname from backend target" nell'impostazione back-end.
• Se si usa un probe personalizzato per il probe personalizzato, è possibile usare il campo "host" per specificare il nome comune del certificato del server back-end. In alternativa, se l'impostazione back-end è già configurata con lo stesso nome host, è possibile scegliere "Scegli nome host dall'impostazione back-end" nelle impostazioni del probe.

Per V1, verificare che il nome di dominio completo della destinazione del pool back-end sia lo stesso nome comune (CN).

Suggerimenti: per determinare il nome comune (CN) del certificato del server back-end, è possibile usare uno di questi metodi. Si noti anche che, in base a RFC 6125 se esiste una san, la verifica SNI viene eseguita solo su tale campo. Il campo nome comune viene confrontato se non è presente una rete SAN nel certificato.

• Usando il browser o qualsiasi client: accedere direttamente al server back-end (non tramite il gateway applicazione) e fare clic sul lucchetto certificato nella barra degli indirizzi per visualizzare i dettagli del certificato. È possibile trovarlo nella sezione "Rilasciato a".

• Accedendo al server back-end (Windows):

  1. Accedere al computer in cui è ospitata l'applicazione.
  2. Premere Windows+R o fare clic con il pulsante destro del mouse sul pulsante Start e scegliere Esegui.
  3. Immettere certlm.msc e selezionare INVIO. È anche possibile cercare Gestione certificati nel menu Start.
  4. Individuare il certificato (in genere in Certificati - Computer locale\Personale\Certificati) e aprire il certificato.
  5. Nella scheda Dettagli verificare il valore di Oggetto del certificato.

• Accedendo al server back-end (Linux): eseguire questo comando OpenSSL specificando il nome file del certificato corretto openssl x509 -in certificate.crt -subject -noout

Il certificato back-end è scaduto

Messaggio: certificato back-end non valido. La data corrente non rientra nell'intervallo di date "Valido da" e "Valido a" nel certificato.

Causa: un certificato scaduto viene considerato non sicuro e quindi il gateway applicazione contrassegna il server back-end con un certificato scaduto come non integro.

Soluzione: la soluzione dipende da quale parte della catena di certificati è scaduta nel server back-end.

Per lo SKU V2,

• Certificato foglia scaduto (noto anche come dominio o server): rinnovare il certificato del server con il provider di certificati e installare il nuovo certificato nel server back-end. Assicurarsi di installare la catena di Leaf (topmost) > Intermediate(s) > Rootcertificati completa costituita da . In base al tipo di autorità di certificazione (CA), è possibile eseguire le azioni seguenti nel gateway.

  • CA nota pubblicamente: se l'autorità di certificazione è una CA nota, non è necessario eseguire alcuna azione sul gateway applicazione.
  • CA privata: se il certificato foglia viene rilasciato da una CA privata, è necessario verificare se il certificato CA radice di firma è stato modificato. In questi casi, è necessario caricare il nuovo certificato CA radice (.CER) per l'impostazione back-end associata del gateway.

• Certificato intermedio o radice scaduto: in genere, questi certificati hanno periodi di validità relativamente estesi (un decennio o due). Quando scade il certificato radice/intermedio, è consigliabile rivolgersi al provider di certificati per i file di certificato rinnovati. Assicurarsi di installare questa catena di certificati aggiornata e completa che Leaf (topmost) > Intermediate(s) > Root include nel server back-end.

  • Se il certificato radice rimane invariato o se l'autorità emittente è una CA nota, non è necessario eseguire alcuna azione sul gateway applicazione.
  • Quando si usa una CA privata, se il certificato CA radice o la radice del certificato intermedio rinnovato è stato modificato, è necessario caricare il nuovo certificato radice nell'impostazione back-end del gateway applicazione.

Per lo SKU V1,

• Rinnovare il certificato Foglia scaduto (noto anche come dominio o server) con la CA e caricare lo stesso certificato foglia (.CER) per l'impostazione back-end associata del gateway applicazione.

Non è stato trovato alcun certificato intermedio

Messaggio: Il certificato intermedio manca dalla catena di certificati presentata dal server back-end. Verificare che la catena di certificati sia completa e ordinata correttamente nel server back-end.

Causa: i certificati intermedi non sono installati nella catena di certificati nel server back-end.

Soluzione: un certificato intermedio viene usato per firmare il certificato foglia ed è quindi necessario completare la catena. Verificare con l'autorità di certificazione (CA) la presenza dei certificati intermedi necessari e installarli nel server back-end. La catena deve iniziare con il certificato foglia, quindi i certificati intermedi e infine il certificato CA radice. È consigliabile installare la catena completa nel server back-end, incluso il certificato CA radice. Per informazioni di riferimento, vedere l'esempio della catena di certificati in Foglia deve essere all’inizio della catena.

Nota

Un certificato autofirmato che non è un'autorità di certificazione genera anche lo stesso errore. Questo avviene perché il gateway applicazione considera tale certificato autofirmato come certificato "Foglia" e cerca il certificato intermedio di firma. È possibile seguire questo articolo per generare correttamente un certificato autofirmato.

Queste immagini mostrano la differenza tra i certificati autofirmati.

Il certificato foglia o server non è stato trovato

Messaggio: Il certificato foglia manca dalla catena di certificati presentata dal server back-end. Verificare che la catena sia stata completata e ordinata correttamente nel server back-end.

Causa: il certificato foglia (noto anche come Dominio o Server) non è presente nella catena di certificati nel server back-end.

Soluzione: è possibile ottenere il certificato foglia dall'autorità di certificazione (CA). Installare questo certificato foglia e tutti i relativi certificati di firma (certificati CA intermedi e radice) nel server back-end. La catena deve iniziare con il certificato foglia, quindi i certificati intermedi e infine il certificato CA radice. È consigliabile installare la catena completa nel server back-end, incluso il certificato CA radice. Per informazioni di riferimento, vedere l'esempio della catena di certificati in Foglia deve essere all’inizio della catena.

Il certificato del server non viene emesso da una CA nota pubblicamente

Messaggio: il certificato del server back-end non è firmato da un'autorità di certificazione (CA) nota. Per usare certificati CA sconosciuti, è necessario caricare il certificato radice nell'impostazione back-end del gateway applicazione.

Causa: è stato scelto il "certificato CA noto" nell'impostazione back-end, ma il certificato radice presentato dal server back-end non è noto pubblicamente.

Soluzione: Quando un certificato Foglia viene emesso da un'autorità di certificazione (CA), il certificato della CA radice di firma deve essere caricato nell'impostazione back-end associata del gateway applicazione. In questo modo il gateway applicazione può stabilire una connessione attendibile con tale server back-end. Per risolvere questo problema, passare all'impostazione back-end associata, scegliere "non una CA nota" e caricare il certificato CA radice (. CER). Per identificare e scaricare il certificato radice, è possibile seguire gli stessi passaggi descritti in Mancata corrispondenza del certificato radice attendibile.

Il certificato intermedio NON è firmato da una CA nota pubblicamente.

Messaggio: il certificato intermedio non è firmato da un'autorità di certificazione (CA) nota. Verificare che la catena di certificati sia completa e ordinata correttamente nel server back-end.

Causa: è stato scelto il "certificato CA noto" nell'impostazione back-end, ma il certificato intermedio presentato dal server back-end non è firmato da alcuna CA nota pubblicamente.

Soluzione: Quando un certificato viene emesso da un'autorità di certificazione (CA), il certificato della CA radice di firma deve essere caricato nell'impostazione back-end associata del gateway applicazione. In questo modo il gateway applicazione può stabilire una connessione attendibile con tale server back-end. Per risolvere questo problema, contattare la CA privata per ottenere il certificato CA radice appropriato (. CER) e caricare il file . File CER per l'impostazione back-end del gateway applicazione selezionando "not a well-known CA". È consigliabile inoltre installare la catena completa nel server back-end, incluso il certificato CA radice per una facile verifica.

Mancata corrispondenza del certificato radice attendibile (nessun certificato radice nel server back-end)

Messaggio: certificato intermedio non firmato da certificati radice caricati nel gateway applicazione. Verificare che la catena di certificati sia completa e ordinata correttamente nel server back-end.

Causa: Nessuno dei certificati CA radice caricati nell'impostazione back-end associata ha firmato il certificato Intermedio installato nel server back-end. Il server back-end include solo certificati Foglia e Intermedi installati.

Soluzione: Un certificato Foglia viene firmato da un certificato Intermedio, che è firmato da un certificato radice CA. Quando si usa un certificato emesso da un’autorità di certificazione privata (CA), è necessario caricare il certificato radice CA corrispondente nel gateway applicazione. Contattare la autorità di certificazione privata per ottenere il certificato radice CA appropriato (. CER) e caricare il file CER nell'impostazione back-end del gateway applicazione.

Mancata corrispondenza del certificato radice attendibile (il certificato radice è disponibile nel server back-end)

Messaggio: Il certificato radice del certificato server usato dal back-end non corrisponde al certificato radice attendibile aggiunto al gateway applicazione. Assicurarsi di aggiungere il certificato radice corretto per consentire l'elenco dei back-end.

Causa: Questo errore si verifica quando nessuno dei certificati radice caricati nell'impostazione back-end del gateway applicazione corrisponde al certificato radice presente nel server back-end.

Soluzione: ciò vale per un certificato del server back-end rilasciato da un'autorità di certificazione (CA) privata oppure è uno auto-firmato. Identificare e caricare il certificato CA radice corretto nell'impostazione back-end associata.

Suggerimenti: per identificare e scaricare il certificato radice, è possibile usare uno di questi metodi.

• Uso di un browser: accedere direttamente al server back-end (non tramite il gateway applicazione) e fare clic sul lucchetto certificato nella barra degli indirizzi per visualizzare i dettagli del certificato.

  1. Scegliere il certificato radice nella catena e fare clic su Esporta. Per impostazione predefinita, si tratta di un oggetto . File CRT.
  2. Aprire il file .CRT.
  3. Passare alla scheda Dettagli e fare clic su "Copia in file",
  4. Nella pagina Esportazione guidata certificati fare clic su Avanti,
  5. Selezionare "X.509 con codifica Base 64 (.CER) e fare clic su Avanti,
  6. Assegnare un nuovo nome file e fare clic su Avanti,
  7. Fare clic su Fine per ottenere un file .CER.
  8. Caricare questo certificato radice (.CER) dell'autorità di certificazione privata per l'impostazione back-end del gateway applicazione.

• Accedendo al server back-end (Windows)

  1. Accedere al computer in cui è ospitata l'applicazione.
  2. Premere Windows+R o fare clic con il pulsante destro del mouse sul pulsante Start e quindi scegliere Esegui.
  3. Immettere certlm.msc e selezionare INVIO. È anche possibile cercare Gestione certificati nel menu Start.
  4. Individuare il certificato, in genere in Certificati - Computer locale\Personale\Certificati, e aprirlo.
  5. Selezionare il certificato radice e quindi Visualizza certificato.
  6. Nelle proprietà Certificato selezionare la scheda Dettagli e fare clic su "Copia nel file",
  7. Nella pagina Esportazione guidata certificati fare clic su Avanti,
  8. Selezionare "X.509 con codifica Base 64 (.CER) e fare clic su Avanti,
  9. Assegnare un nuovo nome file e fare clic su Avanti,
  10. Fare clic su Fine per ottenere un file .CER.
  11. Caricare questo certificato radice (.CER) dell'autorità di certificazione privata per l'impostazione back-end del gateway applicazione.

La foglia deve essere all'inizio della catena.

Messaggio: il certificato foglia non è il certificato più in alto nella catena presentata dal server back-end. Verificare che la catena di certificati sia ordinata correttamente nel server back-end.

Causa: il certificato Foglia (noto anche come dominio o server) non è installato nell'ordine corretto nel server back-end.

Soluzione: L'installazione del certificato nel server back-end deve includere un elenco ordinato di certificati che comprendono il certificato foglia e tutti i relativi certificati di firma (certificati CA intermedi e radice). La catena deve iniziare con il certificato foglia, quindi i certificati intermedi e infine il certificato CA radice. È consigliabile installare la catena completa nel server back-end, incluso il certificato CA radice.

Dato è un esempio di installazione di un certificato server insieme ai relativi certificati CA intermedi e radice, indicati come profondità (0, 1, 2 e così via) in OpenSSL. È possibile verificare lo stesso per il certificato del server back-end usando i comandi OpenSSL seguenti.
s_client -connect <FQDN>:443 -showcerts
O
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Verifica del certificato non riuscita

Messaggio: Impossibile verificare la validità del certificato back-end. To find out the reason, check OpenSSL diagnostics for the message associated with error code {errorCode}. (Non è stato possibile verificare la validità del certificato del back-end. Per scoprire il motivo, controllare nella diagnostica di OpenSSL il messaggio associato al codice di errore {errorCode}).

Causa: questo errore si verifica quando il gateway applicazione non è in grado di verificare la validità del certificato.

Soluzione: per risolvere il problema, verificare che il certificato nel server sia stato creato correttamente. Ad esempio, è possibile usare OpenSSL per verificare il certificato e le relative proprietà e provare a ricaricare il certificato nelle impostazioni HTTP del gateway applicazione.

Stato integrità del back-end: sconosciuto

Aggiornamenti alle voci DNS del pool back-end

Messaggio: impossibile recuperare lo stato di integrità back-end. Questo problema si verifica quando un gruppo di sicurezza di rete/una route definita dall'utente/un firewall nella subnet di Gateway applicazione blocca il traffico sulle porte 65503-65534 nel caso dello SKU v1 e sulle porte 65200-65535 nel caso dello SKU v2 o se non è stato possibile risolvere in un indirizzo IP il nome di dominio completo configurato nel pool back-end. Per altre informazioni, vedere: https://aka.ms/UnknownBackendHealth.

Causa: per le destinazioni back-end basate su FQDN (nome di dominio completo), il gateway applicazione memorizza nella cache e usa l'ultimo indirizzo IP valido noto se non riesce a ottenere una risposta per la ricerca DNS successiva. Un'operazione PUT su un gateway in questo stato cancella completamente la cache DNS. Di conseguenza, non ci saranno indirizzi di destinazione a cui il gateway può raggiungere.

Soluzione: controllare e correggere i server DNS per assicurarsi che stia servendo una risposta per la ricerca DNS del DNS FDQN specificato. È anche necessario verificare se i server DNS sono raggiungibili tramite la rete virtuale del gateway applicazione.

Altri motivi

Se l'integrità del back-end viene visualizzata come Sconosciuto, la visualizzazione del portale è simile alla schermata seguente:

Questo comportamento può verificarsi per uno o più dei motivi seguenti:

1. L'NSG nella subnet del gateway applicazione blocca l'accesso in ingresso alle porte 65503-65534 (SKU V1) o 65200-65535 (SKU V2) da "Internet".
2. La route definita dall'utente nella subnet gateway applicazione è impostata sulla route predefinita (0.0.0.0/0) e l'hop successivo non viene specificato come "Internet".
3. La route predefinita viene annunciata da una connessione ExpressRoute/VPN a una rete virtuale tramite BGP.
4. Il server DNS personalizzato è configurato in una rete virtuale che non è in grado di risolvere i nomi di dominio pubblici.
5. Il gateway applicazione si trova in uno stato non integro.

Soluzione:

1. controllare se l'NSG blocca l'accesso alle porte 65503-65534 (SKU V1) o 65200-65535 (SKU V2) da Internet:

   a. Nella scheda Panoramica del gateway applicazione selezionare il collegamento Rete virtuale/subnet. b. Nella scheda Subnet della rete virtuale selezionare la subnet in cui viene distribuita gateway applicazione. c. Controllare se è configurato un NSG. d. Se è configurato un NSG, cercare la risorsa NSG nella scheda Cerca o in Tutte le risorse. e. Nella sezione Regole in ingresso aggiungere una regola in ingresso per consentire l'intervallo di porte di destinazione 65503-65534 per lo SKU v1 o 65200-65535 v2 con l'origine impostata come tag del servizio GatewayManager. f. Selezionare Salva e verificare che sia possibile visualizzare il back-end come integro. In alternativa, è possibile usare PowerShell o l'interfaccia della riga di comando a questo scopo.

2. Controllare se la route definita dall'utente include una route predefinita (0.0.0.0/0) con l'hop successivo non impostato come Internet:

   a. Seguire i passaggi 1a e 1b per determinare la subnet. b. Verificare se è configurata una route definita dall'utente. Se sì, cercare la risorsa sulla barra di ricerca o in Tutte le risorse. c. Verificare se sono presenti route predefinite (0.0.0.0/0) con l'hop successivo non impostato come Internet. Se l'impostazione è Appliance virtuale o Gateway di rete virtuale, è necessario assicurarsi che l'appliance virtuale o il dispositivo locale sia in grado di reinstradare correttamente il pacchetto alla destinazione Internet senza modificarlo. Se i probe vengono instradati tramite un'appliance virtuale e modificati, la risorsa back-end visualizza un codice di stato 200 e lo stato di integrità gateway applicazione può essere visualizzato come Sconosciuto. Questo non indica un errore. Il traffico deve comunque essere instradato attraverso il gateway applicazione senza problemi. d. In caso contrario, modificare l'hop successivo in Internet, selezionare Salvae verificare l'integrità del back-end.

3. Route predefinita annunciata dalla connessione ExpressRoute/VPN alla rete virtuale tramite BGP (Border Gateway Protocol):

   a. Se è presente una connessione ExpressRoute/VPN alla rete virtuale tramite BGP e se si annuncia una route predefinita, è necessario assicurarsi che il pacchetto venga reinstradato alla destinazione Internet senza modificarlo. Per la verifica, è possibile usare l'opzione Risoluzione dei problemi di connessione nel portale del gateway applicazione. b. Scegliere la destinazione manualmente come qualsiasi indirizzo IP instradabile su Internet, ad esempio 1.1.1.1. Impostare la porta di destinazione come qualsiasi valore e verificare la connettività. c. Se l'hop successivo è il gateway di rete virtuale, potrebbe essere presente una route predefinita annunciata tramite ExpressRoute o VPN.

4. Se nella rete virtuale è configurato un server DNS personalizzato, verificare che i server siano in grado di risolvere i domini pubblici. La risoluzione dei nomi di dominio pubblico potrebbe essere necessaria negli scenari in cui gateway applicazione deve raggiungere domini esterni come i server OCSP (Online Certificate Status Protocol) o per controllare lo stato di revoca del certificato.

5. Per verificare che il gateway applicazione sia integro e in esecuzione, passare all'opzione Integrità risorse nel portale e verificare che lo stato sia Integro. Se viene visualizzato lo stato Non integro o Danneggiato, contattare il supporto tecnico.

6. Se il traffico Internet e privato passa attraverso un firewall di Azure ospitato in un hub virtuale protetto (usando l'hub della rete WAN virtuale di Azure):

   a. Per assicurarsi che il gateway applicazione possa inviare il traffico direttamente a Internet, configurare la route definita dall'utente seguente:

   Prefisso indirizzo: 0.0.0.0/0
   Hop successivo: Internet

   b. Per assicurarsi che il gateway applicazione possa inviare traffico al pool back-end tramite firewall di Azure nell'hub della rete WAN virtuale, configurare la route definita dall'utente seguente:

   Prefisso indirizzo: subnet del pool back-end
   Hop successivo: indirizzo IP privato di Firewall di Azure

Nota

Se il gateway applicazione non è in grado di accedere agli endpoint CRL, potrebbe contrassegnare lo stato di integrità del back-end come "sconosciuto". Per evitare questi problemi, verificare che la subnet del gateway applicazione sia in grado di accedere crl.microsoft.com a e crl3.digicert.com. Questa operazione può essere eseguita configurando i gruppi di sicurezza di rete per inviare il traffico agli endpoint CRL.

Passaggi successivi

Per altre informazioni, vedere Diagnostica e registrazione del gateway applicazione.