Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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.
Flusso del processo:
- 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.
- 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.
- La risposta del server back-end viene inviata al client dal gateway applicazione.
- 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).