Condividi tramite

Configurazione delle impostazioni di backend dell'applicazione gateway

Le impostazioni del backend consentono di gestire le configurazioni per le connessioni backend stabilite da una risorsa del gateway di applicazione a un server nel pool backend. Una configurazione delle impostazioni back-end può essere associata a una o più regole di routing.

Tipi di impostazioni del back-end nel gateway dell'applicazione

Mentre gli utenti del portale visualizzeranno solo l'opzione "Impostazioni back-end", gli utenti dell'API avranno accesso a due tipi di impostazioni. È necessario utilizzare la configurazione corretta, in base al protocollo.

  • Impostazioni HTTP back-end: si tratta di configurazioni proxy di livello 7 che supportano i protocolli HTTP e HTTPS.
  • Impostazioni back-end: si tratta di configurazioni proxy di livello 4 (anteprima) che supportano i protocolli TLS e TCP.

Il gateway applicazione di Azure usa i cookie gestiti dal gateway per gestire le sessioni utente. Quando un utente invia la prima richiesta ad Application Gateway, imposta un cookie di affinità nella risposta con un valore hash contenente i dettagli della sessione. Questo processo consente alle richieste successive che trasportano il cookie di affinità di essere instradate allo stesso server back-end, mantenendo così la persistenza.

Questa funzionalità è utile quando si desidera mantenere una sessione utente nello stesso server e quando lo stato della sessione viene salvato localmente nel server per una sessione utente. Se l'applicazione non è in grado di gestire l'affinità basata su cookie, non è possibile usare questa funzionalità. Per usarla, assicurarsi che i client supportino i cookie.

Nota

Alcune analisi di vulnerabilità possono contrassegnare il cookie di affinità del gateway applicazione perché i flag Secure o HttpOnly non sono impostati. Queste analisi non prendono in considerazione che i dati nel cookie vengono generati usando un hash unidirezionale. Il cookie non contiene informazioni sull'utente e viene usato esclusivamente per il routing.

L'aggiornamento del browserChromium v80 ha portato un mandato in cui i cookie HTTP senza attributo SameSite devono essere trattati come SameSite=Lax. Per le richieste CORS (condivisione di risorse tra le origini), se il cookie deve essere inviato in un contesto di terze parti, deve usare gli attributi SameSite=None; Secure e deve essere inviato solo tramite HTTPS. In caso contrario, in uno scenario solo HTTP, il browser non invia i cookie nel contesto di terze parti. L'obiettivo di questo aggiornamento da Chrome è quello di migliorare la sicurezza e di evitare attacchi CSRF (Cross-Site Request Forgery).

Per supportare questa modifica, a partire dal 17 febbraio 2020, il gateway applicazione (tutti i tipi di SKU) inserirà un altro cookie denominato ApplicationGatewayAffinityCORS oltre al cookie ApplicationGatewayAffinityesistente. Il cookie ApplicationGatewayAffinityCORS contiene altri due attributi aggiunti ("SameSite=None; Proteggere") in modo che le sessioni permanenti vengano mantenute anche per le richieste tra le origini.

Il nome predefinito del cookie di affinità è ApplicationGatewayAffinity ed è possibile modificarlo. Se nella topologia di rete si distribuiscono più gateway applicazione in linea, è necessario impostare nomi di cookie univoci per ogni risorsa. Se si usa un nome di cookie di affinità personalizzato, viene aggiunto un cookie aggiuntivo con CORS come suffisso. Ad esempio: CustomCookieNameCORS.

Nota

Se l'attributo SameSite=None è impostato, è obbligatorio che il cookie contenga anche il flag Secure e che deve essere inviato tramite HTTPS. Se l'affinità di sessione è necessaria su CORS, è necessario eseguire la migrazione del carico di lavoro a HTTPS. Fare riferimento alla documentazione di offload TLS e TLS end-to-end per il gateway applicativo. Vedi la panoramica di SSL, Configurare un gateway di applicazione con la terminazione TLS e Configurare TLS end-to-end.

Svuotamento della connessione

Lo svuotamento delle connessioni consente di rimuovere normalmente i membri del pool back-end durante gli aggiornamenti pianificati del servizio. Si applica alle unità di backend che vengono rimosse esplicitamente dal gruppo di backend.

È possibile applicare questa impostazione a tutti i membri del pool back-end abilitando lo svuotamento delle connessioni nell'impostazione back-end. Garantisce che tutte le istanze di registrazione in un pool back-end non ricevano nuove richieste/connessioni mantenendo le connessioni esistenti fino al valore di timeout configurato. Questo processo è valido anche per le connessioni WebSocket.

Tipo configurazione Valore
Valore predefinito quando lo svuotamento della Connessione non è abilitato nell'impostazione del back-end 30 secondi
Valore definito dall'utente quando lo svuotamento della connessione è abilitato nell'impostazione back-end Da 1 a 3600 secondi

L'unica eccezione a questo processo sono le richieste destinate alla deregistrazione delle istanze a causa dell'affinità di sessione gestita dal gateway. Queste richieste continuano a essere inoltrate alle istanze di deregistrazione.

Nota

Esiste una limitazione in cui un aggiornamento della configurazione terminerà le connessioni in corso dopo il timeout di svuotamento della connessione. Per risolvere questa limitazione, è necessario aumentare il timeout di svuotamento della connessione nelle impostazioni back-end a un valore superiore al tempo massimo di download del client previsto.

Protocollo

Il gateway applicazione supporta sia HTTP che HTTPS per il routing delle richieste ai server back-end. Se si sceglie HTTP, il traffico verso i server back-end non è crittografato. Se la comunicazione non crittografata non è accettabile, scegliere HTTPS.

Questa impostazione combinata con HTTPS nel listener supporta TLS end-to-end. In questo modo è possibile trasmettere in modo sicuro i dati sensibili crittografati al back-end. Ogni server back-end nel pool back-end con TLS end-to-end abilitato deve essere configurato con un certificato per consentire la comunicazione sicura.

Porta

Questa impostazione specifica la porta in cui i server back-end sono in ascolto del traffico dal gateway applicazione. È possibile configurare porte comprese tra 1 e 65535.

Certificato radice trusted

Quando si seleziona il protocollo HTTPS nelle impostazioni back-end, la risorsa del gateway dell'applicazione usa l'archivio certificati CA radice attendibile predefinito per verificare la catena e l'autenticità del certificato fornito dal server back-end.

Per impostazione predefinita, la risorsa gateway applicazione include i certificati CA più diffusi, consentendo connessioni TLS back-end senza interruzioni quando il certificato del server back-end viene rilasciato da una CA pubblica. Tuttavia, se si intende usare una CA privata o un certificato autogenerato, è necessario fornire il certificato CA radice corrispondente (.cer) in questa configurazione delle impostazioni back-end.

Timeout richiesta

Questa impostazione è il numero di secondi durante i quali il gateway applicazione resta in attesa di ricevere una risposta dal server back-end. Il valore predefinito è 20 secondi. Tuttavia, è possibile modificare questa impostazione in base alle esigenze dell'applicazione.

Sostituisci percorso back-end

Questa impostazione consente di configurare un percorso di inoltro personalizzato facoltativo da usare quando la richiesta viene inoltrata al back-end. Qualsiasi parte del percorso in ingresso corrispondente al percorso personalizzato nel campo percorso back-end di override viene copiata nel percorso inoltrato. La tabella seguente illustra il funzionamento di questa funzionalità:

  • Quando l'impostazione HTTP è collegata a una regola di routing delle richieste di base:

    Richiesta originale Sostituisci percorso back-end Richiesta inoltrata al back-end
    /casa/ /sovrascrivere/ /override/home/
    /home/secondhome/ /sovrascrivere/ /override/home/secondhome/

  • Quando l'impostazione HTTP è collegata a una regola di routing delle richieste basata sul percorso:

    Richiesta originale Regola percorso Sostituisci percorso back-end Richiesta inoltrata al back-end
    /pathrule/home/ /pathrule* /sovrascrivere/ /override/home/
    /regolaper/percorso/casa/secondacasa/ /pathrule* /sovrascrivere/ /override/home/secondhome/
    /casa/ /pathrule* /sovrascrivere/ /override/home/
    /home/secondhome/ /pathrule* /sovrascrivere/ /override/home/secondhome/
    /pathrule/home/ /pathrule/home* /sovrascrivere/ /sovrascrivere/
    /regolaper/percorso/casa/secondacasa/ /pathrule/home* /sovrascrivere/ /override/secondhome/
    /regola del percorso/ /regola del percorso/ /sovrascrivere/ /sovrascrivere/

Usa probe personalizzato

Questa impostazione associa un probe personalizzato a un'impostazione HTTP. È possibile associare un solo probe personalizzato a un'impostazione HTTP. Se non si associa in modo esplicito un probe personalizzato, il probe predefinito viene usato per monitorare l'integrità del back-end. È consigliabile creare un probe personalizzato per un maggiore controllo sull'integrità dei back-end.

Nota

Il probe personalizzato non monitora l'integrità del pool back-end, a meno che l'impostazione HTTP corrispondente non sia associata in modo esplicito a un listener.

Configurazione del nome host

Il gateway applicazione consente alla connessione stabilita al back-end di usare un nome host diverso da quello usato dal client per connettersi al gateway applicazione. Anche se questa configurazione può essere utile in alcuni casi, prestare attenzione quando si modifica il nome host in modo che sia diverso tra il gateway dell'applicazione e il client rispetto alla destinazione backend.

Negli ambienti di produzione, è buona norma usare lo stesso nome host per la connessione del client al gateway dell'applicazione e la connessione del gateway dell'applicazione al back-end di destinazione. Questa procedura evita potenziali problemi con URL assoluti, URL di reindirizzamento e cookie associati a host.

Prima di configurare un gateway applicativo che si discosta da quanto indicato, esaminare le implicazioni di tale configurazione come descritto più dettagliatamente nel Centro di Architettura: Mantenere il nome host HTTP originale tra un proxy inverso e l'applicazione Web back-end

Esistono due aspetti di un'impostazione HTTP che influiscono sull'intestazione HTTP Host usata dal gateway applicazione per connettersi al back-end:

  • “Nome host di selezione dall'indirizzo back-end”
  • “Override del nome host”

Selezionare nome host dall'indirizzo back-end

Questa funzionalità imposta dinamicamente l'intestazione host nella richiesta sul nome host del pool back-end. Usa un indirizzo IP o un nome di dominio completo.

Questa funzionalità è utile quando il nome di dominio del back-end è diverso dal nome DNS del gateway applicazione e il back-end si basa su un'intestazione host specifica per risolvere l'endpoint corretto.

Un caso di esempio è costituito da servizi multi-tenant come back-end. Un servizio app è un servizio multi-tenant che usa uno spazio condiviso con un singolo indirizzo IP. È quindi possibile accedere a un servizio app solo tramite i nomi host configurati nelle impostazioni di dominio personalizzate.

Per impostazione predefinita, il nome di dominio personalizzato è example.azurewebsites.net. Per accedere al servizio app usando un gateway applicazione tramite un nome host non registrato in modo esplicito nel servizio app o tramite il nome di dominio completo del gateway applicazione, è possibile eseguire l'override del nome host nella richiesta originale al nome host del servizio app. A tale scopo, abilitare l'impostazione seleziona nome host dall'indirizzo back-end.

Per un dominio personalizzato il cui nome DNS personalizzato esistente è mappato al servizio app, la configurazione consigliata è di non abilitare selezionare il nome host dall'indirizzo back-end.

Nota

Questa impostazione non è necessaria per l'ambiente del servizio app, ovvero una distribuzione dedicata.

Override nome host

Questa funzionalità sostituisce l'intestazione host nella richiesta in ingresso nel gateway applicazione con il nome host specificato.

Ad esempio, se www.contoso.com viene specificato nell'impostazione Nome host , la richiesta originale *https://appgw.eastus.cloudapp.azure.com/path1 viene modificata in *https://www.contoso.com/path1 quando la richiesta viene inoltrata al server back-end.

Passaggi successivi