Configurazione del listener del gateway applicazione

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, è necessario immettere i valori per ciascuno di essi in modo che corrispondano ai valori corrispondenti nella richiesta in arrivo sul 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. La scelta dipende dal fatto che il routing dipenda dal nome host nella richiesta in arrivo.

Per saperne di più sugli ascoltatori multi-sito, vedi ospitare più siti utilizzando Application Gateway.

Ordine di elaborazione dei listener

Per lo SKU v1, le richieste vengono correlate 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, la priorità della regola definisce l'ordine di elaborazione dei listener. I listener con caratteri jolly e di base devono essere definiti con un numero maggiore di listener specifici del sito e multisito, per garantire che i listener specifici del sito e multisito vengano eseguiti prima dei listener con caratteri jolly e di base.

La tabella seguente riassume come l'ordine di elaborazione viene determinato in ogni SKU.

Indirizzo IP front-end

Scegliere l'indirizzo IP front-end che si prevede di associare a questo listener. Il listener ascolterà le richieste in ingresso su questo indirizzo IP.

Scegli un indirizzo IP frontend pubblico quando i client raggiungono l'applicazione dietro questo ascoltatore tramite internet. Scegli un indirizzo IP front-end privato per un endpoint interno non esposto a Internet, ad esempio un'applicazione aziendale interna o un livello di un'applicazione multilivello che richiede comunque il bilanciamento del carico, la persistenza della sessione o la terminazione TLS. Per le combinazioni supportate, vedi Configurazione degli indirizzi IP frontend.

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.

La porta 80 è la scelta tipica per un listener HTTP, mentre la porta 443 è la scelta tipica per un listener HTTPS. Usa una porta personalizzata quando la tua applicazione ne richiede una e verifica che il valore rientra nell'intervallo consentito per il tuo SKU, perché l'intervallo supportato differisce tra gli SKU v1 e v2.

Protocollo

Scegli HTTP o HTTPS. Scegli HTTPS quando il traffico tra il client e il gateway applicativo deve essere criptato, il che permette anche al gateway di scaricare la crittografia e la decrittografia, così che i tuoi server backend non siano gravati dall'overhead di calcolo TLS. Scegli HTTP quando quella crittografia non è richiesta per il traffico che questo ascoltatore accetta.

• 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 desidera la crittografia TLS end-to-end per il target di backend, è necessario scegliere anche HTTPS all'interno dell’impostazione HTTP back-end. In questo modo il traffico viene crittografato quando il gateway dell'applicazione avvia una connessione alla destinazione backend.

Per configurare la terminazione TLS, è necessario aggiungere un certificato TLS/SSL al listener. In questo modo il gateway applicazione può decrittografare il traffico in ingresso e crittografare il traffico di risposta al client. Il certificato fornito all'Application Gateway deve essere in formato PFX (Personal Information Exchange), che contiene sia le chiavi private che quelle pubbliche.

Certificati supportati

Vedere Panoramica della terminazione TLS e di TLS end-to-end con il 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 dell'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

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).

Politica 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.

Si configura una policy TLS per gestire le versioni del protocollo TLS. È possibile configurare un gateway applicativo per utilizzare una versione minima del protocollo per eseguire 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 Panoramica dei criteri TLS del gateway applicativo.

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.

Passaggi successivi

• Informazioni sulle regole di routing delle richieste.