Come funziona un gateway applicativo

• 11/16/2019
• 4 minuti per leggere
• • a
  • j
  • D
  • s
  • v
  • +2

Questo articolo spiega come un gateway applicativo accetta le richieste in entrata e le instrada al backend.

Come un gateway applicativo accetta una richiesta

1. Prima che un client invii una richiesta a un gateway applicativo, risolve il nome di dominio del gateway applicativo utilizzando un server Domain Name System (DNS). Azure controlla la voce DNS perché tutti i gateway applicativi si trovano nel dominio azure.com.

2. Il DNS di Azure restituisce l’indirizzo IP al client, che è l’indirizzo IP frontend del gateway applicativo.

3. Il gateway applicativo accetta il traffico in entrata su uno o più ascoltatori. Un ascoltatore è un’entità logica che controlla le 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 applicativo 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 alla sicurezza. Se la richiesta è valida, viene instradata al backend. Se la richiesta non è valida e il WAF è in modalità Prevention, viene bloccata come minaccia alla sicurezza. Se è in modalità di rilevamento, la richiesta viene valutata e registrata, ma ancora inoltrata al server di backend.

Azure Application Gateway può essere utilizzato come un bilanciatore di carico delle applicazioni interno o come un bilanciatore di carico delle applicazioni rivolto a Internet. Un gateway applicativo rivolto a Internet utilizza indirizzi IP pubblici. Il nome DNS di un gateway applicativo rivolto a Internet è risolvibile pubblicamente al suo indirizzo IP pubblico. Di conseguenza, i gateway applicativi Internet-facing possono instradare le richieste dei client da Internet.

I gateway applicativi interni utilizzano solo indirizzi IP privati. Se si utilizza una zona DNS personalizzata o privata, il nome del dominio dovrebbe essere risolvibile internamente all’indirizzo IP privato del gateway applicativo. Pertanto, i load-balancer interni possono instradare solo le richieste dei client con accesso a una rete virtuale per il gateway applicativo.

Come un gateway applicativo instrada una richiesta

Se una richiesta è valida e non bloccata dal WAF, il gateway applicativo valuta la regola di instradamento della richiesta che è associata all’ascoltatore. Questa azione determina a quale pool di backend instradare la richiesta.

In base alla regola di instradamento della richiesta, il gateway applicativo determina se instradare tutte le richieste sull’ascoltatore a uno specifico pool di backend, instradare le richieste a diversi pool di backend in base al percorso dell’URL o reindirizzare le richieste a un’altra porta o sito esterno.

Quando il gateway applicativo seleziona il pool di backend, invia la richiesta a uno dei server backend sani nel pool (y.y.y.y). La salute del server è determinata da una sonda di salute. Se il pool di backend contiene più server, l’application gateway usa un algoritmo round-robin per instradare le richieste tra i server sani. Questo bilancia le richieste sui server.

Dopo che il gateway applicativo determina il server backend, apre una nuova sessione TCP con il server backend in base alle impostazioni HTTP. Le impostazioni HTTP specificano il protocollo, la porta e altre impostazioni relative al routing che sono necessarie per stabilire una nuova sessione con il server di backend.

La porta e il protocollo utilizzati nelle impostazioni HTTP determinano se il traffico tra il gateway applicativo e i server di backend è criptato (realizzando così TLS end-to-end) o non è criptato.

Quando un gateway applicativo invia la richiesta originale al server di backend, onora qualsiasi configurazione personalizzata fatta nelle impostazioni HTTP relativa alla sovrascrittura di nome host, percorso e protocollo. Questa azione mantiene l’affinità di sessione basata sui cookie, il drenaggio della connessione, la selezione del nome dell’host dal backend e così via.

Modifiche alla richiesta

Un application gateway inserisce quattro intestazioni aggiuntive a tutte le richieste prima di inoltrare le richieste al backend. Queste intestazioni sono x-forwarded-for, x-forwarded-proto, x-forwarded-port e x-original-host. Il formato dell’intestazione x-forwarded-for è una lista separata da virgole di IP:port.

I valori validi per x-forwarded-proto sono HTTP o HTTPS. X-forwarded-port specifica la porta dove la richiesta ha raggiunto l’application gateway. L’intestazione X-original-host contiene l’intestazione originale dell’host con cui la richiesta è arrivata. Questa intestazione è utile nell’integrazione del sito web di Azure, dove l’intestazione dell’host in entrata viene modificata prima che il traffico venga instradato al backend. Se l’affinità di sessione è abilitata come opzione, allora aggiunge un cookie di affinità gestito dal gateway.

È possibile configurare application gateway per modificare le intestazioni di richiesta e risposta e l’URL utilizzando Rewrite HTTP headers and URL o per modificare il percorso URI utilizzando un’impostazione path-override. Tuttavia, a meno che non sia configurato in tal senso, tutte le richieste in entrata vengono reindirizzate al backend.

Impara i componenti del gateway applicativo