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.
Il 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, e le confronta con le 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à 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 dell'applicazione interno o come servizio di bilanciamento del carico delle applicazioni 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 DNS privato o personalizzata, il nome di dominio deve essere risolvibile internamente all'indirizzo IP privato del gateway applicazione. Pertanto, i servizi di bilanciamento del carico interni possono instradare 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 gestione delle richieste associata al listener. Questa azione determina il pool back-end a cui indirizzare la richiesta.
In base alla regola di gestione 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 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 servizio bilancia il carico delle richieste nei server.
Dopo che il gateway applicazione determina il server back-end, viene aperta 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 così 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 gli indirizzi IP privati dell'istanza.
- Contiene un endpoint esterno o un FQDN risolvibile esternamente, il gateway applicazione instrada 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 si basa su una zona DNS privato o su un server DNS personalizzato, se configurata 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.
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 per consentirlo di 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 TTL (time to live) del record DNS ed esegue una nuova ricerca DNS dopo la scadenza del TTL. 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 come la ricerca DNS non riesce a ricevere una risposta o il record non esiste più, il gateway continua a usare l'ultimo indirizzo IP valido noto. In questo modo si garantisce un impatto minimo sul percorso dei dati.
Importante
- Quando si usano server DNS personalizzati con Rete virtuale di gateway applicazione, è importante che tutti i server rispondano in modo coerente con gli stessi valori DNS. Quando un'istanza del gateway applicazione genera una query DNS, usa prima il valore del server che risponde.
- Gli utenti di server DNS personalizzati locali devono garantire la connettività a DNS di Azure tramite il resolver privato DNS di Azure (scelta consigliata) o una macchina virtuale del server d'inoltro DNS quando si usa una zona DNS privato per l'endpoint privato.
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 dell'intestazione x-forwarded-for è un elenco di IP:port separato da virgole.
I valori validi per x-forwarded-proto sono HTTP or HTTPS. X-forwarded-port specifica la porta in cui la richiesta raggiunge il gateway applicazione. X-original-host header contiene l'intestazione host originale con cui è arrivata la richiesta. Questa intestazione è utile nell'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 l'affinità di sessione è abilitata come opzione, 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). 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 Riscrivi intestazioni HTTP e URL, 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.