Domande frequenti sul gateway applicazione di Azure

Il gateway applicazione di Azure offre un controller per la distribuzione di applicazioni come servizio. Offre varie funzionalità di bilanciamento del carico di livello 7 per le applicazioni. Questo servizio è altamente disponibile, scalabile e completamente gestito da Azure.

Il gateway applicazione supporta scalabilità automatica, offload TLS e TLS end-to-end, Web application firewall, affinità della sessione basata su cookie, routing basato su percorso URL, hosting multisito e altre funzionalità. Per un elenco completo delle funzionalità supportate, vedere Cos'è il gateway applicazione di Azure?

Il gateway applicazione è un servizio di bilanciamento del carico di livello 7 e funziona quindi solo con il traffico Web (HTTP, HTTPS, WebSocket e HTTP/2). Supporta funzionalità come terminazione TLS, affinità di sessione basata su cookie e round robin per il bilanciamento del carico del traffico. Load Balancer esegue il bilanciamento del carico del traffico al livello 4 (TCP o UDP).

Il gateway applicazione supporta HTTP, HTTPS, HTTP/2 e WebSocket.

Vedere Supporto HTTP/2.

Vedere Risorse back-end supportate.

Il gateway applicazione v1 (Standard e WAF) è disponibile in tutte le aree di Azure globale. È disponibile anche in Microsoft Azure gestito da 21Vianet e Azure per enti pubblici.

Per la disponibilità del gateway applicazione v2 (Standard_v2 e WAF_v2), vedere la sezione relativa alle aree supportate per il gateway applicazione v2.

Il gateway applicazione è una distribuzione dedicata nella rete virtuale.

Il reindirizzamento è supportato. Vedere Panoramica del reindirizzamento nel gateway applicazione.

Vedere l'ordine di elaborazione del listener.

Se si usa un indirizzo IP pubblico come endpoint, le informazioni sull'indirizzo IP e sul DNS sono disponibili nella risorsa indirizzo IP pubblico. In alternativa, è possibile trovarle nel portale di Azure, nella pagina di panoramica per il gateway applicazione. Se si usano indirizzi IP interni, le informazioni sono disponibili nella pagina di panoramica. Per lo SKU v1, i gateway creati dopo il 1° maggio 2023 non avranno automaticamente un nome DNS predefinito associato alla risorsa IP pubblica. Per lo SKU v2, aprire la risorsa IP pubblico e selezionare Configurazione. Il campo Etichetta del nome DNS (facoltativa) è disponibile per configurare il nome DNS.

Il timeout Keep-Alive controlla per quanto tempo il gateway applicazione deve attendere che un client invii un'altra richiesta HTTP su una connessione permanente prima di riutilizzarla o chiuderla. Il timeout di inattività TCP controlla per quanto tempo una connessione TCP viene mantenuta aperta in caso di assenza di attività.

Per le connessioni HTTP/1.1, il Keep-Alive timeout nello SKU gateway applicazione v1 e v2 è di 120 secondi. Per gli indirizzi IP privati, il valore non è configurabile con un timeout di inattività TCP di 5 minuti. Il timeout di inattività TCP è un valore predefinito di 4 minuti nell'indirizzo IP virtuale front-end (VIP) dello SKU v1 e v2 del gateway applicazione. È possibile configurare il valore di timeout di inattività TCP nelle istanze del gateway applicazione v1 e v2 in un punto qualsiasi tra 4 minuti e 30 minuti. Per le istanze del gateway applicazione v1 e v2, è necessario passare all'indirizzo IP pubblico del gateway applicazione e modificare il timeout di inattività TCP nel riquadro Configurazione dell'indirizzo IP pubblico nel portale. È possibile impostare il valore del timeout di inattività TCP dell'indirizzo IP pubblico tramite PowerShell eseguendo i comandi seguenti:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Per le connessioni HTTP/2 all'indirizzo IP front-end nello SKU v2 del gateway applicazione, il timeout di inattività è impostato su 180 secondi e non è configurabile.

Per evitare conflitti e comportamenti imprevisti, assicurarsi che il timeout di inattività TCP sia impostato come o più lungo del timeout keep-alive.

Sì. Il gateway applicazione riutilizza le connessioni TCP esistenti con un server back-end.

No. Non è possibile rinominare una risorsa del gateway applicazione. È necessario creare una nuova risorsa con un nome diverso.

No. Non è possibile ripristinare una risorsa del gateway applicazione o il relativo indirizzo IP pubblico dopo l'eliminazione. È necessario creare una nuova risorsa.

Nello SKU v1 del gateway applicazione l'indirizzo VIP può cambiare se si arresta e si avvia il gateway applicazione. Tuttavia, il nome DNS associato al gateway applicazione non cambia durante il ciclo di vita del gateway. Poiché il nome DNS non cambia, è consigliabile usare un alias CNAME che punti all'indirizzo DNS del gateway applicazione. Nello SKU v2 del gateway applicazione gli indirizzi IP sono statici, quindi l'indirizzo IP e il nome DNS non cambieranno per tutta la durata del gateway applicazione.

Sì. Lo SKU v2 del gateway applicazione supporta indirizzi IP pubblici statici e indirizzi IP interni statici. Lo SKU versione 1 supporta indirizzi IP interni statici.

Un gateway applicazione supporta un solo indirizzo IP pubblico per protocollo IP. Se il gateway applicazione è configurato come DualStack, può supportare due indirizzi IP pubblici, uno per IPv4 e uno per IPv6.

Vedere Considerazioni sulle dimensioni della subnet del gateway applicazione.

Sì. Oltre ad avere più istanze di una determinata distribuzione del gateway applicazione, è possibile effettuare il provisioning di un'altra risorsa gateway applicazione univoca a una subnet esistente che contiene un'altra risorsa gateway applicazione.

Una singola subnet non può supportare entrambi gli SKU v2 e v1 del gateway applicazione.

Sì, ma solo scenari specifici. Per altre informazioni, vedere la configurazione dell'infrastruttura del gateway applicazione.

Sì. Vedere Modifiche a una richiesta.

Nuove distribuzioni di SKU versione 1 del gateway applicazione possono richiedere fino a 20 minuti per effettuare il provisioning. Le modifiche all'istanza di conteggio o dimensioni non causano problemi e il gateway rimane attivo durante questo periodo di tempo.

Per la maggior parte delle distribuzioni che usano lo SKU v2 sono necessari circa 6 minuti per il provisioning. Tuttavia, il processo può richiedere più tempo a seconda del tipo di distribuzione. Ad esempio, le distribuzioni in più zone di disponibilità con molte istanze possono richiedere più di 6 minuti.

Gli aggiornamenti avviati al gateway applicazione vengono applicati un dominio di aggiornamento alla volta. Man mano che vengono aggiornate le istanze di ogni dominio di aggiornamento, le istanze rimanenti in altri domini di aggiornamento continuano a gestire il traffico¹. Le connessioni attive vengono svuotate normalmente dalle istanze da aggiornare per un massimo di 5 minuti per consentire la connettività alle istanze in un dominio di aggiornamento diverso prima dell'inizio dell'aggiornamento. Durante l'aggiornamento, il gateway applicazione viene eseguito temporaneamente alla capacità massima ridotta, determinata dal numero di istanze configurate. Il processo di aggiornamento passa al set successivo di istanze solo se il set corrente di istanze è stato aggiornato correttamente.

¹ È consigliabile configurare un numero minimo di istanze pari a 2 per le distribuzioni di SKU v1 del gateway applicazione per garantire che almeno un'istanza possa gestire il traffico mentre vengono applicati gli aggiornamenti.

Il gateway applicazione supporta il proxy del protocollo TLS/TCP tramite il proxy di livello 4 in Anteprima.

Il proxy di livello 7 del gateway applicazione con protocolli HTTP(S) non supporterà protocolli di e-mail come SMTP, IMAP e POP3. Tuttavia, per alcuni servizi di e-mail di supporto, ad esempio Outlook Web Access (OWA), ActiveSync e traffico di Individuazione automatica che usa protocolli HTTP(S), è possibile usare il proxy di livello 7 e il relativo traffico deve fluire attraverso. Nota: le esclusioni nelle regole WAF potrebbero essere necessarie quando si usa uno SKU WAF.

Sì. Per maggiori informazioni, vedere Eseguire la migrazione del gateway applicazione di Azure e del web application firewall da v1 a v2.

Sì. Lo SKU v1 del gateway applicazione continua a essere supportato. È consigliabile passare alla versione 2 per sfruttare i vantaggi degli aggiornamenti delle funzionalità in tale SKU. Per altre informazioni sulle differenze tra le funzionalità v1 e v2, vedere Scalabilità automatica e gateway applicazione con ridondanza della zona v2. È possibile eseguire manualmente la migrazione delle distribuzioni di SKU v1 del gateway applicazione alla versione 2 seguendo il documento sulla migrazione v1-v2.

No. Il gateway applicazione v2 non supporta il proxy delle richieste con l'autenticazione NTLM o Kerberos.

I nomi di intestazione della richiesta possono contenere caratteri alfanumerici e trattini. I nomi di intestazione della richiesta che contengono altri caratteri vengono eliminati quando una richiesta viene inviata alla destinazione back-end. I nomi delle intestazioni di risposta possono contenere qualsiasi carattere alfanumerico e simboli specifici definiti in RFC 7230.

Sì. Il browser Chromium aggiornamento v80 ha introdotto un mandato per i cookie HTTP senza l'attributo SameSite da considerare come SameSite=Lax. Ciò significa che il cookie di affinità del gateway applicazione non verrà inviato dal browser in un contesto di terze parti.

Per supportare questo scenario, il gateway applicazione inserisce un altro cookie chiamato ApplicationGatewayAffinityCORS oltre al cookie ApplicationGatewayAffinity esistente. Questi cookie sono simili, ma il cookie ApplicationGatewayAffinityCORS ha altri due attributi aggiunti: SameSite=None e Secure. Questi attributi gestiscono sessioni permanenti anche per le richieste tra origini. Per altre informazioni, vedere la sezione affinità basata su cookie.

Un listener attivo è un listener associato a una regola e invia il traffico a un pool back-end. Qualsiasi listener che reindirizza solo il traffico non è un listener attivo. I listener associati alle regole di reindirizzamento non sono considerati attivi. Se la regola di reindirizzamento è una regola basata sul percorso, tutti i percorsi in tale regola di reindirizzamento devono reindirizzare il traffico oppure il listener viene considerato attivo. Per informazioni dettagliate sul limite dei singoli componenti, vedere Sottoscrizione di Azure e limiti del servizio, quote e vincoli.

Lo SKU v1 del gateway applicazione supporta scenari di disponibilità elevata se sono state distribuite due o più istanze. Azure distribuisce queste istanze nei domini di errore e di aggiornamento per impedire l'arresto simultaneo di tutte le istanze. Lo SKU versione 1 supporta la scalabilità tramite l'aggiunta di più istanze dello stesso gateway per ripartire il carico.

Lo SKU V2 garantisce automaticamente che le nuove istanze vengono distribuite tra domini di errore e domini di aggiornamento. Se si sceglie la ridondanza della zona, le istanze più recenti vengono anche distribuite tra le zone di disponibilità per offrire resilienza dagli errori delle zone.

Usare Gestione traffico di Azure per distribuire il traffico tra più gateway applicazione in data center diversi.

Sì. È possibile configurare lo svuotamento delle connessioni per modificare i membri all'interno di un pool back-end senza interruzioni. Per altre informazioni, vedere la sezione Svuotamento delle connessioni di Gateway applicazione.

Sì, lo SKU versione 2 del gateway applicazione supporta la scalabilità automatica. Per altre informazioni, vedere Gateway applicazione con scalabilità automatica e ridondanza della zona.

No. Le istanze vengono distribuite tra domini di aggiornamento e domini di errore.

Sì.

Sì.

Sì. Il gateway applicazione viene sempre distribuito in una subnet di rete virtuale. Questa subnet può contenere solo gateway applicazione. Per altre informazioni, vedere i requisiti della rete virtuale e della subnet.

Se è disponibile la connettività IP, il gateway applicazione può comunicare con le istanze all'esterno della rete virtuale in cui si trova. Il gateway applicazione può anche comunicare con istanze all'esterno della sottoscrizione in cui si trova. Se si prevede di usare indirizzi IP interni come membri del pool back-end, usare il peering di reti virtuali o il gateway VPN di Azure.

Come qualsiasi resolver DNS, la risorsa del gateway applicazione rispetta il valore TTL (Time to Live) del record DNS del server back-end. Dopo la scadenza del TTL, il gateway esegue una ricerca per aggiornare le informazioni DNS. Durante questa ricerca, se il gateway applicazione rileva un problema durante il recupero di una risposta (o non viene trovato alcun record DNS), il gateway continua a usare l'ultimo valore DNS valido noto per gestire il traffico. Per altre informazioni, vedere Funzionamento di un gateway applicazione.

Le istanze del gateway applicazione usano la configurazione DNS della rete virtuale per la risoluzione dei nomi. Dopo aver modificato qualsiasi configurazione del server DNS, è necessario riavviare (Arrestare e avviare) il gateway applicazione per assegnare i nuovi server DNS. Fino ad allora, le risoluzioni dei nomi basate su FQDN per la connettività in uscita potrebbero non riuscire.

No. Ma è possibile distribuire altri gateway applicazione nella subnet.

È possibile spostare un gateway applicazione tra subnet solo all'interno della stessa rete virtuale. È supportato con v1 con un front-end pubblico e privato (allocazione dinamica) e v2 solo con un front-end pubblico. Non è possibile spostare il gateway applicazione in un'altra subnet se la configurazione IP front-end privato viene allocata in modo statico. Per eseguire questa azione, il gateway applicazione deve trovarsi in uno stato Arrestato. L'arresto o l'avvio della versione 1 modifica l'indirizzo IP pubblico. Questa operazione può essere eseguita solo usando Azure PowerShell e l'interfaccia della riga di comando di Azure con i comandi seguenti:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Per altre informazioni, vedere Set-AzApplicationGatewayIPConfiguration.

Interfaccia della riga di comando di Azure

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Vedere Gruppi di sicurezza di rete nella subnet del gateway applicazione.

Vedere Route definite dall'utente supportate nella subnet del gateway applicazione.

No. I criteri degli endpoint di servizio per gli account di archiviazione non sono supportati nella subnet del gateway applicazione e la configurazione di questa impostazione comporta il blocco del traffico dell'infrastruttura di Azure.

Vedere Limiti del gateway applicazione.

Sì. Il gateway applicazione supporta un indirizzo IP interno e un indirizzo IP esterno.

Sì. Il peering di reti virtuali consente di bilanciare il carico del traffico in altre reti virtuali.

Sì, se il traffico è consentito.

L'architettura di microservizi è supportata. Per il probe su porte diverse è necessario configurare più impostazioni back-end.

No.

Vedere Ordine di elaborazione delle regole.

Il campo Host specifica il nome a cui inviare il probe quando è stato configurato il multisito nel gateway applicazione. In caso contrario, usare 127.0.0.1. Questo valore è diverso dal nome host della macchina virtuale. Il formato è <protocollo>://<host>:<porta><percorso>.

Sì. Vedere Limitare l'accesso a IP di origine specifici.

Sì, è possibile usare listener pubblici e privati con lo stesso numero di porta per supportare contemporaneamente client pubblici e privati. Se un gruppo di sicurezza di rete (NSG) è associato alla subnet del gateway applicazione, potrebbe essere necessaria una regola in ingresso specifica a seconda della configurazione. Maggiori informazioni.

Il gateway applicazione v2 supporta front-end IPv4 e IPv6. Attualmente, il supporto IPv6 è disponibile solo per i nuovi gateway applicazione. Per supportare IPv6, la rete virtuale deve essere dual stack. Il gateway applicazione v1 non supporta reti virtuali dual stack.

Gli SKU v1 del gateway applicazione possono essere eseguiti in una modalità di funzionamento approvata da FIPS 140-2, comunemente definita "modalità FIPS". La modalità FIPS chiama un modulo di crittografia convalidato FIPS 140-2 che garantisce algoritmi conformi a FIPS per la crittografia, l'hashing e la firma quando sono abilitati. Per assicurarsi che la modalità FIPS sia abilitata, l'impostazione FIPSMode deve essere configurata tramite PowerShell, il modello di Azure Resource Manager o l'API REST dopo la registrazione della sottoscrizione per abilitare la configurazione di FIPSmode.

Nota: come parte della conformità FedRAMP, il governo degli Stati Uniti impone che i sistemi operano in modalità approvata da FIPS dopo agosto 2024.

Passaggi per abilitare la modalità FIPS nello SKU V1:

Passaggio 1: registrare la funzionalità "AllowApplicationGatewayEnableFIPS" per registrare la sottoscrizione per la configurazione della modalità FIPS.

Per eseguire la registrazione con Azure PowerShell, aprire un prompt di Cloud Shell e immettere quanto segue:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Per eseguire la registrazione con il portale di Azure:

• Accedere al portale di Azuree cercare Funzionalità di anteprima.
• Immettere AllowApplicationGatewayEnableFIPS nella casella del filtro. Selezionare Gateway applicazione V1 Consenti modalità FIPS e quindi selezionare Registra.

Passaggio 2: impostare la proprietà enableFips su True usando PowerShell, il modello di Azure Resource Manager o l'API REST.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

La modifica della modalità FIPS non influisce sulla disponibilità complessiva dei pacchetti di crittografia nei gateway V1. Tuttavia, quando si usa la crittografia a curva ellittica per le crittografie, con la modalità FIPS disabilitata è possibile usare curve25519, NistP256 e NistP384, mentre con la modalità FIPS abilitato solo NistP256 e NistP384 sono consentiti e curve25519 è disabilitato. Poiché curve25519 non è più disponibile in modalità FIPS, assicurarsi che i client supportino NistP256 o NistP384 per la comunicazione sicura prima di abilitare FIPS.

Il gateway applicazione v2 supporta attualmente solo la configurazione front-end IP privato (nessun indirizzo IP pubblico) tramite l'anteprima pubblica. Per altre informazioni, vedere distribuzione del gateway applicazione privato (anteprima).

Per il supporto della disponibilità generale corrente, il gateway applicazione v2 supporta le combinazioni seguenti:

• IP privato e IP pubblico
• Solo IP pubblico

Per limitare il traffico solo agli indirizzi IP privati con la funzionalità corrente, seguire questa procedura:

1. Creare un gateway applicazione con un indirizzo IP front-end pubblico e privato.

2. Non creare listener per l'indirizzo IP front-end pubblico. Il gateway applicazione non sarà in ascolto di alcun traffico sull'indirizzo IP pubblico se non viene creato alcun listener.

3. Creare e associare un gruppo di sicurezza di rete per la subnet del gateway applicazione con la configurazione seguente in ordine di priorità:

   1. Consentire il traffico dall’origine come tag del servizio GatewayManager, la Destinazione come Qualsiasi e la porta di destinazione come 65200-65535. Questo intervallo di porte è necessario per la comunicazione di infrastruttura di Azure. Queste porte sono protette (bloccate) tramite l'autenticazione del certificato. Le entità esterne, inclusi gli amministratori utenti del gateway, non possono avviare modifiche sugli endpoint senza certificati appropriati.

   2. Consentire il traffico dall'origine come tag del servizio AzureLoadBalancer e porta di destinazione come Qualsiasi.

   3. Negare tutto il traffico in ingresso dall'origine come tag del servizio Internet e la porta di destinazione come qualsiasi. Assegnare a questa regola la priorità minima nelle regole in ingresso.

   4. Mantenere le regole predefinite, ad esempio AllowVNetInBound, in modo che l'accesso in un indirizzo IP privato non venga bloccato.

   5. La connettività Internet in uscita non può essere bloccata. In caso contrario, si riscontrano problemi con la registrazione e le metriche.

Esempio di configurazione del gruppo di sicurezza di rete per l'accesso solo IP privato:

È possibile usare Azure PowerShell o l'interfaccia della riga di comando di Azure per arrestare e avviare il gateway applicazione. Quando si arresta e si avvia il gateway applicazione, viene arrestata e avviata anche la fatturazione. Qualsiasi operazione PUT eseguita su un gateway applicazione arrestato (ad esempio l'aggiunta di tag, probe di integrità o listener) attiva un avvio. È consigliabile arrestare il gateway applicazione dopo l'aggiornamento della configurazione.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Il gateway applicazione supporta i certificati autofirmati, i certificati della CA (Certificate Authority), i certificati EV (Extended Validation), i certificati multidominio (SAN) e i certificati con caratteri jolly.

Il gateway applicazione supporta i pacchetti di crittografia seguenti:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Per informazioni su come personalizzare le opzioni TLS, vedere Configurare i pacchetti di crittografia e le versioni dei criteri TLS nel gateway applicazione.

Sì. Il gateway applicazione supporta l'offload TLS e il TLS end-to-end, che ripete la crittografia del traffico nel back-end.

Sì. È possibile configurare il gateway applicazione per rifiutare TLS1.0, TLS1.1 e TLS1.2. Per impostazione predefinita, SSL 2.0 e 3.0 sono già disabilitati e non sono configurabili.

Sì. Nel gateway applicazione è possibile configurare i pacchetti di crittografia. Per definire criteri personalizzati, abilitare almeno uno dei pacchetti di crittografia seguenti:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Il gateway applicazione usa SHA256 per la gestione del back-end.

Il gateway applicazione supporta fino a 100 certificati TLS/SSL.

Sì, il gateway applicazione supporta i certificati con estensioni OCSP e l'associazione OCSP per i certificati server.

Il gateway applicazione supporta fino a 100 certificati di autenticazione.

Sì, lo SKU versione 2 del gateway applicazione supporta Key Vault. Per altre informazioni, vedere Terminazione TLS con certificati di Key Vault.

Per routing basati su dominio (basati su host) multipli, è possibile creare listener multisito, configurare i listener che usano HTTPS come protocollo e associare i listener alle regole di gestione. Per altre informazioni, vedere Hosting di più siti in un gateway applicazione.

No. Usare solo caratteri alfanumerici nella password del file con estensione pfx.

I membri del browser dell'autorità di certificazione (CA) hanno pubblicato di recente alcuni report che elencano in dettaglio più certificati rilasciati dai fornitori di CA usati dai clienti, da Microsoft e dalla più estesa community di tecnologie che non erano conformi agli standard del settore per le CA attendibili pubblicamente. I report relativi alle CA non conformi sono disponibili qui:

• Bug 1649951
• Bug 1650910

In base ai requisiti di conformità del settore, i fornitori di CA hanno iniziato a revocare le CA non conformi e a rilasciare CA conformi che richiedono ai clienti un nuovo rilascio dei certificati. Microsoft collabora strettamente con questi fornitori per ridurre al minimo il potenziale impatto sui servizi di Azure. Tuttavia, i certificati o i certificati autoemessi usati negli scenari BYOC (Bring Your Own Certificate) sono ancora a rischio di essere revocati in modo imprevisto.

Per verificare se i certificati usati dall'applicazione sono stati revocati, vedere annuncio di DigiCert e il sito che tiene traccia delle revoche dei certificati. Se i certificati sono stati revocati o verranno revocati, è necessario richiedere nuovi certificati al fornitore della CA utilizzato nelle applicazioni. Per evitare che la disponibilità dell'applicazione venga interrotta a causa di certificati revocati in modo imprevisto o per aggiornare un certificato revocato, vedere Revoca di autorità di certificazione non conformi che potrebbero influire sui servizi di Azure del cliente.

Per informazioni specifiche del gateway applicazione:

Se si usa un certificato emesso da uno degli ICA revocati, la disponibilità dell'applicazione potrebbe essere interrotta. A seconda dell'applicazione, è possibile che vengano visualizzati vari messaggi di errore, tra cui:

• Certificato non valido/Certificato revocato
• Timeout della connessione
• HTTP 502

Per evitare interruzioni dell'applicazione a causa di questo problema o per eseguire nuovamente una CA revocata, è necessario eseguire le azioni seguenti:

1. Contattare il provider di certificati per informazioni su come eseguire nuovamente i certificati.
2. Dopo che i certificati sono stati nuovamente rilasciati, aggiornarli certificati nel gateway applicazione/WAF con la catena di certificati completa (certificato foglia, intermedio e radice). In base alla posizione in cui si usa il certificato, nel listener o nelle impostazioni HTTP del gateway applicazione, seguire questa procedura per aggiornare i certificati. Per altre informazioni, vedere i collegamenti alla documentazione indicati.
3. Aggiornare i server applicazioni back-end per usare il certificato nuovamente rilasciato. A seconda del server back-end in uso, la procedura di aggiornamento del certificato può variare. Vedere la documentazione del fornitore.

Per aggiornare il certificato nel listener:

1. Nel portale di Azure aprire la risorsa del gateway applicazione.
2. Aprire le impostazioni del listener associate al certificato.
3. Selezionare Rinnova o modifica il certificato selezionato.
4. Caricare il nuovo certificato PFX con la password e selezionare Salva.
5. Accedere al sito Web e verificare se il sito funziona come previsto. Per altre informazioni, vedere Rinnova i certificati del gateway applicazione.

Se si fa riferimento a certificati di Key Vault nel listener del gateway applicazione, è consigliabile seguire questa procedura per una modifica rapida:

1. Nel portale di Azure passare alle impostazioni di Key Vault associate al gateway applicazione.
2. Aggiungere o importare nell'archivio il certificato nuovamente rilasciato. Per altre informazioni, vedere Avvio rapido: Creare un insieme di credenziali delle chiavi usando il portale di Azure.
3. Dopo aver importato il certificato, passare alle impostazioni del listener del gateway applicazione e in Scegliere un certificato da Key Vault selezionare l'elenco a discesa Certificato e selezionare il certificato aggiunto di recente.
4. Seleziona Salva. Per altre informazioni sulla terminazione TLS nel gateway applicazione con certificati di Key Vault, vedere Terminazione TLS con certificati di Key Vault.

Per aggiornare il certificato nelle impostazioni HTTP:

Se si usa lo SKU v1 del servizio gateway applicazione/WAF, è necessario caricare il nuovo certificato come certificato di autenticazione back-end.

1. Nel portale di Azure aprire la risorsa del gateway applicazione.
2. Aprire le impostazioni HTTP associate al certificato.
3. Selezionare Aggiungi certificato, caricare il certificato riemesso e selezionare Salva.
4. È possibile rimuovere il certificato precedente in un secondo momento selezionando il pulsante delle opzioni ... accanto al certificato precedente. Selezionare Elimina e quindi selezionare Salva. Per altre informazioni, vedere Configurare TLS end-to-end usando il gateway applicazione con il portale.

Se si usa lo SKU V2 del gateway applicazione/servizio WAF, non è necessario caricare il nuovo certificato nelle impostazioni HTTP perché lo SKU V2 usa "certificati radice trusted" e non è necessario eseguire alcuna azione.

Sì. Sia il routing di livello 7 che quello di livello 4 tramite il gateway applicazione usano la stessa configurazione IP front-end. In questo modo, è possibile indirizzare tutti i client a un singolo indirizzo IP (pubblico o privato) e la stessa risorsa del gateway li instrada in base ai protocolli del listener configurati e alle porte.

Anche se il traffico HTTP(S) può essere gestito anche tramite i protocolli proxy L4, non è consigliabile farlo. La soluzione proxy L7 del gateway applicazione offre maggiore controllo e sicurezza sui protocolli HTTP(S) tramite funzionalità avanzate quali Riscrittura, Affinità di sessione, Reindirizzamento, WebSocket, WAF e altro ancora.

Le proprietà delle risorse per le funzionalità di livello 4 sono diverse da quelle di livello 7. Di conseguenza, quando si usano l'API REST o l'interfaccia della riga di comando, è necessario usare le proprietà seguenti.

• REST API
• CLI

No. Non è possibile collegare le proprietà layer 4 e layer 7. Pertanto, una regola di routing consentirà solo di collegare un listener di livello 4 a un'impostazione back-end di livello 4.

Non è possibile usare lo stesso nome per un L7 (httpListeners) e L4 (listener). Questo vale anche per altre proprietà L4, ad esempio backendSettingsCollection e routingRules.

Assolutamente. Analogamente al proxy di livello 7, è possibile aggiungere un endpoint privato al pool back-end del gateway applicazione. Questo endpoint privato deve essere distribuito in una subnet adiacente della stessa rete virtuale del gateway applicazione.

Non usa Keepalive per le connessioni back-end. Per ogni richiesta in ingresso nella connessione del listener front-end, il gateway applicazione avvia una nuova connessione back-end per soddisfare tale richiesta.

Il server back-end vede l'indirizzo IP del gateway applicazione. Attualmente non è supportata la "conservazione IP client" tramite la quale l'applicazione back-end può essere presa in considerazione dell'indirizzo IP del client originale.

La stessa configurazione dei criteri TLS/SSL è applicabile sia per il livello 7 (HTTPS) sia per il livello 4 (TLS). È ora possibile usare il profilo SSL (per i criteri TLS specifici del listener e l'autenticazione reciproca) per i listener TLS. Attualmente, tuttavia, un profilo SSL può essere associato a un listener TLS tramite l'interfaccia della riga di comando, PowerShell o solo l'API REST.

No. Il routing di un client allo stesso server back-end non è attualmente supportato. Le connessioni verranno distribuite in modo round robin ai server in un pool back-end.

Sì, la funzionalità di scalabilità automatica funzionerà anche per picchi e riduzioni del traffico per il protocollo TLS o TCP.

Le funzionalità web application firewall (WAF) non funzioneranno per l'utilizzo di livello 4.

No. Il supporto UDP non è attualmente disponibile.

Lo stesso elenco di intervalli di porte consentiti e eccezioni si applica anche per il proxy di livello 4.

L'uso di una porta comune per i listener TLS/TCP non è attualmente supportato.

Kubernetes consente la creazione delle risorse deployment e service per esporre un gruppo di pod internamente nel cluster. Per esporre lo stesso servizio esternamente, viene definita una risorsa Ingress che offre il bilanciamento del carico, la terminazione TLS e l'hosting virtuale basato sul nome. Per soddisfare questa risorsa Ingress, è necessario un controller di ingresso che rimane in ascolto delle modifiche apportate alle risorse Ingress e configura i criteri del servizio di bilanciamento del carico.

Il controller di ingresso del gateway applicazione consente di usare il gateway applicazione come ingresso per un servizio Azure Kubernetes, noto anche come cluster del servizio Azure Kubernetes.

La configurazione diretta del gateway applicazione non è supportata.

Se è necessario modificare le impostazioni nel gateway applicazione, apportare la modifica usando la configurazione esposta nel controller in ingresso o in altri oggetti Kubernetes, ad esempio usando annotazioni supportate. Quando un gateway applicazione è collegato al controller in ingresso del gateway applicazione (AGIC), quasi tutte le configurazioni di tale gateway verranno sincronizzate e controllate dal controller in ingresso. Se si sta tentando di configurare direttamente il gateway applicazione in modo imperativo o tramite l'infrastruttura come codice, tali modifiche verranno infine sovrascritte dal controller in ingresso.

Attualmente, un'istanza di un controller di ingresso può essere associata a un solo gateway applicazione.

AGIC tenta di associare automaticamente la risorsa della tabella di route alla subnet del gateway applicazione, ma potrebbe non riuscire a farlo a causa della mancanza di autorizzazioni da AGIC. Se AGIC non è in grado di associare la tabella di route alla subnet del gateway applicazione, nei log del gateway applicazione viene visualizzato un errore. In questo caso, è necessario associare manualmente la tabella di route creata dal cluster del servizio Azure Kubernetes alla subnet del gateway applicazione. Per altre informazioni, vedere Route definite dall'utente supportate.

Sì, purché le reti virtuali siano impostate per il peer e non includano spazi indirizzi sovrapposti. Se si esegue il servizio Azure Kubernetes con kubenet, assicurarsi di associare la tabella di route generata dal servizio Azure Kubernetes alla subnet del gateway applicazione.

Per le differenze tra AGIC distribuito tramite Helm e distribuito come componente aggiuntivo del servizio Azure Kubernetes, vedere Differenza tra la distribuzione Helm e il componente aggiuntivo del servizio Azure Kubernetes.

Per le differenze tra AGIC distribuito tramite Helm e distribuito come componente aggiuntivo del servizio Azure Kubernetes, vedere Differenza tra la distribuzione Helm e il componente aggiuntivo servizio Azure Kubernetes, in particolare le tabelle che documentano gli scenari supportati da AGIC distribuiti tramite Helm anziché un componente aggiuntivo del servizio Azure Kubernetes. In generale, la distribuzione tramite Helm consente di testare le funzionalità beta e le versioni finali candidate prima di una versione ufficiale.

No. Il componente aggiuntivo AGIC è un servizio gestito. Questo significa che Microsoft aggiorna automaticamente il componente aggiuntivo alla versione stabile più recente.

L'autenticazione reciproca corrisponde all'autenticazione bidirezionale tra un client e un server. L'autenticazione reciproca con il gateway applicazione consente attualmente al gateway di verificare il client che invia la richiesta, che corrisponde all'autenticazione client. In genere, il client è l'unico che autentica il gateway applicazione. Dal momento che anche il gateway applicazione può ora autenticare il client, diventa un'autenticazione reciproca in cui il gateway applicazione e il client si autenticano reciprocamente.

No, l'autenticazione reciproca è attualmente solo disponibile tra il client front-end e il gateway applicazione. L'autenticazione reciproca back-end non è attualmente supportata.

Il gateway applicazione offre tre log:

• ApplicationGatewayAccessLog: il log di accesso contiene ogni richiesta inviata al front-end del gateway applicazione. I dati includono IP del chiamante, URL richiesto, latenza della risposta, codice restituito e byte in ingresso e in uscita. Il log contiene un record per ogni gateway applicazione.
• ApplicationGatewayPerformanceLog: il log delle prestazioni acquisisce informazioni sulle prestazioni per ogni gateway applicazione. Le informazioni includono la velocità effettiva in byte, le richieste totali gestite, il numero di richieste non riuscite e il numero di istanze back-end integre e non integre.
• ApplicationGatewayFirewallLog: Per i gateway applicazione configurati con WAF, il log del firewall contiene le richieste registrate tramite la modalità di rilevamento o la modalità di prevenzione.

Tutti i log vengono raccolti ogni 60 secondi. Per altre informazioni, vedere Integrità back-end, log di diagnostica e metriche per il gateway applicazione.

Verificare lo stato di integrità usando il cmdlet di PowerShell Get-AzApplicationGatewayBackendHealth o il portale. Per altre informazioni, vedere Diagnostica del gateway applicazione.

Il flusso dei log di diagnostica viene inviato all'account di archiviazione del cliente. I clienti possono impostare i criteri di conservazione in base alle proprie preferenze. I log di diagnostica possono anche essere inviati a un hub eventi o a log di Monitoraggio di Azure. Per altre informazioni, vedere Diagnostica del gateway applicazione.

Nel portale, nel riquadro del menu di un gateway applicazione selezionare Log attività per accedere al log di controllo.

Sì. Nel gateway applicazione gli avvisi sono configurati nelle metriche. Per altre informazioni, vedere Metriche per il gateway applicazione e Ricevere notifiche di avviso.

È possibile visualizzare e analizzare i log di accesso in diversi modi. Usare i log di Monitoraggio di Azure, Excel, Power BI e così via.

È anche possibile usare un modello di Resource Manager che installa ed esegue il diffuso analizzatore di log GoAccess per i log di accesso del gateway applicazione. GoAccess offre statistiche utili sul traffico HTTP, ad esempio numero di visitatori unici, file richiesti, host, sistemi operativi, browser, codici di stato HTTP. Per altre informazioni, in GitHub vedere il file Readme nella cartella del modello di Resource Manager.

In genere, viene visualizzato uno stato sconosciuto quando l'accesso al back-end è bloccato da un gruppo di sicurezza di rete, un DNS personalizzato o un routing definito dall'utente nella subnet del gateway applicazione. Per altre informazioni, vedere integrità back-end, registrazione diagnostica e metriche per il gateway applicazione.

A causa delle limitazioni correnti della piattaforma, se si dispone di un gruppo di sicurezza di rete nella subnet del gateway applicazione v2 (Standard_v2, WAF_v2) e se è stato abilitato il flusso del gruppo di sicurezza di rete, viene visualizzato un comportamento non deterministico. Questo scenario non è attualmente supportato.

Il gateway applicazione non sposta o archivia i dati dei clienti al di fuori dell'area in cui è distribuito.

Passaggi successivi

• Per altre informazioni sul gateway applicazione, vedere Cos'è il gateway applicazione di Azure?
• Per informazioni sulla terminazione TLS e su TLS end-to-end con il gateway applicazione, vedere Abilitare TLS end-to-end nel gateway applicazione di Azure.