Come funziona un gateway applicativo

Questo articolo illustra come un gateway applicazione accetta le richieste in ingresso e le instrada al back-end.

Come un gateway applicativo accetta una richiesta

Come un gateway applicativo accetta una richiesta

  1. 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 gestisce il record DNS perché tutti i gateway applicazione si trovano nel dominio azure.com.

  2. Il DNS di Azure restituisce l'indirizzo IP al client, ovvero 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 frontend, un protocollo e un numero di porta per le connessioni dai client al gateway applicativo.

  4. Se è in uso un Web Application Firewall (WAF), il gateway applicazione verifica 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à 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 applicativo esposto a Internet usa indirizzi IP pubblici. Il nome DNS di un gateway applicazione esposto a Internet è risolvibile pubblicamente nel relativo indirizzo IP pubblico. Di conseguenza, i gateway applicativi esposti a Internet possono instradare le richieste dei client provenienti da Internet.

I gateway applicativi interni usano solo indirizzi IP privati. Se si utilizza una zona DNS personalizzata o zona DNS privata, il nome di dominio deve essere risolto internamente nell'indirizzo IP privato dell'Application Gateway. Pertanto, i bilanciatori del carico interni possono instradare solo le richieste provenienti da client con accesso a una rete virtuale per il gateway applicativo.

Come un gateway applicazione instrada una richiesta

Se una richiesta è valida e non è bloccata da WAF, il gateway applicativo valuta la regola di instradamento 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 di back-end, inoltra la richiesta a uno dei server back-end disponibili nel pool (y.y.y.y). Lo stato del server è determinato da una probe di stato. Se il pool di back-end contiene più server, il gateway applicazione usa un algoritmo round-robin per instradare le richieste verso i server disponibili. Questo servizio bilancia il carico delle richieste nei server.

Dopo che il gateway applicativo individua 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 così TLS end-to-end) o non crittografato.

Quando un gateway applicazione invia la richiesta originale al server back-end, applica qualsiasi configurazione personalizzata definita nelle impostazioni HTTP relativa alla sostituzione 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

Il gateway delle applicazioni non inoltra la richiesta al WAF quando non sono disponibili membri del pool di back-end.

Nota

Se il pool di back-end:

  • È un endpoint pubblico, il gateway applicazione usa l'indirizzo IP pubblico del 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 applicativo instrada la richiesta verso il server back-end utilizzando gli indirizzi IP privati dell'istanza.
  • Contiene un endpoint esterno o un FQDN risolvibile esternamente, il gateway applicazione instrada la richiesta al server di back-end usando il proprio indirizzo IP pubblico front-end. Se la subnet contiene endpoint di servizio, il gateway applicazione instraderà la richiesta al servizio tramite il proprio 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 backend

Quando il server di un pool back-end è configurato con un nome di dominio completo (FQDN), Application Gateway esegue una query DNS per ottenere l'indirizzo IP o 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 utilizzano server DNS personalizzati con la rete virtuale dell'Application Gateway, è importante che tutti i server rispondano in modo coerente con gli stessi valori DNS. Quando un'istanza di Application Gateway invia una query DNS, usa il valore restituito dal server che risponde per primo.
  • Gli utenti di server DNS personalizzati on-premises devono garantire la connettività ad DNS di Azure tramite DNS di Azure Private Resolver (scelta consigliata) o una VM d’inoltro DNS quando si usa una zona DNS privata per un endpoint privato.

Modifiche alla richiesta

Il gateway applicativo inserisce sei header aggiuntivi in 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. Se il tuo handshake TLS utilizza una policy SSL predefinita da AppGwSslPolicy20220101 o successiva, oppure una policy SSL personalizzata di tipo CustomV2 o successivo, la tua richiesta avrà un'intestazione aggiuntiva: x-azure-ja4-fingerprint. Il formato dell'intestazione x-forwarded-for è una lista separata da virgole di IP:port.

I valori validi per x-forwarded-proto sono HTTP or HTTPS. X-forwarded-port specifica la porta su cui la richiesta ha raggiunto il gateway applicativo. 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-Azure-JA4-Fingerprint è un'impronta TLS del client che aiuta a identificare e correlare il traffico dei client tra i servizi per le indagini di sicurezza.

X-appgw-trace-id è un GUID univoco generato da gateway applicazione per ogni richiesta del client e incluso 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 da gateway applicazione e inoltrata a un membro del pool back-end tramite la proprietà transactionId in log di diagnostica.

È possibile configurare il gateway applicativo per modificare le intestazioni delle richieste e delle risposte e l'URL tramite Riscrivi intestazioni HTTP e URL oppure per modificare il percorso URI tramite un'impostazione di sostituzione del percorso. Tuttavia, a meno che non sia configurato per farlo, tutte le richieste in ingresso vengono inviate tramite proxy al back-end.

Passaggi successivi

  • Last updated on