Funzionamento del gateway applicazione
Questo articolo illustra come un gateway applicazione accetta le richieste in ingresso e le instrada al back-end.
Modalità di accettazione di una richiesta da parte di un gateway applicazione
Prima che un client invii una richiesta a un gateway applicazione, 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.
Dns di Azure restituisce l'indirizzo IP al client, ovvero l'indirizzo IP front-end del gateway applicazione.
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. Viene configurato con un indirizzo IP front-end, un protocollo e un numero di porta per le connessioni dai client al gateway applicazione.
Se è in uso un web application firewall (WAF), il gateway applicazione controlla le intestazioni della richiesta e il corpo, se presente, rispetto alle regole WAF. Questa azione determina se la richiesta è una richiesta valida o una minaccia per la sicurezza. Se la richiesta è valida, viene instradata al back-end. Se la richiesta non è valida e WAF è in modalità prevenzione, viene bloccata come minaccia per la sicurezza. Se è in modalità di rilevamento, la richiesta viene valutata e registrata, ma comunque inoltrata al server back-end.
gateway applicazione di Azure può essere usato come servizio di bilanciamento del carico interno dell'applicazione o come servizio di bilanciamento del carico dell'applicazione con connessione Internet. Un gateway applicazione con connessione Internet usa indirizzi IP pubblici. Il nome DNS di un gateway applicazione con connessione Internet è risolvibile pubblicamente nel relativo indirizzo IP pubblico. Di conseguenza, i gateway applicazione con connessione Internet possono instradare le richieste client da Internet.
I gateway applicazione interni usano solo indirizzi IP privati. Se si usa una zona Personalizzata o DNS privato, il nome di dominio deve essere risolvibile internamente all'indirizzo IP privato del gateway applicazione. Di conseguenza, i servizi di bilanciamento del carico interni possono indirizzare solo le richieste dai client con accesso a una rete virtuale per il gateway applicazione.
Come un gateway applicazione instrada una richiesta
Se una richiesta è valida e non bloccata da WAF, il gateway applicazione valuta la regola di routing della richiesta 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 URL o reindirizzare le richieste a un'altra porta o sito esterno.
Nota
Le regole vengono elaborate nell'ordine in cui sono elencate nel portale per lo SKU v1.
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 server integri. Questo bilanciamento del carico delle richieste nei server.
Dopo che il gateway applicazione determina il server back-end, 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 (ottenendo quindi TLS end-to-end) o non crittografato.
Quando un gateway applicazione invia la richiesta originale al server back-end, rispetta qualsiasi configurazione personalizzata eseguita nelle impostazioni HTTP correlate all'override del nome host, del percorso e del protocollo. Questa azione mantiene l'affinità di sessione basata su cookie, lo svuotamento delle connessioni, la selezione del nome host dal back-end e così via.
Nota
Se il pool back-end:
- Endpoint pubblico, il gateway applicazione usa l'indirizzo IP pubblico front-end per raggiungere il server. Se non è presente un indirizzo IP pubblico front-end, ne viene assegnato uno per la connettività esterna in uscita.
- Contiene un FQDN risolvibile internamente o un indirizzo IP privato, il gateway applicazione instrada la richiesta al server back-end usando i relativi indirizzi IP privati dell'istanza.
- Contiene un endpoint esterno o un FQDN risolvibile esternamente, il gateway applicazione indirizza la richiesta al server back-end usando il relativo indirizzo IP pubblico front-end. Se la subnet contiene endpoint di servizio, il gateway applicazione instrada la richiesta al servizio tramite il relativo indirizzo IP privato. La risoluzione DNS è basata su una zona DNS privata o su un server DNS personalizzato, se configurato o usa il DNS predefinito fornito da Azure. Se non è presente un indirizzo IP pubblico front-end, ne viene assegnato uno per la connettività esterna in uscita.
Modifiche alla richiesta
Il gateway applicazione inserisce sei intestazioni aggiuntive a tutte le richieste prima di inoltrare le richieste 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 IP:port.
I valori validi per x-forwarded-proto sono HTTP o 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 è arrivata la richiesta. Questa intestazione è utile nell'integrazione del sito Web di Azure, in cui l'intestazione host in ingresso viene modificata prima che il traffico venga instradato al back-end. Se l'affinità di sessione è abilitata come opzione, aggiunge un cookie di affinità gestita 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 presentati senza trattini (ad esempio: ac882cd65a2712a0fe1289ec2bb6aee7). Questo GUID può essere usato per correlare una richiesta ricevuta dal gateway applicazione e avviata a un membro del pool back-end tramite la proprietà transactionId in Log di diagnostica.
È possibile configurare il gateway applicazione per modificare le intestazioni di richiesta e risposta e l'URL usando le intestazioni HTTP e l'URL di riscrittura o per modificare il percorso URI usando un'impostazione di override del percorso. Tuttavia, a meno che non sia configurato per farlo, tutte le richieste in ingresso vengono inviate tramite proxy al back-end.