Pianificare e implementare un gateway applicazione di Azure

• 10 minuti

Il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web (livello OSI 7) che consente di gestire il traffico verso le applicazioni Web. I servizi di bilanciamento del carico tradizionali operano a livello di trasporto (OSI livello 4 - TCP e UDP) ed eseguono il routing del traffico da un indirizzo IP e una porta di origine verso un indirizzo IP e una porta di destinazione.

Il gateway applicazione consente di prendere decisioni relative al routing basate su altri attributi di una richiesta HTTP, ad esempio il percorso dell'URI o le intestazioni host. Ad esempio, è possibile eseguire il rounting del traffico in base all'URL in ingresso. Quindi se /images è incluso nell'URL in ingresso, è possibile instradare il traffico a un set specifico di server, detto pool, configurato per le immagini. Se /video è incluso nell'URL, il traffico viene instradato a un altro pool ottimizzato per i video.

Questo tipo di routing è detto bilanciamento del carico a livello di applicazione (OSI livello 7). Il gateway applicazione di Azure può eseguire il routing basato su URL e molto altro.

Componenti del gateway applicazione

Un gateway applicazione funge da unico punto di contatto per i client. Distribuisce il traffico delle applicazioni in ingresso tra più pool back-end, tra cui macchine virtuali di Azure, set di scalabilità di macchine virtuali, Servizio app di Azure e server locali o esterni.

Infrastruttura

L'infrastruttura del gateway applicazione include la rete virtuale, le subnet, i gruppi di sicurezza di rete e le route definite dall'utente.

Indirizzo IP front-end IP

È possibile configurare il gateway applicazione con un indirizzo IP pubblico, un indirizzo IP privato o entrambi. È necessario un IP pubblico quando si ospita un back-end a cui i client devono accedere via Internet tramite un IP virtuale (VIP) con connessione a Internet.

Per un endpoint interno non esposto a Internet non occorre un IP pubblico. Una configurazione di front-end privato è utile per le applicazioni line-of-business interne che non sono esposte a Internet. È utile anche per i servizi e i livelli di un'applicazione multilivello all'interno di un limite di sicurezza che non sono esposti a Internet, ma che richiedono la distribuzione round robin del carico, la persistenza della sessione o la terminazione TLS.

Sono supportati un solo IP pubblico e un solo IP privato. Si sceglie l'IP front-end al momento della creazione del gateway applicazione.

• Per quanto riguarda gli IP pubblici, è possibile crearne uno nuovo o usare un IP pubblico esistente nella stessa posizione del gateway applicazione. Per altre informazioni, vedere la differenza tra IP pubblico statico e dinamico.
• Per quanto riguarda gli IP privati, è possibile specificare un IP privato della subnet in cui viene creato il gateway applicazione. Per le distribuzioni dello SKU del gateway applicazione v2, quando si aggiunge un indirizzo IP privato al gateway è necessario definire un indirizzo IP statico. Per le distribuzioni dello SKU del gateway applicazione v1, se non si specifica un indirizzo IP, viene selezionato automaticamente un indirizzo IP disponibile nella subnet. Il tipo di indirizzo IP selezionato (statico o dinamico) non può essere modificato in un secondo momento.

Un indirizzo IP front-end è associato a un listener che verifica la presenza di richieste in ingresso all'IP front-end.

È possibile creare listener privati e pubblici con lo stesso numero di porta. Prestare però attenzione alla presenza di gruppi di sicurezza di rete (NSG) associati alla subnet del gateway applicazione. In base alla configurazione del gruppo di sicurezza di rete, può essere necessaria una regola per consentire le comunicazioni in ingresso in cui sono specificati come indirizzi IP di destinazione gli IP del front-end pubblico e del front-end privato del gateway applicazione. Quando si usa la stessa porta, il gateway applicazione modifica la Destinazione del flusso in ingresso negli indirizzi IP front-end del gateway.

Regola in ingresso:

• Origine: in base alle esigenze
  
• Destinazione: IP dei front-end pubblico e privato del gateway applicazione.
• Porta di destinazione: in base ai listener configurati
• Protocollo: TCP

Regola in uscita: nessun requisito specifico

Listener

Un listener è un'entità logica che verifica la presenza di richieste di connessione in ingresso usando la porta, il protocollo, l'host e l'indirizzo IP. Quando si configura il listener, è necessario immettere i valori per quelli che corrispondano ai valori corrispondenti nella richiesta in ingresso nel gateway.

Quando si crea un gateway applicazione usando il portale di Azure, si crea anche un listener predefinito scegliendo il protocollo e la porta. È possibile scegliere se abilitare il supporto HTTP2 nel listener. Dopo aver creato il gateway applicazione, è possibile modificare le impostazioni del listener predefinito (appGatewayHttpListener) o creare nuovi listener.

Tipo di listener

Un listener è un'entità logica che verifica la presenza di richieste di connessione in ingresso. Un listener accetta una richiesta se il protocollo, la porta, il nome host e l'indirizzo IP associati alla richiesta corrispondono agli stessi elementi associati alla configurazione del listener.

Prima di usare un gateway applicazione è necessario aggiungere almeno un listener. Un gateway applicazione può disporre di più listener, che possono essere usati per lo stesso protocollo.

Quando un listener rileva richieste in ingresso dai client, il gateway applicazione instrada queste richieste ai membri nel pool back-end configurato nella regola.

I listener supportano le porte e i protocolli descritti di seguito.

Porti

La porta è la posizione in cui un listener è in ascolto delle richieste dei client. È possibile configurare le porte per gli SKU v1 e v2 come indicato di seguito.

SKU	Intervallo di porte supportato	Eccezioni
V2	Da 1 a 64999	22
V1	Da 1 a 65502	3389

Protocolli

Il gateway applicazione supporta quattro protocolli, HTTP, HTTPS, HTTP/2 e WebSocket:

• Specificare i protocolli HTTP o HTTPS nella configurazione del listener.
• Il supporto per i protocolli WebSocket e HTTP/2 viene fornito in modo nativo e il supporto di WebSocket è abilitato per impostazione predefinita. Non esistono impostazioni configurabili dall'utente per abilitare o disabilitare in modo selettivo il supporto di WebSocket. Usare WebSocket con i listener HTTP e HTTPS.

Usare un listener HTTPS per la terminazione TLS. Un listener HTTPS esegue l'offload della operazioni di crittografia e decrittografia al gateway applicazione, in modo da non sovraccaricare i server Web.

Richiedere regole di routing

Quando si crea un gateway applicazione usando il portale di Azure, si crea una regola predefinita (rule1). Questa regola associa il listener predefinito (appGatewayHttpListener) al pool back-end predefinito (appGatewayBackendPool) e alle impostazioni HTTP back-end predefinite (appGatewayBackendHttpSettings). Dopo aver creato il gateway, è possibile modificare le impostazioni della regola predefinita o creare nuove regole.

Tipo di regola

Quando si crea una regola, è possibile scegliere tra base e basata sul percorso.

• Scegliere quella di base se si desidera inoltrare tutte le richieste nel listener associato (ad esempio blog.contoso.com/ *) a un singolo pool back-end.
  
• Scegliere quella basata sul percorso se si desidera instradare le richieste da percorsi URL specifici a pool back-end specifici. Il modello di percorso viene applicato solo al percorso dell'URL, non ai relativi parametri di query.

Listener associato

Associare un listener alla regola in modo che la regola di routing delle richieste associata al listener venga valutata per determinare il pool back-end a cui instradare la richiesta.

Pool back-end associato

Associare alla regola il pool back-end che contiene le destinazioni back-end che gestiscono le richieste ricevute dal listener.

• Per una regola di base, è consentito un solo pool back-end. Tutte le richieste nel listener associato vengono inoltrate a tale pool back-end.
  
• Per una regola basata su percorso, aggiungere più pool back-end che corrispondono a ogni percorso URL. Le richieste che corrispondono al percorso URL immesso vengono inoltrate al pool back-end corrispondente. Aggiungere anche un pool back-end predefinito. Le richieste che non corrispondono ad alcun percorso URL nella regola vengono inoltrate a tale pool.
  

Impostazione HTTP back-end associata

Aggiungere un'impostazione HTTP back-end per ogni regola. Le richieste vengono instradate dal gateway applicazione alle destinazioni back-end usando il numero di porta, il protocollo e altre informazioni specificate in questa impostazione.

Per una regola di base, è consentita una sola impostazione HTTP back-end. Tutte le richieste nel listener associato vengono inoltrate alle destinazioni back-end corrispondenti usando questa impostazione HTTP.

Per una regola basata sul percorso, aggiungere più impostazioni HTTP back-end che corrispondono a ogni percorso URL. Le richieste che corrispondono al percorso URL in questa impostazione vengono inoltrate alle destinazioni back-end corrispondenti usando le impostazioni HTTP corrispondenti a ogni percorso URL. Aggiungere anche un'impostazione HTTP predefinita. Le richieste che non corrispondono ad alcun percorso URL in questa regola vengono inoltrate al pool back-end predefinito usando l'impostazione HTTP predefinita.

Impostazione del reindirizzamento

Se il reindirizzamento è configurato per una regola di base, tutte le richieste nel listener associato vengono reindirizzate alla destinazione. Si tratta di reindirizzamento globale. Se il reindirizzamento è configurato per una regola basata su percorso, vengono reindirizzate solo le richieste in un'area del sito specifica. Un esempio è un'area del carrello acquisti indicata da /cart/*. Questo è il reindirizzamento basato su percorso.

Listener

Scegliere il listener come destinazione di reindirizzamento per reindirizzare il traffico da un listener a un altro nel gateway. Questa impostazione è necessaria quando si vuole abilitare il reindirizzamento da HTTP a HTTPS. Reindirizza il traffico dal listener di origine, che verifica la presenza di richieste HTTP in ingresso, al listener di destinazione, che verifica la presenza di richieste HTTPS in ingresso. È anche possibile scegliere di includere la stringa di query e il percorso della richiesta originale nella richiesta inoltrata alla destinazione di reindirizzamento.

Sito esterno

Scegliere un sito esterno per reindirizzare il traffico nel listener associato a questa regola a un sito esterno. È possibile scegliere di includere la stringa di query della richiesta originale nella richiesta inoltrata alla destinazione di reindirizzamento. Non è possibile inoltrare il percorso al sito esterno presente nella richiesta originale.

Riscrivere l'URL e le intestazioni HTTP

Usando le regole di riscrittura, è possibile aggiungere, rimuovere o aggiornare le intestazioni delle richieste e delle risposte HTTP(S), nonché i parametri del percorso URL e della stringa di query quando i pacchetti di richieste e risposte si spostano tra il client e i pool back-end tramite il gateway applicazione.

Le intestazioni e i parametri URL possono essere impostati su valori statici o su altre intestazioni e variabili server. Ciò consente di usare casi d'uso importanti, ad esempio l'estrazione di indirizzi IP client, la rimozione di informazioni riservate sul back-end, l'aggiunta di maggiore sicurezza e così via.

Impostazioni HTTP

Il gateway applicazione instrada il traffico ai server back-end usando la configurazione specificata qui. Dopo aver creato un'impostazione HTTP, è necessario associarla a una o più regole di routing delle richieste.

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 al gateway applicazione, imposta un cookie di affinità nella risposta con un valore hash che contiene i dettagli della sessione, in modo che le richieste successive che trasportano il cookie di affinità vengano instradate allo stesso server back-end per mantenere 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.

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 istanze back-end che sono

• rimosse in modo esplicito dal pool back-end,
  
• rimosse durante le operazioni di scalabilità orizzontale o
• segnalate come non integre dai probe di integrità.

È 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 vale 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 è costituita dalle richieste associate per la deregistrazione delle istanze a causa dell'affinità di sessione gestita dal gateway e continueranno a essere inoltrate alle istanze di deregistrazione.

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

Se si seleziona HTTPS come protocollo back-end, il gateway applicazione richiede un certificato radice attendibile per considerare attendibile il pool back-end per SSL end-to-end. Per impostazione predefinita, l'opzione Usa un certificato CA noto è impostata su No. Se si prevede di usare un certificato autofirmato o un certificato firmato da un'autorità di certificazione interna, è necessario fornire al gateway applicazione il certificato pubblico corrispondente che verrà usato dal pool back-end. Questo certificato deve essere caricato direttamente nel gateway applicazione in . Formato CER.

Se si prevede di usare un certificato nel pool back-end firmato da un'autorità di certificazione pubblica attendibile, è possibile impostare l'opzione Usa certificato CA noto su Sì e ignorare il caricamento di un certificato pubblico.

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.

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	Override del percorso back-end	Richiesta inoltrata al back-end
/home/	/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/
/home/	/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/
/pathrule/	/pathrule/	/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.

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, è consigliabile eseguire con attenzione l’override dell'hostname, che deve essere diverso tra il client e il gateway applicazione e tra il gateway applicazione e la destinazione backend.

Nell'ambiente di produzione, è consigliabile mantenere il nome host usato dal client verso il gateway applicazione come lo stesso nome host usato dal gateway applicazione alla destinazione back-end. In questo modo si evitano potenziali problemi correlati a URL assoluti, URL di reindirizzamento e cookie associati all'host.

Prima di configurare il gateway applicazione in modo diverso, esaminare le implicazioni di questa configurazione, descritte in dettaglio in Centro architetture: Mantenere il nome host HTTP originale tra un proxy inverso e l'applicazione Web back-end.

Ci sono due impostazioni della configurazione 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 nome host

Nome host di selezione 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.

Ad esempio, questo è il caso di un back-end rappresentato da un servizio multi-tenant. Un servizio app è un servizio multi-tenant che usa uno spazio condiviso con un unico 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 è non abilitare Nome host di selezione dall'indirizzo back-end.

Override nome host

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

Ad esempio, se nell'impostazione Nome host è specificato www.contoso.com, 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.

Pool back-end

È possibile puntare un pool back-end a quattro tipi di membri back-end: una macchina virtuale specifica, un set di scalabilità di macchine virtuali, un indirizzo IP/FQDN o un servizio app.

Dopo aver creato un pool back-end, è necessario associarlo a una o più regole di routing delle richieste. È anche necessario configurare i probe di integrità per ogni pool back-end nel gateway applicazione. Quando viene soddisfatta una condizione della regola di routing delle richieste, il gateway applicazione inoltra il traffico ai server integri (come determinato dai probe di integrità) nel pool back-end corrispondente.

Probe di integrità

Il gateway applicazione di Azure monitora lo stato di integrità di tutti i server nel pool back-end e interrompe automaticamente l'invio del traffico a qualsiasi server considerato non integro. I probe continuano a monitorare un server non integro e il gateway avvia nuovamente il routing del traffico a tale server non appena i probe lo rilevano come integri.

Il probe predefinito usa il numero di porta dell'impostazione back-end associata e altre configurazioni predefinite. È possibile usare probe personalizzati per configurarli in modo personalizzato.

Comportamento dei probe

Indirizzo IP di origine

L'indirizzo IP di origine dei probe dipende dal tipo di server back-end:

• Se il server nel pool back-end è un endpoint pubblico, l'indirizzo di origine sarà l'indirizzo IP pubblico front-end del gateway applicazione.
  
• Se il server nel pool back-end è un endpoint privato, l'indirizzo IP di origine proviene dallo spazio indirizzi della subnet del gateway applicazione.

Operazioni probe

Un gateway avvia la generazione di probe immediatamente dopo aver configurato una regola associandola a un'impostazione back-end e a un pool back-end (e il listener, naturalmente). La figura mostra che il gateway esegue il probe indipendente di tutti i server del pool back-end. Le richieste in ingresso che iniziano ad arrivare vengono inviate solo ai server integri. Un server back-end è contrassegnato come non integro per impostazione predefinita fino a quando non viene ricevuta una risposta probe corretta.

I probe necessari vengono determinati in base alla combinazione univoca del server back-end e dell'impostazione back-end. Si consideri ad esempio un gateway con un singolo pool back-end con due server e due impostazioni back-end, ognuna con numeri di porta diversi. Quando queste impostazioni back-end distinte sono associate allo stesso pool back-end che usa le rispettive regole, il gateway crea probe per ogni server e la combinazione dell'impostazione back-end. È possibile visualizzare questa opzione nella pagina Integrità back-end.

Inoltre, tutte le istanze del gateway applicazione eseguono il probe dei server back-end in modo indipendente l'una dall'altra.

Probe di integrità predefinito

Un gateway applicazione configura automaticamente un probe di integrità predefinito quando non si configura nessuna configurazione di probe personalizzato. Il comportamento di monitoraggio funziona effettuando una richiesta HTTP GET agli indirizzi IP o al nome di dominio completo configurato nel pool back-end. Per i probe predefiniti, se le impostazioni HTTP del back-end vengono configurate per HTTPS, il probe usa HTTPS per testare l'integrità dei server back-end.

Ad esempio, si configura il gateway applicazione per usare i server back-end A, B e C per ricevere il traffico di rete HTTP sulla porta 80. Il monitoraggio dell'integrità predefinito testa i tre server ogni 30 secondi per una risposta HTTP integra con un timeout di 30 secondi per ogni richiesta. Una risposta HTTP integra ha un codice di stato compreso tra 200 e 399. In questo caso, la richiesta HTTP GET per il probe di integrità è simile a http://127.0.0.1/. Vedere anche Codici di risposta HTTP nel gateway applicazione.

Se la verifica del probe predefinito non riesce per il server A, il gateway applicazione interrompe l'inoltro delle richieste a questo server. Il probe predefinito continua tuttavia a controllare il server A ogni 30 secondi. Quando il server A risponde correttamente a una richiesta di un probe di integrità predefinito, il gateway applicazione avvia nuovamente l'inoltro delle richieste al server.

Impostazioni predefinite del probe di integrità

Proprietà probe	Valore	Descrizione
URL probe	<protocol>://127.0.0.1:<porta>/	Il protocollo e la porta vengono ereditati dalle impostazioni HTTP del back-end a cui è associato il probe
Intervallo	30	Il tempo di attesa in secondi prima di inviare il probe di integrità successivo.
Timeout	30	Il tempo in secondi che un gateway applicazione trascorre in attesa di una risposta del probe prima di contrassegnare il probe come non integro. Se un probe viene restituito come integro, il back-end corrispondente viene subito contrassegnato anch'esso come tale.
Soglia non integra	3	Determina quanti probe inviare in caso di errore del probe di integrità normale. Nello SKU v1 questi probe di integrità aggiuntivi vengono inviati in rapida successione per determinare rapidamente l'integrità del back-end e non attendono l'intervallo di probe. Per SKU versione 2, i probe di integrità attendono l'intervallo. Il server back-end viene contrassegnato come inattivo dopo che il numero di errori di probe consecutivi ha raggiunto una soglia non integra.

Il probe predefinito esamina solo <protocollo>://127.0.0.1:<porta> per determinare lo stato di integrità. Se si deve configurare il probe di integrità per passare a un URL personalizzato o modificare altre impostazioni, è necessario usare probe personalizzati.

Probe di integrità personalizzato

I probe personalizzati consentono un controllo più granulare sul monitoraggio dell'integrità. Quando si usano probe personalizzati, è possibile configurare un nome host personalizzato, un percorso URL, un intervallo di probe e il numero di risposte non riuscite da accettare prima di contrassegnare l'istanza del pool back-end come non integra e così via.

Impostazioni del probe di integrità personalizzato

La tabella seguente fornisce le definizioni delle proprietà di un probe di integrità personalizzato.

Proprietà probe	Descrizione
Name	Nome del probe. Questo nome viene usato per identificare e fare riferimento al probe nelle impostazioni HTTP back-end.
Protocollo	Protocollo usato per inviare il probe. Deve corrispondere al protocollo definito nelle impostazioni HTTP back-end a cui è associato
Host	Nome host con cui inviare il probe. Nello SKU v1 questo valore viene usato solo per l'intestazione host della richiesta del probe. Nello SKU v2 viene usato sia come intestazione host che come SNI
Percorso	Percorso relativo del probe. Un percorso valido inizia con "/".
Porta	Se definita, viene usata come porta di destinazione. In caso contrario, usa la stessa porta delle impostazioni HTTP a cui è associata. Questa proprietà è disponibile solo nello SKU v2
Intervallo	Intervallo di probe in secondi. Il valore corrisponde all'intervallo di tempo tra due probe consecutivi
Timeout	Timeout del probe in secondi. Se non viene ricevuta una risposta valida entro questo periodo di timeout, il probe viene contrassegnato come non riuscito
Soglia non integra	Numero di tentativi di probe. Il server back-end viene contrassegnato come inattivo dopo che il numero di errori di probe consecutivi ha raggiunto una soglia non integra

Criteri di corrispondenza dei probe

Per impostazione predefinita, una risposta HTTP(S) con codice di stato compreso tra 200 e 399 viene considerata integra. I probe di integrità personalizzati supportano anche due criteri di corrispondenza. Questi criteri possono essere usati per modificare l'interpretazione predefinita di ciò che costituisce una risposta integra.

I criteri di corrispondenza sono i seguenti:

• Corrispondenza del codice di stato della risposta HTTP: il criterio adottato da un probe per accettare il codice di risposta o l'intervallo di codici di risposta HTTP specificato dall'utente. Sono supportati singoli codici di stato della risposta, delimitati da virgole, o un intervallo di codici di stato.
  
• Corrispondenza del corpo della risposta HTTP: il criterio adottato dal probe in base al quale viene esaminato il corpo della risposta HTTP e viene stabilita una corrispondenza con una stringa specificata dall'utente. La corrispondenza verifica solo la presenza della stringa specificata dall'utente nel corpo della risposta e non è una corrispondenza completa basata su espressione regolare. La corrispondenza specificata deve essere di almeno 4090 caratteri.

I criteri di corrispondenza possono essere specificati tramite il cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.

Ad esempio:

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399

$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

I criteri di corrispondenza possono essere associati alla configurazione del probe usando un operatore -Match in PowerShell.

Casi d'uso di probe personalizzati

• Se un server back-end consente l'accesso solo agli utenti autenticati, i probe del gateway applicazione riceveranno un codice di risposta 403 anziché 200. Poiché i client (utenti) sono associati per autenticarsi per il traffico live, è possibile configurare il traffico probe per accettare 403 come risposta prevista.
• Quando un server back-end dispone di un certificato con caratteri jolly (*.contoso.com) installato per gestire domini secondari diversi, è possibile usare un probe personalizzato con un nome host specifico (obbligatorio per SNI) accettato per stabilire un probe TLS riuscito e segnalare tale server come integro. Con l'opzione per l'override del nome host nell'impostazione back-end impostata su NO, i diversi nomi host in ingresso (sottodomini) verranno passati al back-end così come sono.

Considerazioni sui gruppi di sicurezza di rete (NSG)

Nella versione di anteprima pubblica è disponibile il controllo granulare della subnet del gateway applicazione tramite regole del gruppo di sicurezza di rete. Per informazioni dettagliate, vedere questo articolo.

Con la funzionalità corrente esistono alcune restrizioni:

È necessario consentire il traffico Internet in ingresso sulle porte TCP 65503-65534 per lo SKU del gateway applicazione v1 e sulle porte TCP 65200-65535 per lo SKU v2 con la subnet di destinazione impostata su Qualsiasi e l'origine impostata sul tag di servizio GatewayManager. Questo intervallo di porte è necessario per la comunicazione di infrastruttura di Azure.

Non è possibile neanche bloccare la connettività Internet in uscita ed è necessario autorizzare il traffico in ingresso proveniente dal tag AzureLoadBalancer.

Funzionamento del gateway applicazione

Come un gateway applicazione accetta una richiesta

1. Prima di inviare una richiesta a un gateway applicazione, un client risolve il nome di dominio del gateway applicazione usando un server DNS (Domain Name System). Azure controlla la voce DNS perché tutti i gateway applicazione si trovano nel dominio azure.com.
2. Il servizio DNS di Azure restituisce al client l'indirizzo IP, che è l'indirizzo IP front-end del gateway applicazione.
   
3. Il gateway applicazione accetta il traffico in ingresso su uno o più listener. Un listener è un'entità logica che verifica la presenza di richieste di connessione. È configurato con un indirizzo IP front-end, un protocollo e un numero di porta per le connessioni dai client al gateway applicazione.
   
4. Se è in uso un web application firewall (WAF), il gateway applicazione controlla le intestazioni della richiesta e il corpo, se presente, in base alle regole WAF. Questa azione determina se la richiesta è valida o rappresenta una minaccia per la sicurezza. Se la richiesta è valida, viene instradata al back-end. Se la richiesta non è valida e WAF è in modalità di prevenzione, viene bloccata come minaccia per la sicurezza. Se WAF è in modalità di rilevamento, la richiesta viene valutata e registrata, ma comunque inoltrata al server back-end.
   

Il gateway applicazione di Azure può essere usato come servizio di bilanciamento del carico delle applicazioni interne o come servizio di bilanciamento del carico delle applicazioni con connessione Internet. Un gateway applicazione con connessione Internet usa IP pubblici. Il nome DNS di un gateway applicazione con connessione Internet è risolvibile pubblicamente nel relativo IP pubblico. Di conseguenza, i gateway applicazione con connessione Internet possono instradare le richieste dei client provenienti da Internet.

I gateway applicazione interni usano solo indirizzi IP privati. Se si usa una zona DNS personalizzata o privata, il nome di dominio deve essere risolvibile internamente nell'indirizzo IP privato del gateway applicazione. Di conseguenza, i servizi di bilanciamento del carico interni possono instradare solo le richieste provenienti da client con accesso a una rete virtuale per il gateway applicazione.

Come un gateway applicazione instrada una richiesta

Se una richiesta è valida e non viene bloccata da WAF, il gateway applicazione valuta la regola di routing delle richieste associata al listener. Questa azione determina il pool back-end a cui instradare la richiesta.

In base alla regola di routing delle richieste, il gateway applicazione determina se instradare tutte le richieste nel listener a un pool back-end specifico, instradare le richieste a pool back-end diversi in base al percorso dell'URL o reindirizzare le richieste a un'altra porta o a un sito esterno.

Quando il gateway applicazione seleziona il pool back-end, invia la richiesta a uno dei server back-end integri nel pool (y.y.y.y.y). L'integrità del server è determinata da un probe di integrità. Se il pool back-end contiene più server, il gateway applicazione usa un algoritmo round robin per instradare le richieste tra i server integri. Questo consente di bilanciare il carico delle richieste nei server.

Dopo aver determinato il server back-end, il gateway applicazione apre una nuova sessione TCP con il server back-end in base alle impostazioni HTTP. Le impostazioni HTTP specificano il protocollo, la porta e altre impostazioni correlate al routing necessarie per stabilire una nuova sessione con il server back-end.

La porta e il protocollo usati nelle impostazioni HTTP determinano se il traffico tra il gateway applicazione e i server back-end è crittografato, implementando quindi TLS end-to-end, o non crittografato.

Quando un gateway applicazione invia la richiesta originale al server back-end, rispetta le eventuali configurazioni personalizzate definite nelle impostazioni HTTP associate all'override del nome host, del percorso e del protocollo. Questa azione mantiene l'affinità di sessione basata su cookie, lo svuotamento della connessione, la selezione del nome host dal back-end e così via.

Se il pool back-end:

• È un endpoint pubblico, il gateway applicazione usa l'IP pubblico front-end per raggiungere il server. Se non esiste un IP pubblico front-end, ne viene assegnato uno per la connettività esterna in uscita.
• Contiene un indirizzo IP privato o un nome di dominio completo risolvibile internamente, il gateway applicazione instrada la richiesta al server back-end usando l'indirizzo IP privato dell'istanza.
• Contiene un endpoint esterno o un nome di dominio completo risolvibile esternamente, il gateway applicazione instrada la richiesta al server back-end usando l'indirizzo IP pubblico front-end. Se la subnet contiene endpoint di servizio, il gateway applicazione instrada la richiesta al servizio tramite l'indirizzo IP privato. La risoluzione DNS si basa su una zona DNS privata o su un server DNS personalizzato, se configurato, o usa il DNS predefinito fornito da Azure. Se non esiste un IP pubblico front-end, ne viene assegnato uno per la connettività esterna in uscita.

Risoluzione DNS dei server back-end

Quando il server di un pool back-end è configurato con un nome di dominio completo (FQDN), il gateway applicazione esegue una ricerca DNS per ottenere gli indirizzi IP del nome di dominio. Il valore IP viene archiviato nella cache del gateway applicazione, in modo che possa raggiungere le destinazioni più velocemente durante la gestione delle richieste in ingresso.

Il gateway applicazione mantiene queste informazioni memorizzate nella cache per il periodo equivalente al valore TTL (durata) del record DNS. Dopo la scadenza del TTL, esegue una nuova ricerca DNS. Se un gateway rileva una modifica dell'indirizzo IP per la query DNS successiva, inizierà a instradare il traffico a questa destinazione aggiornata. In caso di problemi, ad esempio se la ricerca DNS non riesce a ricevere una risposta o se il record non esiste più, il gateway continua a usare l'ultimo indirizzo IP valido noto. Questo assicura un impatto minimo sul percorso dati.

• Quando si usano server DNS personalizzati con la rete virtuale del gateway applicazione, è essenziale che tutti i server siano identici e rispondano in modo coerente con gli stessi valori DNS.
• Gli utenti di server DNS personalizzati locali devono garantire la connettività a DNS di Azure tramite il servizio Resolver privato DNS (scelta consigliata) o la macchina virtuale del server d'inoltro DNS quando viene usata una zona DNS privata per l'endpoint privato.

Modifiche alla richiesta

Il gateway applicazione aggiunge altre sei intestazioni a tutte le richieste prima di inoltrarle al back-end. Queste intestazioni sono x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url e x-appgw-trace-id. Il formato per l'intestazione x-forwarded-for è un elenco delimitato da virgole di valori IP:porta.

I valori validi per x-forwarded-proto sono HTTP e HTTPS. X-forwarded-port specifica la porta in cui la richiesta ha raggiunto il gateway applicazione. L'intestazione X-original-host contiene l'intestazione host originale con cui la richiesta è arrivata. Questa intestazione è utile per l'integrazione di un sito Web di Azure, in cui l'intestazione host in ingresso viene modificata prima che il traffico venga indirizzato al back-end. Se è abilitata l'opzione di affinità di sessione, aggiunge un cookie di affinità gestito dal gateway.

X-appgw-trace-id è un GUID univoco generato dal gateway applicazione per ogni richiesta client e presentato nella richiesta inoltrata al membro del pool back-end. Il GUID è costituito da 32 caratteri alfanumerici senza trattini, ad esempio: ac882cd65a2712a0fe1289ec2bb6aee7. Può essere usato per correlare una richiesta ricevuta dal gateway applicazione e avviata a un membro del pool back-end tramite la proprietà transactionId nei log di diagnostica.

È possibile configurare il gateway applicazione in modo da modificare le intestazioni di richiesta e risposta e l'URL usando le funzionalità di riscrittura di URL e intestazioni HTTP oppure in modo da modificare il percorso dell'URI usando un'impostazione di override del percorso. Tuttavia, a meno che non sia configurato a questo scopo, tutte le richieste in ingresso vengono inviate tramite proxy al back-end.