Domande frequenti sul gateway applicazione di Azure

app Azure lication Gateway fornisce un controller di recapito dell'applicazione 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à gateway applicazione v2 (Standard_v2 e WAF_v2), vedere Aree supportate per 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, sono disponibili le informazioni IP e DNS sulla risorsa indirizzo IP pubblico. In alternativa, è possibile trovarlo nella 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.

Keep-Alive timeout determina per quanto tempo il gateway applicazione attende che un client invii un'altra richiesta HTTP a una connessione permanente prima di riutilizzarla o chiuderla. Il timeout di inattività TCP determina per quanto tempo una connessione TCP viene mantenuta aperta se non è presente alcuna attività.

Il Keep-Alive timeout nello SKU gateway applicazione v1 è di 120 secondi e nello SKU v2 è di 75 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 v1 e v2 gateway applicazione in modo che siano comprese tra 4 minuti e 30 minuti. Sia per le istanze v1 che v2 gateway applicazione, è 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 in gateway applicazione SKU v2, il timeout di inattività è impostato su 180 secondi e non è configurabile.

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

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

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

In gateway applicazione SKU v1, 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. In gateway applicazione SKU v2 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 gateway applicazione v2 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 ogni 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.

Aggiornamenti avviato a 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, gateway applicazione temporaneamente viene eseguito con 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 gateway applicazione per assicurarsi che almeno un'istanza possa gestire il traffico mentre vengono applicati gli aggiornamenti.

gateway applicazione supporta 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 posta elettronica come SMTP, IMAP e POP3. Tuttavia, per alcuni servizi di posta elettronica 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 altre informazioni, vedere Eseguire la migrazione del gateway di app Azure lication e web application firewall dalla versione 1 alla versione 2.

Sì. Lo SKU gateway applicazione v1 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 ridondanza della zona gateway applicazione v2. È possibile eseguire manualmente la migrazione gateway applicazione distribuzioni di SKU v1 alla versione 2 seguendo il documento sulla migrazione v1-v2.

No. 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, come definito in RFC 7230.

Sì. L'aggiornamento del browserChromium v80 ha introdotto un mandato sui 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, gateway applicazione inserisce un altro cookie chiamato ApplicationGatewayAffinityCORS oltre al cookie esistenteApplicationGatewayAffinity. Questi cookie sono simili, ma il ApplicationGatewayAffinityCORS cookie 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 Connessione di svuotamento delle gateway applicazione.

Sì, lo SKU versione 2 del gateway applicazione supporta la scalabilità automatica. Per altre informazioni, vedere Scalabilità automatica e gateway applicazione con 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 Requisiti di rete virtuale e subnet.

Se si dispone di connettività IP, gateway applicazione può comunicare con istanze esterne alla 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 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 solo tra subnet 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 eseguendo 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 gateway applicazione e la configurazione blocca il 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 eseguire 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 multisito in 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 indirizzi 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.

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. gateway applicazione v1 non supporta reti virtuali dual stack.

gateway applicazione SKU v1 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.

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 gateway applicazione privata (anteprima).

Per il supporto della disponibilità generale corrente, 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 indirizzo IP front-end pubblico e privato.

2. Non creare listener per l'indirizzo IP front-end pubblico. gateway applicazione non ascolterà alcun traffico sull'indirizzo IP pubblico se non vengono creati listener.

3. Creare e collegare un gruppo di sicurezza di rete per la subnet gateway applicazione con la configurazione seguente nell'ordine di priorità:

   1. Consentire il traffico dall'origine come gatewayManager del servizio, destinazione come Qualsiasi e porta di destinazionecome 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 degli utenti del gateway, non possono avviare modifiche in tali 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.

Configurazione del gruppo di sicurezza di rete di esempio per l'accesso solo IP privato:

È possibile usare Azure PowerShell o l'interfaccia della riga di comando di Azure per arrestare e avviare gateway applicazione. Quando si arresta e si avvia gateway applicazione, anche la fatturazione viene arrestata e avviata. 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.

gateway applicazione supporta le suite 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ì. gateway applicazione supporta TLS offload e TLS end-to-end, che ricrittografa il traffico verso il 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 un criterio personalizzato, abilitare almeno una delle suite 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

gateway applicazione usa SHA256 per la gestione back-end.

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

Sì, 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 pfx.

I membri ca/browser hanno recentemente pubblicato report che illustrano in dettaglio più certificati rilasciati dai fornitori di CA usati dai clienti, Microsoft e dalla community tecnologica più grande che non erano conformi agli standard di settore per 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 ca non conformi e rilasciare ca conformi, che richiedono ai clienti di avere nuovamente i certificati. Microsoft collabora strettamente con questi fornitori per ridurre al minimo il potenziale impatto sui servizi di Azure. Tuttavia, i certificati o i certificati autocertificati usati negli scenari BYOC (Bring Your Own Certificate) sono ancora a rischio di essere revocati in modo imprevisto.

Per verificare se i certificati utilizzati dall'applicazione sono stati revocati, vedere l'annuncio di DigiCert e lo strumento di rilevamento delle revoche di certificati. Se i certificati sono stati revocati o verranno revocati, è necessario richiedere nuovi certificati al fornitore della CA usato 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 per 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 la ristampa, aggiornare i certificati nel gateway applicazione/WAF con la catena completa di attendibilità (foglia, intermedio e certificato 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 in modo che usino il certificato riemesso. A seconda del server back-end in uso, i passaggi di aggiornamento del certificato possono variare. Verificare la documentazione del fornitore.

Per aggiornare il certificato nel listener:

1. Nella portale di Azure aprire la risorsa gateway applicazione.
2. Aprire le impostazioni del listener associate al certificato.
3. Selezionare Rinnova o modifica 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 Rinnovare i certificati gateway applicazione.

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

1. Nella portale di Azure passare alle impostazioni di Key Vault associate al gateway applicazione.
2. Aggiungere o importare il certificato riemesso nell'archivio. 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 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 in gateway applicazione con i 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. Nella portale di Azure aprire la risorsa 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 ... opzioni accanto al certificato precedente. Selezionare Elimina e quindi Salva. Per altre informazioni, vedere Configurare TLS end-to-end usando gateway applicazione con il portale.

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

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 di gateway applicazione offre maggiore controllo e sicurezza sui protocolli HTTP(S) tramite funzionalità avanzate quali Riscritture, 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 back-end Impostazioni Collection 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, 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 SSL è applicabile sia per il livello 7 (HTTPS) sia per il livello 4 (TLS). Attualmente non è supportato il profilo SSL (criteri SSL specifici del listener o l'autenticazione reciproca) per i listener TLS.

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.

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

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

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 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 gateway applicazione, viene visualizzato un errore nei log AGIC. 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 Kubenet con kubenet, assicurarsi di associare la tabella di route generata dal servizio Azure Kubernetes alla subnet 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 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 i candidati per il rilascio prima di una versione ufficiale.

No. Il componente aggiuntivo AGIC è un servizio gestito, il che 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 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 l'INDIRIZZO IP, l'URL richiesto, la latenza della risposta, il codice restituito e i byte in ingresso e in uscita del chiamante. 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 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 riquadro dei menu di un gateway applicazione del portale 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 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 gateway applicazione. Per altre informazioni, vedere Integrità back-end, registrazione diagnostica e metriche per gateway applicazione.

A causa delle limitazioni correnti della piattaforma, se si dispone di un gruppo di sicurezza di rete nella subnet 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.

gateway applicazione non sposta o archivia i dati dei clienti dall'area in cui viene distribuita.

Passaggi successivi

• Per altre informazioni sulle gateway applicazione, vedere Che cos'è app Azure gateway.
• Per informazioni sulla terminazione TLS e su TLS end-to-end con gateway applicazione, vedere Abilitare TLS end-to-end nel gateway di app Azure lication.