Condividi tramite

Risoluzione degli errori del gateway non valido nel gateway applicazione

  • Articolo

Informazioni su come risolvere gli errori del gateway non valido (502) ricevuti quando si usa il gateway applicazione di Azure.

Nota

È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Panoramica

Dopo aver configurato un gateway applicazione, uno degli errori visualizzati è Errore del server: 502 - Server Web ha ricevuto una risposta non valida mentre funge da gateway o server proxy. Questo errore può verificarsi per i motivi principali seguenti:

Problema di gruppo di sicurezza di rete, route definita dall'utente o DNS personalizzato

Causa

Se l'accesso al back-end è bloccato a causa di un gruppo di sicurezza di rete, una route definita dall'utente o un DNS personalizzato, le istanze del gateway applicazione non possono raggiungere il pool back-end. Questo problema provoca errori del probe, causando errori 502.

Il gruppo di sicurezza di rete/route definita dall'utente può essere presente nella subnet del gateway applicazione o nella subnet in cui vengono distribuite le macchine virtuali dell'applicazione.

Analogamente, anche la presenza di un DNS personalizzato nella rete virtuale potrebbe causare problemi. Un FQDN usato per i membri del pool back-end potrebbe non essere risolto correttamente dal server DNS configurato dall'utente per la rete virtuale.

Soluzione

Convalidare la configurazione di gruppo di sicurezza di rete, route definita dall'utente o DNS personalizzato tramite i passaggi seguenti:

  1. Controllare i gruppi di sicurezza di rete associati alla subnet del gateway applicazione. Assicurarsi che la comunicazione con il back-end non sia bloccata. Per altre informazioni, vedere Gruppi di sicurezza di rete.

  2. Controllare la route definita dall'utente associata alla subnet del gateway applicazione. Assicurarsi che la route definita dall'utente non indirizzi il traffico dalla subnet back-end. Ad esempio, verificare la presenza di routing verso appliance virtuali di rete o route predefinite annunciate alla subnet del gateway applicazione tramite ExpressRoute/VPN.

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

  3. Controllare il gruppo di sicurezza di rete e la route effettivi nella macchina virtuale back-end

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

  4. Controllare se è presente un DNS personalizzato nella rete virtuale. È possibile eseguire questo controllo esaminando i dettagli delle proprietà della rete virtuale nell'output.

    Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
DhcpOptions            : {
                           "DnsServers": [
                             "x.x.x.x"
                           ]
                         }

  5. Se presente, assicurarsi che il server DNS possa risolvere correttamente il nome di dominio completo del membro del pool back-end.

Problemi con il probe di integrità predefinito

Causa

Gli errori 502 possono anche essere indicatori frequenti che il probe di integrità predefinito non può raggiungere le macchine virtuali back-end.

Quando viene eseguito il provisioning di un'istanza del gateway applicazione, viene automaticamente configurato il probe di integrità predefinito per ogni BackendAddressPool tramite le proprietà del BackendHttpSetting. Per impostare il probe non è necessaria alcuna azione da parte dell'utente. In particolare, quando viene configurata una regola di bilanciamento del carico, viene creata un'associazione tra un BackendHttpSetting e un BackendAddressPool. Un probe predefinito è configurato per ognuna di queste associazioni e il gateway applicazione avvia una connessione periodica di controllo integrità a ogni istanza di BackendAddressPool nella porta specificata nell'elemento BackendHttpSetting.

Nella tabella seguente sono elencati i valori associati al probe di integrità predefinito:

Proprietà probe Valore Descrizione
URL probe http://127.0.0.1/ Percorso URL
Intervallo 30 Intervallo di probe in secondi
Timeout 30 Timeout di probe in secondi
Soglia non integra 3 Numero di tentativi di probe. Il server back-end viene contrassegnato come inattivo dopo che il numero di errori di probe consecutivi ha raggiunto una soglia non integra.

Soluzione

  • Il valore host della richiesta verrà impostato su 127.0.0.1. Verificare che sia stato configurato un sito predefinito e che sia in ascolto su 127.0.0.1.
  • Il protocollo della richiesta è determinato dal protocollo BackendHttpSetting.
  • Il percorso URI verrà impostato su /.
  • Se BackendHttpSetting specifica una porta diversa da 80, il sito predefinito deve essere configurato per ascoltare tale porta.
  • La chiamata a protocol://127.0.0.1:port deve restituire un codice risultato HTTP di 200. Questo codice deve essere restituito entro il periodo di timeout di 30 secondi.
  • Verificare che la porta configurata sia aperta e che non siano presenti regole del firewall o gruppi di sicurezza di rete di Azure che bloccano il traffico in ingresso o in uscita sulla porta configurata.
  • Se le macchine virtuali classiche di Azure o il servizio cloud vengono usate con un FQDN o un indirizzo IP pubblico, assicurarsi che venga aperto l’endpoint corrispondente.
  • Se la macchina virtuale è configurata tramite Azure Resource Manager e si trova all'esterno della rete virtuale in cui viene distribuito il gateway applicazione, è necessario configurare un gruppo di sicurezza di rete per consentire l'accesso sulla porta desiderata.

Per altre informazioni, vedere la configurazione dell'infrastruttura del gateway applicazione.

Problemi con il probe di integrità personalizzato

Causa

Il probe di integrità personalizzato consente una maggiore flessibilità per la ricerca di comportamenti predefiniti del probe. Quando si usano probe personalizzati, è possibile configurare l'intervallo di probe, l'URL, il percorso da testare e il numero di risposte non riuscite da accettare prima di contrassegnare l'istanza del pool back-end come non integra.

Vengono aggiunte le seguenti proprietà aggiuntive:

Proprietà probe Descrizione
Name Nome del probe. Questo nome viene usato per fare riferimento al probe nelle impostazioni HTTP back-end.
Protocollo Protocollo usato per inviare il probe. Il probe usa il protocollo definito nelle impostazioni HTTP del back-end.
Host Nome host per inviare il probe. Applicabile solo quando vengono configurati più siti nel gateway applicazione. Questo nome è diverso dal nome host della macchina virtuale.
Percorso Percorso relativo del probe. Il percorso valido inizia da "/". Il probe viene inviato a <protocollo>://<host>:<porta><percorso>
Intervallo Intervallo di probe in secondi. Si tratta dell'intervallo di tempo tra due probe consecutivi.
Timeout Timeout del probe in secondi. Se non viene ricevuta una risposta valida entro questo periodo di timeout, il probe viene contrassegnato come non riuscito.
Soglia non integra Numero di tentativi di probe. Il server back-end viene contrassegnato come inattivo dopo che il numero di errori di probe consecutivi ha raggiunto una soglia non integra.

Soluzione

Verificare che il probe di integrità personalizzato sia configurato correttamente, come illustrato nella tabella precedente. In aggiunta alle procedure di risoluzione dei problemi precedenti, verificare anche quanto segue:

  • Verificare che il probe sia specificato correttamente secondo le istruzioni della guida.
  • Se il gateway applicazione è configurato per un singolo sito, per impostazione predefinita il nome host deve essere specificato come 127.0.0.1, se non diversamente configurato nel probe personalizzato.
  • Verificare che la chiamata a http://<host>:<porta><percorso> restituisca un codice risultato HTTP di 200.
  • Assicurarsi che Interval, Timeout e UnhealtyThreshold siano compresi negli intervalli accettabili.
  • Se si usa un probe HTTPS, assicurarsi che il server back-end non richieda SNI configurando un certificato di fallback nello stesso server back-end.

Timeout della richiesta

Causa

Quando viene ricevuta una richiesta dell'utente, il gateway applicazione applica le regole configurate alla richiesta e la instrada a un'istanza del pool back-end. Attende quindi la risposta dall'istanza back-end per un intervallo di tempo configurabile. Per impostazione predefinita, questo intervallo è 20 secondi. Se il gateway applicazione in Gateway applicazione v1 non riceve una risposta dall'applicazione back-end in questo intervallo, la richiesta dell'utente riceve un errore 502. Nel gateway applicazione v2, se il gateway applicazione non riceve una risposta dall'applicazione back-end in questo intervallo, la richiesta verrà tentata per un secondo membro del pool back-end. Se la seconda richiesta ha esito negativo, la richiesta dell'utente riceve un errore 504.

Soluzione

Il gateway applicazione consente di configurare questa impostazione tramite BackendHttpSetting, che può essere quindi applicata a pool diversi. Pool back-end diversi possono avere backendHttpSetting diversi e un timeout di richiesta diverso configurato.

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

BackendAddressPool vuoto

Causa

Se il gateway applicazione non ha macchine virtuali o set di scalabilità di macchine virtuali configurato nel pool di indirizzi back-end, non può instradare alcuna richiesta del cliente e invia un errore di gateway non valido.

Soluzione

Assicurarsi che il pool di indirizzi back-end non sia vuoto. A tale scopo è possibile usare PowerShell, l'interfaccia della riga di comando o il portale.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

L'output del cmdlet precedente deve contenere un pool di indirizzi back-end non valido. L'esempio seguente mostra due pool restituiti che sono configurati con un nome di dominio completo o con indirizzi IP per le macchine virtuali back-end. Lo stato del provisioning di BackendAddressPool deve essere "Succeeded".

BackendAddressPoolsText:

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

Istanze non integre in BackendAddressPool

Causa

Se tutte le istanze di BackendAddressPool non sono integre, il gateway applicazione non dispone di alcun back-end a cui instradare la richiesta dell'utente. Questo può anche essere il caso in cui le istanze back-end sono integre ma non hanno l'applicazione richiesta distribuita.

Soluzione

Verificare che le istanze siano integre e che l'applicazione sia configurata correttamente. Controllare se le istanze back-end possono rispondere a un ping da un'altra macchina virtuale nella stessa rete virtuale. Se configurato con un endpoint pubblico, verificare che una richiesta del browser all'applicazione Web sia gestibile.

Il certificato SSL upstream non corrisponde

Causa

Il certificato TLS installato nei server back-end non corrisponde al nome host ricevuto nell'intestazione della richiesta host.

Negli scenari in cui TLS end-to-end è abilitato, una configurazione ottenuta modificando le impostazioni HTTP back-end appropriate e modificando la configurazione dell'impostazione "Protocollo back-end" su HTTPS, è obbligatorio assicurarsi che il CNAME del certificato TLS installato nei server back-end corrisponda al nome host che arriva al back-end nella richiesta di intestazione host HTTP.

Come promemoria, l'effetto dell'abilitazione in "Impostazioni HTTP back-end" dell'opzione di protocollo HTTPS anziché HTTP, sarà che la seconda parte della comunicazione che avviene tra le istanze del gateway applicazione e i server back-end verrà crittografata con TLS.

A causa del fatto che per impostazione predefinita il gateway applicazione invia la stessa intestazione host HTTP al back-end ricevuto dal client, è necessario assicurarsi che il certificato TLS installato nel server back-end venga emesso con un CNAME che corrisponde al nome host ricevuto dal server back-end nell'intestazione host HTTP. Tenere presente che, se non specificato diversamente, questo nome host sarà uguale a quello ricevuto dal client.

Ad esempio:

Si supponga di avere un gateway applicazione per gestire le richieste https per il dominio www.contoso.com. Si potrebbe avere il dominio contoso.com delegato a una zona pubblica DNS di Azure e un record DNS di Azure in tale zona che punta www.contoso.com all'indirizzo IP pubblico del gateway applicazione specifico che gestisce le richieste.

Nel gateway applicazione è necessario disporre di un listener per l'host www.contoso.com con una regola con l'”impostazione HTTP supportata” forzata per l'uso del protocollo HTTPS (verificando TLS end-to-end). La stessa regola potrebbe aver configurato un pool back-end con due macchine virtuali che eseguono IIS come server Web.

Come si sa, l'abilitazione di HTTPS nell'”impostazione HTTP supportata” della regola eseguirà la seconda parte della comunicazione tra le istanze del gateway applicazione e i server nel back-end per l'uso di TLS.

Se i server back-end non dispongono di un certificato TLS emesso per il CNAME www.contoso.com o *.contoso.com, la richiesta avrà esito negativo con Errore server: 502 - Il server Web ha ricevuto una risposta non valida mentre funge da gateway o server proxy perché il certificato SSL upstream (il certificato installato nei server back-end) non corrisponderà al nome host nell'intestazione host, e quindi la negoziazione TLS avrà esito negativo.

www.contoso.com --> IP front-end del gateway APP -> Listener con una regola che configura "Impostazioni HTTP back-end" per l'uso del protocollo HTTPS anziché HTTP -> Pool back-end --> Server Web (deve avere un certificato TLS installato per www.contoso.com)

Soluzione

È necessario che il CNAME del certificato TLS installato nel server back-end corrisponda al nome host configurato nelle impostazioni back-end HTTP, altrimenti la seconda parte della comunicazione end-to-end che si verifica tra le istanze del gateway applicazione e il back-end, avrà esito negativo con "Il certificato SSL upstream non corrisponde" e genererà un errore del server: 502 - Il server Web ha ricevuto una risposta non valida mentre funge da gateway o server proxy

Passaggi successivi

Se il problema non viene risolto tramite i passaggi precedenti, aprire un ticket di supporto.