Condividi tramite

Risolvere gli errori del gateway difettoso (502) nel gateway di applicazione di Azure

Riassunto

Informazioni su come risolvere gli errori 502 nel Azure Application Gateway, per ripristinare rapidamente l'accesso affidabile alle applicazioni 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.

Informazioni generali

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

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

Motivo

Se l'accesso al back-end è bloccato a causa di un NSG (gruppo di sicurezza di rete), una route definita dall'utente o un DNS personalizzato, le istanze del gateway di applicazione non possono raggiungere il pool del 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, 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 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 il percorso con la VM di back-end.

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

  4. Verificare la presenza di DNS personalizzati nella rete virtuale. Il DNS può essere controllato 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 la sonda di monitoraggio predefinita

Motivo

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

Quando viene effettuato il provisioning di un'istanza del gateway applicativo, configura automaticamente una sonda di integrità predefinita per ogni *BackendAddressPool* usando le proprietà di *BackendHttpSetting*. Per impostare questo probe non è necessario alcun input dell'utente. In particolare, quando viene configurata una regola di bilanciamento del carico, viene eseguita un'associazione tra backendHttpSetting e backendAddressPool. Un sonda predefinita è configurata per ognuna di queste associazioni e il gateway applicativo avvia una connessione periodica di controllo dell'integrità a ogni istanza nel 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 della richiesta è determinato dal protocollo BackendHttpSetting.
  • Il percorso URI è impostato su /.
  • Se BackendHttpSetting specifica una porta diversa da 80, il sito predefinito deve essere configurato 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 ci siano regole del firewall o gruppi di sicurezza di rete di Azure che bloccano il traffico in ingresso o in uscita sulla porta configurata.
  • Se Azure macchina virtuale classica o il servizio cloud viene usato con un FQDN o un indirizzo IP pubblico, assicurarsi che venga aperto il endpoint corrispondente.
  • Se la macchina virtuale viene 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 Network per consentire l'accesso sulla porta desiderata.

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

Problemi con la sonda di salute personalizzata

Motivo

Le sonde di stato personalizzate consentono una maggiore flessibilità rispetto al comportamento di sondaggio predefinito. Quando si usano sonde personalizzate, è possibile configurare l'intervallo della sonda, 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 funzionante.

Vengono aggiunte le proprietà aggiuntive seguenti:

Proprietà della probe Descrzione
Nome Nome della sonda. Questo nome viene usato per fare riferimento al probe 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. Applicabile solo quando il multi-sito è configurato nel gateway applicativo. Questo è diverso dal nome host della macchina virtuale.
Percorso Percorso relativo della sonda. Il percorso valido inizia da '/'. La sonda viene inviata al <protocollo>://<host>:<port><path>
Intervallo Intervallo di sonda in secondi. Questo è 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 stato personalizzata sia configurata correttamente, come illustrato nella tabella precedente. Oltre ai passaggi precedenti per la risoluzione dei problemi, assicurarsi anche quanto segue:

  • Assicurarsi che la sonda sia specificata correttamente in base alla guida.
  • Se il gateway applicativo è configurato per un singolo sito, per impostazione predefinita il nome host deve essere specificato come 127.0.0.1, a meno che non sia diversamente configurato in un probe personalizzato.
  • Assicurarsi che una chiamata a http://< host>:<port><path> restituisca un codice di risultato HTTP 200.
  • Assicurarsi che Interval, Timeout e UnhealthyThreshold siano compresi negli intervalli accettabili.
  • Se si usa un probe HTTPS, verificare che il server backend non richieda SNI configurando un certificato di fallback sul server backend stesso.

Timeout della richiesta

Motivo

Quando si riceve una richiesta da un utente, il gateway di applicazione applica le regole configurate alla richiesta e lo instrada verso 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 Gateway Applicazione v1, se il gateway dell'applicazione non riceve una risposta dall'applicazione backend 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

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

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

BackendAddressPool 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. Questa operazione può essere eseguita 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 che sono configurati con un nome di dominio completo o con 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 attive, il gateway applicativo non dispone di alcun backend 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

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 configurato con un endpoint pubblico, verificare che una richiesta del browser all'applicazione Web sia gestibile.

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 avere il dominio contoso.com delegato a una zona pubblica di Azure DNS e un record DNS in tale zona che punta www.contoso.com all'indirizzo IP pubblico dello specifico Application Gateway che gestirà 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