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

È consigliabile usare il modulo Az PowerShell Azure 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, è possibile che venga visualizzato l'errore 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 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.

Il NSG/UDR può essere presente nella subnet del gateway delle applicazioni o nella subnet dove vengono distribuite le macchine virtuali dell'applicazione.

Analogamente, la presenza di un DNS personalizzato nella rete virtuale potrebbe anche 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 del gruppo di sicurezza di rete, della route definita dall'utente e del DNS seguendo questa procedura:

  1. Controllare i gruppi di sicurezza di rete associati alla subnet del gateway dell'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 delle applicazioni. Assicurarsi che l'UDR non indirizzi il traffico fuori dalla subnet back-end. Ad esempio, verificare la presenza di routing verso appliance virtuali di rete o route predefinite annunciate alla subnet del gateway dell'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 effettivo e l'instradamento con la macchina virtuale del back-end.

    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

Gli errori 502 possono anche indicare che la sonda di integrità predefinita non riesce a raggiungere le macchine virtuali backend.

Quando si effettua il provisioning di un'istanza del gateway delle applicazioni, configura automaticamente una sonda di integrità predefinita a ciascun 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 BackendHttpSetting a un BackendAddressPool. Ognuna di queste associazioni ha un probe predefinito configurato e il gateway applicativo avvia una verifica periodica dello stato di salute per ogni istanza del BackendAddressPool alla porta specificata nell'elemento BackendHttpSetting.

Nella tabella seguente sono elencati i valori associati alla sonda di integrità predefinita:

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

  • 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 protocollo BackendHttpSetting 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.
  • Verificare che la porta configurata sia aperta e che non siano presenti regole 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 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 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 host per inviare la sonda. Questa proprietà si applica solo quando si configura il multisito sul gateway dell'applicazione. Questo nome host è diverso dal nome host della macchina virtuale.
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 ai passaggi precedenti per la risoluzione dei problemi, verificare anche i passaggi seguenti:

  • Assicurati di specificare correttamente il probe in base alla guida.
  • Configurando il gateway di applicazione 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 i valori Interval, Timeout e UnhealthyThreshold siano compresi negli intervalli accettabili.
  • Se usi una sonda HTTPS, assicurati che il server back-end non richieda SNI configurando un certificato di fallback sul server back-end stesso.

Timeout della richiesta o problemi di connessione con le richieste degli utenti

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. Nel gateway delle applicazioni v1, se il gateway delle applicazioni non riceve una risposta dall'applicazione di back-end in questo intervallo, la richiesta dell'utente riceve un errore 502. Nel gateway applicativo v2, se il gateway applicativo non riceve una risposta dall'applicazione back-end in questo intervallo, la richiesta viene effettuata con un secondo membro del pool back-end. Se la seconda richiesta ha esito negativo, la richiesta dell'utente riceve un errore 504.

Soluzione

È possibile configurare questa impostazione tramite BackendHttpSetting, che è possibile applicare a pool diversi. Pool back-end diversi possono avere configurazioni BackendHttpSetting diverse e impostazioni di timeout delle richieste diverse.

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

Il pool back-end del gateway delle applicazioni 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 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 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.

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

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 installato nei server back-end non corrisponde al nome host ricevuto nell'intestazione della richiesta host.

Negli scenari in cui è abilitato TLS end-to-end, 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 NOME DNS 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" l'opzione di protocollo HTTPS anziché HTTP è che la seconda parte della comunicazione che avviene tra le istanze del gateway applicazione e i server back-end vengono crittografate con TLS.

Poiché per impostazione predefinita il gateway applicazione invia la stessa intestazione host HTTP al back-end che riceve dal client, è necessario assicurarsi che il certificato TLS installato sul server back-end sia emesso con un nome DNS che corrisponda 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.

Per esempio:

Si supponga di avere un gateway applicazione per gestire le richieste https per il dominio www.contoso.com. È possibile che il dominio contoso.com sia delegato a una zona pubblica DNS di Azure e un record A DNS in quella zona che punta www.contoso.com all'indirizzo IP pubblico del gateway applicativo specifico che servirà le richieste.

Nel Gateway Applicazione è necessario disporre di un listener per l'host www.contoso.com con una regola con "Impostazione HTTP di backend" forzata a utilizzare il protocollo HTTPS (assicurando 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 'Back-end HTTP' della regola rende la seconda parte della comunicazione che avviene tra le istanze dell'Application Gateway e i server nel back-end ad utilizzare TLS.

Se i server back-end non dispongono di un certificato TLS emesso per il NOME www.contoso.com DNS o *.contoso.com, la richiesta non riesce 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 corrisponde al nome host nell'intestazione host, e quindi la negoziazione TLS ha 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 di backend --> Server Web (deve avere un certificato TLS installato per www.contoso.com)

Soluzione

È necessario che il NOME DNS 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, ha esito negativo con "Il certificato SSL upstream non corrisponde" e genera un errore del server: 502 - Il server Web ha ricevuto una risposta non valida mentre funge da gateway o server proxy

  • Last updated on