Funzionamento del gateway applicazione
Questo articolo illustra come un gateway applicazione accetta le richieste in ingresso e le instrada al back-end.
Come un gateway applicazione accetta una richiesta
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.
Il servizio DNS di Azure restituisce al client l'indirizzo IP, che è 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. È 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, 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 Personalizzata o DNS privato, il nome di dominio deve essere internamente risolvibile all'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.
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 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.
Nota
Se il pool back-end:
- Endpoint pubblico, il gateway applicazione usa l'indirizzo 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 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 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.
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 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. 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 a questo scopo, tutte le richieste in ingresso vengono inviate tramite proxy al back-end.