Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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.
Affinità basata sui cookie
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.
Note
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.
Il browser Chromiumaggiornamento v80 ha portato un mandato in cui i cookie HTTP senza attributo SameSite devono essere considerati 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.
Note
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. Vedere la documentazione di TLS offload e TLS end-to-end per il gateway applicazione. Vedere la panoramica di SSL, Configurare un gateway applicazione con la terminazione TLS e Configurare TLS end-to-end.
Esaurimento delle connessioni
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 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 di cancellazione delle istanze a causa dell'affinità di sessione gestita dal gateway. Queste richieste continuano a essere inoltrate alle istanze di deregistrazione.
Note
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 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 con convalida TLS completa, è necessario fornire il certificato CA radice corrispondente (.cer) nella configurazione delle impostazioni back-end.
Impostazioni di convalida HTTPS back-end
Quando HTTPS è selezionato nelle impostazioni back-end del gateway applicazione di Azure, il gateway esegue la convalida completa dell'handshake TLS durante la creazione di una connessione sicura con i server back-end. Queste convalide includono:
- Verifica della catena di certificati per verificare che il certificato sia attendibile.
- Verifica del nome soggetto del certificato rispetto all'indicazione del nome del server (SNI) inviata da Application Gateway.
- Verifica della scadenza del certificato per verificare se il certificato è ancora valido.
Le impostazioni di convalida predefinite garantiscono la comunicazione TLS sicura tra il gateway e i servizi back-end. In alcuni scenari potrebbe essere necessario modificare una o più di queste impostazioni di convalida. Per soddisfare diversi requisiti dei clienti, il gateway applicazione offre le opzioni configurabili seguenti. È possibile usare una o entrambe le opzioni in base alle esigenze.
| Proprietà | Valori |
|---|---|
| validateCertChainAndExpiry | Tipo: booleano (true o false). L'impostazione predefinita è true. In questo modo viene verificata o ignorata sia la catena di certificati che le verifiche di scadenza. |
| validateSNI | Tipo: booleano (true o false). L'impostazione predefinita è true. Verifica se il nome comune del certificato fornito dal server backend corrisponde al valore SNI (Server Name Indication) inviato dal gateway dell'applicazione. |
| sniName | Tipo: String. Questa proprietà è obbligatoria solo quando validateSNI è impostato su true. È possibile specificare un valore SNI in modo che corrisponda al nome comune del certificato nel back-end. Per impostazione predefinita, il gateway applicazione usa l'intestazione host della richiesta in ingresso come SNI. |
Note
- È consigliabile mantenere tutte le convalide abilitate per gli ambienti di produzione. La disabilitazione di alcune o tutte le convalide è consigliata solo per scopi di test e sviluppo, ad esempio quando vengono usati certificati autofirmati.
- Queste impostazioni non si applicano alla funzionalità del probe di test quando si aggiunge un probe di integrità personalizzato. Di conseguenza, è possibile riscontrare differenze nei risultati nel confronto con i probe di integrità periodici.
- Attualmente, non supportato per il proxy TLS.
- PowerShell e l'interfaccia della riga di comando saranno presto supportati.
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. I valori accettabili sono compresi tra 1 secondo e 86400 secondi (24 ore).
Override del 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 Override del percorso back-end Richiesta inoltrata al back-end /casa/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ Quando l'impostazione HTTP è collegata a una regola di routing delle richieste basata sul percorso:
Richiesta originale Regola percorso Override del percorso back-end Richiesta inoltrata al back-end /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /casa/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /regola del percorso/ /regola del percorso/ /override/ /override/
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.
Note
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 esegue l'override del nome host in modo che sia diverso tra il gateway applicazione e il client rispetto alla destinazione back-end.
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.
Note
Questa impostazione non è necessaria per l'ambiente del servizio app, ovvero una distribuzione dedicata.
Override del 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.
Connessione back-end dedicata
Il gateway applicazione di Azure, per impostazione predefinita, riutilizza le connessioni back-end inattive per ottimizzare l'utilizzo delle risorse delle connessioni TCP sia per il gateway applicazione che per il server back-end. Per supportare le funzioni di sicurezza nei percorsi dei dati dei clienti che richiedono connessioni back-end univoche per cliente, Azure Application Gateway V2 fornisce connessioni dedicate ai server back-end.
Questa funzionalità stabilisce un mapping diretto uno-a-uno tra connessioni front-end e back-end, garantendo la connettività permanente per ogni singolo client.
Note
Per abilitare l'autenticazione pass-through NTLM o Kerberos, assicurarsi che l'impostazione della connessione dedicata al back-end sia attivata. Questa configurazione mantiene un mapping uno-a-uno tra connessioni front-end e back-end, essenziale per mantenere l'integrità della sessione richiesta da questi protocolli di autenticazione.
Importante
La connessione back-end dedicata comporta un aumento del numero di connessioni back-end e quindi potrebbe richiedere più risorse per supportare le connessioni simultanee aumentate nel gateway applicazione e nei server back-end. Nel Gateway Applicazione, è necessario prendere in considerazione l'aumento del numero di istanze o abilitare la scalabilità automatica.
Quando il back-end è un server remoto, le istanze del gateway applicazione usano le porte SNAT per ogni connessione. Quando ogni connessione client stabilisce una connessione back-end dedicata, il consumo di porte SNAT aumenta in modo corrispondente. Pertanto, è importante tenere conto del potenziale esaurimento delle porte SNAT. Per indicazioni, vedere le procedure consigliate per l'architettura .
La connessione back-end dedicata non è supportata con HTTP/2.