Risolvere gli errori di bad gateway (502) in gateway applicazione di Azure

Riassunto

Informazioni su come risolvere gli errori di gateway non valido (502) in gateway applicazione di Azure in modo da poter ripristinare rapidamente l'accesso affidabile alle app Web.

Annotazioni

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 Migrate Azure PowerShell da AzureRM ad Az.

Symptoms

Dopo aver configurato un gateway applicazione, potrebbe essere visualizzato l'errore "Errore server: 502 - Server Web ha ricevuto una risposta non valida mentre funge da gateway o server proxy". Questo errore può verificarsi per i motivi seguenti:

Gruppo di sicurezza di rete, route definita dall'utente o problema DNS personalizzato

Motivo

Se un NSG, una UDR o un DNS personalizzato blocca l'accesso al back-end, le istanze del gateway dell'applicazione non possono raggiungere il pool back-end. Questo problema provoca guasti alla sonda, che si traducono in errori 502.

Potrebbe essere presente un NSG o un UDR sia nella subnet del gateway applicativo sia nella subnet in cui sono distribuite le macchine virtuali (VM) dell'applicazione.

Analogamente, anche la presenza di un DNS personalizzato nella rete virtuale (VNet) può causare problemi. Il server DNS configurato dall'utente per la rete virtuale potrebbe non risolvere correttamente un nome di dominio completo (FQDN) usato per i membri del pool back-end.

Soluzione

Convalida le configurazioni di NSG, UDR e DNS. A tale scopo, eseguire le operazioni seguenti:

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

  2. Controllare l'UDR associata alla subnet del gateway applicativo. Assicurarsi che l'UDR non indirizzi il traffico fuori dalla subnet back-end. Ad esempio, verificare se il traffico viene instradato verso appliance virtuali di rete oppure se route predefinite vengono annunciate alla subnet di Application Gateway tramite Azure ExpressRoute o Azure VPN. Eseguire i comandi seguenti in Azure PowerShell.

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

  3. Verificare gli NSG e le route effettivi per la VM back-end. Eseguire i comandi seguenti in Azure PowerShell.

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

  4. Verificare la presenza di DNS personalizzati nella rete virtuale. Controllare DNS 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.

La sonda di integrità predefinita non riesce a raggiungere le macchine virtuali (VM) back-end

Motivo

Un errore 502 può anche indicare che la sonda di integrità predefinita non riesce a raggiungere le VM di back-end.

Quando si esegue il provisioning di un'istanza del gateway applicativo, viene configurata automaticamente una sonda di integrità predefinita per ogni BackendAddressPool utilizzando le proprietà di BackendHttpSetting.

Non è necessario fornire alcun input per impostare questo probe. In particolare, quando si configura una regola di bilanciamento del carico, si associa un oggetto BackendHttpSetting a un oggetto BackendAddressPool. Ognuna di queste associazioni ha configurato un probe predefinito e il gateway applicativo avvia una connessione periodica per il controllo dello stato di integrità a ogni istanza in BackendAddressPool sulla porta specificata nell'elemento BackendHttpSetting.

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

Proprietà della probe Valore Descrzione
URL di controllo http://127.0.0.1/ Percorso URL
Intervallo 30 Intervallo della sonda in secondi
Timeout 30 Timeout di sondaggio in secondi
Soglia non salutare 3 Numero di tentativi di probe. Il server backend viene contrassegnato come inattivo dopo che il numero consecutivo di errori del probe ha raggiunto la soglia di criticità.

Soluzione

Utilizza le linee guida seguenti per risolvere i problemi del controllo di integrità predefinito.

  • Il valore host della richiesta è impostato su 127.0.0.1. Assicurarsi che un sito predefinito sia configurato e sia in ascolto alla versione 127.0.0.1.
  • Il BackendHttpSetting protocollo determina il protocollo della richiesta.
  • Il percorso URI è impostato su /*.
  • Se BackendHttpSetting specifica una porta diversa da 80, configurare il sito predefinito per l'ascolto su tale porta.
  • La chiamata a protocol://127.0.0.1:port deve restituire un codice di risultato HTTP di 200. Questo codice deve essere restituito entro il periodo di timeout di 30 secondi.
  • Assicurarsi 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 si usano Azure macchine virtuali classiche o un servizio cloud con un FQDN o un indirizzo IP pubblico, assicurarsi di aprire il endpoint corrispondente.
  • Se si configura la macchina virtuale tramite Azure Resource Manager (ARM) e si trova all'esterno della rete virtuale in cui viene distribuito il gateway applicativo, configurare un NSG per consentire l'accesso alla porta desiderata.

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

Configurazione non valida o non corretta delle sonde di salute personalizzate

Motivo

Le sonde di integrità personalizzate offrono maggiore flessibilità rispetto al comportamento di sondaggio predefinito. Quando si usano probe personalizzati, è possibile impostare l'intervallo del probe, l'URL, il percorso da verificare e il numero di risposte fallite da accettare prima di segnare l'istanza del pool back-end come non sano.

Nella tabella seguente vengono descritte le proprietà aggiuntive che è possibile impostare.

Proprietà della probe Descrzione
Nome Nome della sonda. Usare questo nome per fare riferimento alla sonda nelle impostazioni HTTP back-end.
Protocollo Protocollo utilizzato per inviare la sonda. Il probe usa il protocollo definito nelle impostazioni HTTP back-end.
Host Nome dell'host a cui inviare la sonda. Questo nome host è diverso dal nome host della macchina virtuale. Nello SKU v1, Application Gateway usa questo valore solo come intestazione Host della richiesta di probe. Nella SKU v2, il valore viene utilizzato sia come intestazione Host sia come valore di Server Name Indication (SNI).
Percorso Percorso relativo della sonda. Il percorso valido inizia da '/'. La sonda viene inviata al <protocollo>://<host>:<porta><path>.
Intervallo Intervallo di sonda in secondi. Questo valore imposta l'intervallo di tempo tra due probe consecutivi.
Timeout Timeout della sonda in secondi. Se una risposta valida non viene ricevuta entro questo periodo di timeout, la sonda viene contrassegnata come non riuscita.
Soglia non salutare Numero di tentativi di probe. Il server backend viene contrassegnato come inattivo dopo che il numero consecutivo di errori del probe ha raggiunto la soglia di criticità.

Soluzione

Verificare che la sonda di integrità personalizzata sia configurata correttamente, come illustrato nella tabella precedente. Oltre alle indicazioni precedenti per la risoluzione dei problemi, seguire anche queste indicazioni.

  • Assicurati di specificare correttamente il probe in base alla guida.
  • Se si configura il gateway applicativo per un singolo sito, specificare il nome host predefinito come 127.0.0.1, a meno che non lo si configuri diversamente nella sonda personalizzata.
  • Assicurarsi che una chiamata a http://<host>:<port><path> restituisca un codice di risultato HTTP pari a 200.
  • Assicurarsi che Intervali valori , Timeoute UnhealthyThreshold siano compresi negli intervalli accettabili.
  • Se usi un probe HTTPS nello SKU v2, Application Gateway trasmette anche il nome host del probe come valore SNI. Assicurarsi che il nome host corrisponda al nome alternativo del soggetto del certificato back-end (SAN) o al nome comune (CN) se il certificato non ha san, come descritto in RFC 6125. Application Gateway non invia SNI quando il nome host è un indirizzo IP, incluso quello predefinito 127.0.0.1. Per la procedura per confrontare il nome host del probe con il certificato, vedere Risoluzione F in Risolvere gli errori HTTP 502 in gateway applicazione di Azure. Se non è possibile modificare il certificato back-end, modificare le impostazioni di convalida HTTPS back-end per usare un valore SNI specifico o ignorare la convalida del nome soggetto.

È stato superato il timeout della richiesta back-end

Motivo

Quando il gateway delle applicazioni riceve una richiesta di un utente, applica le regole configurate alla richiesta e la instrada a un'istanza del pool backend. Attende un intervallo di tempo configurabile per una risposta dall'istanza back-end. Per impostazione predefinita, questo intervallo è di 20 secondi. In Application Gateway v1, se Application Gateway non riceve una risposta dall'applicazione backend entro questo intervallo, la richiesta dell'utente restituisce un errore 502. In Application Gateway v2, se Application Gateway non riceve una risposta dall'applicazione backend entro questo intervallo, la richiesta viene ritentata su un secondo membro del pool backend. Se anche la seconda richiesta ha esito negativo, la richiesta dell'utente riceve un errore 504. Se gli utenti ricevono errori 504 anziché 502, vedere Risolvere gli errori HTTP 504 in gateway applicazione di Azure.

Se l'applicazione back-end impiega regolarmente più tempo dell'intervallo configurato per rispondere, ad esempio per una query o un report a esecuzione prolungata, aumenta il timeout delle richieste nell'impostazione HTTP del back-end usata da quel pool back-end.

Soluzione

Il timeout della richiesta è una proprietà dell'impostazione HTTP back-end, in modo che pool back-end diversi possano avere valori di timeout della richiesta diversi. Aumentarlo usando il portale di Azure, interfaccia della riga di comando di Azure o Azure PowerShell. L'intervallo accettato è compreso tra 1 e 86400 secondi. Per altre informazioni, vedere Timeout della richiesta.

Azure portal

Segui questi passaggi:

  1. Nel portale di Azure, passa al tuo gateway applicazione.
  2. In Impostazioni selezionare Impostazioni back-end.
  3. Seleziona l'impostazione del backend utilizzata dal pool backend interessato.
  4. Aumentare il valore di timeout della richiesta (secondi) per consentire più tempo per la risposta del back-end.
  5. Seleziona Salva.

Interfaccia della riga di comando di Azure

Nell'interfaccia della riga di comando di Azure, eseguire il comando seguente:

az network application-gateway http-settings update \
  --gateway-name <application-gateway-name> \
  --resource-group <resource-group-name> \
  --name <backend-http-settings-name> \
  --timeout <time-out-in-seconds>

Azure PowerShell

Eseguire il comando seguente in Azure PowerShell:

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

Annotazioni

L'aumento del timeout della richiesta maschera solo il sintomo se il back-end è lento a causa di un problema sottostante, ad esempio utilizzo elevato della CPU o della memoria, contesa del database o query inefficiente. Esaminare anche il tempo di risposta dell'applicazione back-end prima di aumentare il valore di timeout.

Il pool di back-end del gateway applicativo non è configurato o è vuoto

Motivo

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. È possibile controllare questa condizione tramite Azure PowerShell, interfaccia della riga di comando di Azure o il portale. Vedere l'esempio seguente per controllare il pool di indirizzi back-end tramite Azure PowerShell.

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

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

[{
    "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

Motivo

Se tutte le istanze di BackendAddressPool non sono integre, il gateway applicativo non ha nessun back-end a cui instradare le richieste degli utenti. Questa condizione può verificarsi anche quando le istanze back-end sono integre ma non hanno l'applicazione richiesta distribuita.

Soluzione

Assicurarsi 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 si configura un endpoint pubblico, assicurarsi che una richiesta del browser per l'applicazione Web sia utilizzabile.

Il certificato SSL upstream non corrisponde

Motivo

Il certificato Tls (Transport Layer Security) installato nei server back-end non corrisponde al nome host ricevuto nell'intestazione della richiesta host HTTP.

Negli scenari in cui TLS end-to-end è abilitato, effettuare la configurazione modificando le impostazioni pertinenti di Backend HTTP. Modificare la configurazione dell'impostazione del protocollo back-end su HTTPS , se necessario. Assicurarsi che il DNS NAME del certificato TLS installato sui server back-end corrisponda al nome host inviato al back-end nell'intestazione Host della richiesta HTTP.

Dopo aver completato questo passaggio, la seconda parte della comunicazione tra Application Gateway e i server back-end viene crittografata con TLS.

Per impostazione predefinita, Application Gateway invia al back-end la stessa intestazione host HTTP che riceve dal client. Assicurarsi che il certificato TLS installato nel server back-end venga emesso con un oggetto DNS NAME che corrisponde al nome host ricevuto dal server back-end nell'intestazione host HTTP. Questo nome host deve essere uguale a quello ricevuto dal client.

Soluzione

Per la procedura necessaria per allineare il nome host del probe e il valore SNI al SAN o al CN del certificato, vedere la Soluzione F dell'articolo Risolvere gli errori HTTP 502 in gateway applicazione di Azure. Per informazioni su come le impostazioni back-end Scegli nome host dalla destinazione back-end e Sostituisci con un nome di dominio specifico si associano al nome del certificato previsto da Application Gateway, vedere Il nome comune (CN) non corrisponde.

  • Last updated on