Condividi tramite


Panoramica del proxy TCP/TLS dell'Application Gateway

Oltre alle funzionalità di livello 7 esistenti (HTTP, HTTPS, WebSockets e HTTP/2), il gateway applicazione di Azure supporta ora anche il proxy di livello 4 (protocollo TCP) e TLS (Transport Layer Security).

Funzionalità proxy TLS/TCP nel gateway applicazione

Come servizio di proxy inverso, le operazioni di livello 4 del gateway applicazione funzionano in modo simile alle operazioni proxy del livello 7. Un client stabilisce una connessione TCP con il gateway applicazione e il gateway applicazione stesso avvia una nuova connessione TCP a un server back-end dal pool back-end. La figura seguente mostra il funzionamento tipico.

Diagramma di panoramica del funzionamento del proxy TCP/TLS.

Flusso del processo:

  1. Un client avvia una connessione TCP o TLS con il gateway applicazione usando l'indirizzo IP e il numero di porta del listener front-end. In questo modo viene stabilita la connessione front-end. Una volta stabilita la connessione, il client invia una richiesta usando il protocollo di livello applicazione richiesto.
  2. Il gateway applicazione stabilisce una nuova connessione con una delle destinazioni di back-end dal pool back-end associato (formando la connessione di back-end) e invia la richiesta del client a tale server back-end.
  3. La risposta del server back-end viene inviata al client dal gateway applicazione.
  4. La stessa connessione TCP del front-end viene usata per le richieste successive del client, a meno che il timeout di inattività TCP non chiuda tale connessione.

Confronto tra Azure Load Balancer e il gateway applicazione di Azure:

Prodotto TIPO
Azure Load Balancer Un servizio di bilanciamento del carico pass-through in cui un client stabilisce direttamente una connessione con un server back-end selezionato dall'algoritmo di distribuzione di Load Balancer.
Gateway applicazione Azure Arresto del servizio di bilanciamento del carico in cui un client stabilisce direttamente una connessione con il gateway applicazione e viene avviata una connessione separata con un server back-end selezionato dall'algoritmo di distribuzione del gateway applicazione.

Gateway di applicazione di Azure (proxy TLS/TCP)

  • Tipo – proxy di terzo livello terminante.
  • Protocolli : supporta protocolli TCP o TLS.
  • Versatilità : usare un singolo endpoint (IP front-end) per gestire carichi di lavoro HTTP e non HTTP.
  • Ridimensionamento : configurare la scalabilità automatica (fino a 125 istanze) per gestire il traffico TCP e TLS.
  • Sicurezza tramite terminazione TLS : semplificare la sicurezza con la terminazione e la gestione dei certificati TLS centralizzati garantendo la conformità coerente in tutte le applicazioni, inclusi i carichi di lavoro non HTTP. Si integra perfettamente con Azure Key Vault per la gestione sicura dei certificati.
  • Tipi di back-end: collegare in modo flessibile le applicazioni ai back-end ovunque; all'interno della stessa rete virtuale, tra reti virtuali con peering, tramite FQDN o IP remoti, o anche tramite connettività ibrida ai server locale.

Bilanciatore di carico Azure

  • Tipo: dispositivo di rete pass-through di livello 4.
  • Protocolli : supporta protocolli TCP o UDP.
  • Prestazioni : offre bassa latenza e velocità effettiva elevata. Creato per milioni di connessioni simultanee con latenza a livello di microsecondo.
  • Ridimensionamento : gestisce le connessioni di lunga durata e aumenta fino a milioni di flussi per tutte le applicazioni TCP e UDP.
  • In ingresso e in uscita : Azure Load Balancer offre un controllo del traffico completo con funzionalità in ingresso e in uscita. Connettere facilmente client esterni alle applicazioni, consentendo alle istanze back-end di raggiungere in modo sicuro Internet e altri servizi.
  • Restituzione del server diretto : per il traffico restituito, l'istanza back-end invia il pacchetto di risposta direttamente all'indirizzo IP del client, riducendo la latenza e migliorando le prestazioni.

Funzionalità

  • Usare un singolo endpoint (IP front-end) per gestire carichi di lavoro HTTP e non HTTP. La stessa distribuzione di gateway applicazione può supportare protocolli di livello 7 e di livello 4: HTTP(S), TCP o TLS. Tutti i clienti possono connettersi allo stesso endpoint e accedere ad applicazioni back-end diverse.
  • Usare un dominio personalizzato per gestire qualsiasi servizio back-end. Con il front-end per lo SKU V2 del gateway applicazione come indirizzi IP pubblici e privati, è possibile configurare qualsiasi nome di dominio personalizzato in modo che punti al relativo indirizzo IP usando un record di indirizzo (A). Inoltre, con la terminazione TLS e il supporto per i certificati di un'autorità di certificazione (CA) privata, è possibile garantire una connessione sicura nel dominio preferito.
  • Usare un server back-end da qualsiasi posizione (Azure o locale). I back-end per il gateway applicazione possono essere:
    • Risorse di Azure come macchine virtuali IaaS, set di scalabilità di macchine virtuali o PaaS (Servizi app, Hub eventi, SQL)
    • Risorse remote, ad esempio server locali accessibili tramite FQDN o indirizzi IP
  • Supportato per un gateway solo privato. Con il supporto del proxy TLS e TCP per le distribuzioni del gateway applicazione privato, è possibile supportare client HTTP e non HTTP in un ambiente isolato per una maggiore sicurezza.

Limitazioni

  • Un gateway SKU WAF v2 consente la creazione di listener TLS o TCP e back-end per supportare il traffico HTTP e non HTTP attraverso la stessa risorsa. Tuttavia, non controlla il traffico nei listener TLS e TCP per individuare exploit e vulnerabilità.
  • Il valore predefinito del timeout di svuotamento per i server back-end è di 30 secondi. Attualmente non è supportato un valore di svuotamento definito dall'utente.
  • Un aggiornamento della configurazione (PUT) su Gateway applicazione termina le connessioni attive dopo il periodo di timeout di drenaggio predefinito.
  • Il Controller in ingresso del gateway applicazione (AGIC) non è supportato e funziona solo con il proxy L7 tramite listener HTTP(S).

Passaggi successivi