Configurazione del listener del gateway applicazione
Nota
È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.
Un listener è un'entità logica che verifica la presenza di richieste di connessione in ingresso usando la porta, il protocollo, l'host e l'indirizzo IP. Quando si configura il listener, i valori inseriti per questi elementi devono coincidere con i valori corrispondenti presenti nella richiesta in ingresso nel gateway.
Quando si crea un gateway applicazione usando il portale di Azure, si crea anche un listener predefinito scegliendo il protocollo e la porta. È possibile scegliere se abilitare il supporto HTTP2 nel listener. Dopo aver creato il gateway applicazione, è possibile modificare le impostazioni del listener predefinito (appGatewayHttpListener) o creare nuovi listener.
Tipo di listener
Quando si crea un nuovo listener, è possibile scegliere tra base e multisito.
Se si vuole che tutte le richieste (per qualsiasi dominio) vengano accettate e inoltrate ai pool back-end, scegliere di base. Informazioni su come creare un gateway applicazione con un listener di base.
Se si desidera inoltrare le richieste a pool back-end diversi in base all'intestazione host o ai nomi host, scegliere listener multisito. Il gateway applicazione si basa su intestazioni host HTTP 1.1 per ospitare più siti Web nello stesso indirizzo IP pubblico e nella stessa porta. Per distinguere le richieste sulla stessa porta, è necessario specificare un nome host corrispondente alla richiesta in ingresso. Per altre informazioni, vedere Hosting di più siti tramite gateway applicazione.
Ordine dei elaborazione dei listener
Per lo SKU v1, la corrispondenza con le richieste viene cercata in base all'ordine delle regole e al tipo di listener. Se una regola con listener di base risulta prima nell'ordine, viene elaborata per prima e accetterà qualsiasi richiesta per tale combinazione di porta e IP. Per evitare questo problema, configurare prima le regole con listener multisito ed eseguire il push della regola con il listener di base alla fine dell'elenco.
Per lo SKU v2, i listener multisito vengono elaborati prima dei listener di base, a meno che non sia definita la priorità delle regole. Se si usa la priorità della regola, è necessario definire una priorità con un numero maggiore di listener non con caratteri jolly, per garantire che i listener non con caratteri jolly vengano eseguiti prima dei listener con caratteri jolly.
Indirizzo IP front-end IP
Scegliere l'indirizzo IP front-end che si prevede di associare a questo listener. Il listener resterà in ascolto delle richieste in ingresso a questo indirizzo IP.
Nota
gateway applicazione front-end supporta gli indirizzi IP dual stack. È possibile creare fino a quattro indirizzi IP front-end: due indirizzi IPv4 (pubblici e privati) e due indirizzi IPv6 (pubblici e privati).
Porta front-end
Associare una porta front-end. È possibile selezionare una porta esistente o crearne una nuova. Scegliere qualsiasi valore dall'intervallo di porte consentito. È possibile usare non solo le porte note, ad esempio 80 e 443, ma anche qualsiasi porta personalizzata consentita che risulti adatta. La stessa porta può essere usata per listener pubblici e privati.
Nota
Quando si usano listener privati e pubblici con lo stesso numero di porta, il gateway applicazione modifica la "destinazione" del flusso in ingresso agli indirizzi IP front-end del gateway. Di conseguenza, a seconda della configurazione del gruppo di sicurezza di rete, potrebbe essere necessaria una regola in ingresso con indirizzi IP di destinazione come indirizzi IP front-end pubblici e privati del gateway applicazione.
Regola in ingresso:
- Origine: (in base alle esigenze)
- Indirizzi IP di destinazione: indirizzi IP front-end pubblici e privati del gateway applicazione.
- Porta di destinazione: (in base alla configurazione del listener)
- Protocollo: TCP
Regola in uscita: (nessun requisito specifico)
Protocollo
Scegliere HTTP o HTTPS:
Se si sceglie HTTP, il traffico tra il client e il gateway applicazione non è crittografato.
Scegliere HTTPS se si vuole la terminazione TLS o la crittografia TLS end-to-end. Il traffico tra il client e il gateway applicazione viene crittografato e la connessione TLS verrà terminata nel gateway applicazione. Se si vuole che la crittografia TLS end-to-end sia alla destinazione back-end, è necessario scegliere anche HTTPS all'interno dell'impostazione HTTP back-end. In questo modo il traffico viene crittografato quando il gateway applicazione avvia una connessione alla destinazione back-end.
Per configurare la terminazione TLS, è necessario aggiungere un certificato TLS/SSL al listener. Ciò consente al gateway applicazione di decrittografare il traffico in ingresso e crittografare il traffico di risposta al client. Il certificato fornito al gateway applicazione deve essere in formato PFX (Personal Information Exchange), che contiene sia le chiavi private che pubbliche.
Nota
Quando si usa un certificato TLS da Key Vault per un listener, è necessario assicurarsi che l'gateway applicazione abbia sempre accesso a tale risorsa dell'insieme di credenziali delle chiavi collegate e all'oggetto certificato al suo interno. Ciò consente operazioni semplici della funzionalità di terminazione TLS e mantiene l'integrità complessiva della risorsa del gateway. Se una risorsa del gateway applicazione rileva un insieme di credenziali delle chiavi non configurato correttamente, inserisce automaticamente i listener HTTPS associati in uno stato disabilitato. Altre informazioni.
Certificati supportati
Vedere Panoramica della terminazione TLS e di TLS end-to-end con gateway applicazione
Supporto aggiuntivo del protocollo
Supporto HTTP2
Il supporto del protocollo HTTP/2 è disponibile solo per i client che si connettono ai listener del gateway applicazione. La comunicazione con i pool di server back-end è sempre HTTP/1.1. Per impostazione predefinita, il supporto di HTTP/2 è disabilitato. Il frammento di codice di Azure PowerShell seguente illustra come abilitare questa procedura:
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
È anche possibile abilitare il supporto HTTP2 usando il portale di Azure selezionando Abilitato in HTTP2 in Configurazione del gateway > applicazione.
Supporto per WebSocket
Il supporto webSocket è abilitato per impostazione predefinita. Non esiste alcuna impostazione configurabile dall'utente per abilitarla o disabilitarla. È possibile usare WebSocket con listener HTTP e HTTPS.
Pagine di errore personalizzate
È possibile definire pagine di errore personalizzate per codici di risposta diversi restituiti dal gateway applicazione. I codici di risposta per cui è possibile configurare le pagine di errore sono 400, 403, 405, 408, 500, 502, 503 e 504. È possibile usare la configurazione della pagina di errore specifica del listener o a livello globale per impostarle in modo granulare per ogni listener. Per altre informazioni, vedere Create Application Gateway custom error pages (Creare pagine di errore personalizzate del gateway applicazione).
Nota
Un errore proveniente dal server back-end viene passato lungo un valore non modificato dal gateway applicazione al client.
Criteri TLS
È possibile centralizzare la gestione dei certificati TLS/SSL e ridurre il sovraccarico di decrittografia della crittografia per una server farm back-end. La gestione centralizzata di TLS consente anche di specificare un criterio TLS centrale adatto ai requisiti di sicurezza. È possibile scegliere criteri TLS predefiniti o personalizzati .
I criteri TLS vengono configurati per controllare le versioni del protocollo TLS. È possibile configurare un gateway applicazione per usare una versione minima del protocollo per gli handshake TLS da TLS1.0, TLS1.1, TLS1.2 e TLS1.3. Per impostazione predefinita, SSL 2.0 e 3.0 sono disabilitati e non sono configurabili. Per altre informazioni, vedere gateway applicazione panoramica dei criteri TLS.
Dopo aver creato un listener, associarlo a una regola di routing delle richieste. Tale regola determina il modo in cui le richieste ricevute nel listener vengono instradate al back-end.