Application Gateway-lyssnarkonfiguration

Anmärkning

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. För att lära dig hur du migrerar till Az PowerShell-modulen, se Migrera Azure PowerShell från AzureRM till Az.

En lyssnare är en logisk entitet som söker efter inkommande anslutningsbegäranden med hjälp av port, protokoll, värd och IP-adress. När du konfigurerar lyssnaren måste du ange värden för dessa inställningar som matchar motsvarande värden i den inkommande förfrågan på gatewayen.

När du skapar en programgateway med hjälp av Azure-portalen skapar du också en standardlyssnare genom att välja protokoll och port för lyssnaren. Du kan välja om du vill aktivera HTTP2-stöd för lyssnaren. När du har skapat programgatewayen kan du redigera inställningarna för standardlyssnaren (appGatewayHttpListener) eller skapa nya lyssnare.

Lyssnartyp

När du skapar en ny lyssnare väljer du mellan grundläggande och flera webbplatser. Valet beror på om routing beror på värdnamnet i den inkommande förfrågan.

Routing beror på värdnamnet	Lyssnartyp	Behavior
No	Basic	Acceptera och vidarebefordra alla förfrågningar för vilken domän som helst till backendpooler. Lär dig hur du skapar en programgateway med en grundläggande lyssnare.
Yes	Flera platser	Vidarebefordra förfrågningar till olika backend-pooler baserat på värdhuvudet eller värdnamnen. Application Gateway förlitar sig på HTTP 1.1 värdhuvuden för att ha mer än en webbplats på samma offentliga IP-adress och port. För att särskilja förfrågningar på samma port måste du ange ett värdnamn som matchar den inkommande förfrågan.

Mer information om lyssnare för flera webbplatser finns i hosta flera webbplatser med Application Gateway.

Ordningen för hantering av lyssnare

För V1 SKU matchas begäranden enligt reglernas ordning och typ av lyssnare. Om en regel med en grundläggande lyssnare kommer först i ordningen, behandlar den först och accepterar alla förfrågningar om den port- och IP-kombinationen. För att undvika detta beteende konfigurera först reglerna med lyssnare för flera platser och placera regeln med den grundläggande lyssnaren sist i listan.

För V2 SKU definierar regelprioritet i vilken ordning lyssnare bearbetas. Definiera wildcard- och basic-lyssnare med ett prioritetsnummer högre än platsspecifika och multi-site lyssnare. Denna konfiguration säkerställer att platsspecifika och multi-site lyssnare kör före wildcard och basic lyssnare.

Följande tabell sammanfattar hur bearbetningsordningen bestäms i varje SKU.

artikelnummer (SKU)	Vad bestämmer ordningen	Rekommenderad konfiguration
v1	Ordningen på reglerna och typen av lyssnare. En regel med en grundläggande lyssnare som kommer först i ordningen processas först och accepterar alla förfrågningar om den port- och IP-kombinationen.	Konfigurera reglerna med lyssnare för flera platser först och flytta regeln med baslyssnaren till den sista positionen i listan.
v2	Regelprioritet.	Definiera joker- och grundlyssnare med ett prioritetsnummer högre än det som används för platsspecifika och flerplatslyssnare, så att platsspecifika och flerplatslyssnare kör först.

Klientdelens IP-adress

Välj den IP-adress för klientdelen som du planerar att associera med den här lyssnaren. Lyssnaren lyssnar på inkommande förfrågningar på denna IP.

Välj en publik frontend-IP-adress när klienterna når applikationen bakom denna lyssnare via internet. Välj en privat frontend-IP-adress för en intern endpoint som inte är exponerad mot internet, såsom en intern affärsapplikation eller ett lager av en flernivåapplikation som fortfarande kräver lastfördelning, sessionsstickiness eller TLS-terminering. För de stödda kombinationerna, se Frontend IP-adresskonfiguration.

Anmärkning

Application Gateway-klientdelen stöder IP-adresser med dubbla staplar. Du kan skapa upp till fyra IP-adresser för klientdelen: två IPv4-adresser (offentliga och privata) och två IPv6-adresser (offentliga och privata).

frontend-port

Associera en frontport. Du kan välja en befintlig port eller skapa en ny. Välj valfritt värde från det tillåtna portintervallet. Du kan inte bara använda välkända portar, till exempel 80 och 443, utan även alla tillåtna anpassade portar som är lämpliga. Samma port kan användas för offentliga och privata lyssnare.

Port 80 är det typiska valet för en HTTP-lyssnare, och port 443 är det typiska valet för en HTTPS-lyssnare. Använd en anpassad port när din applikation kräver en, och bekräfta att värdet ligger inom det tillåtna intervallet för din SKU, eftersom det stödda intervallet skiljer sig mellan v1- och v2-SKU:erna.

Anmärkning

När du använder privata och offentliga lyssnare med samma portnummer ändrar programgatewayen "målet" för det inkommande flödet till gatewayens klientdels-IP-adresser. Beroende på nätverkssäkerhetsgruppens konfiguration kan du därför behöva en inkommande regel med mål-IP-adresser som programgatewayens offentliga och privata klientdels-IP-adresser.

Inkommande regel:

• Källa: (enligt dina behov)
• Mål-IP-adresser: Offentliga och privata klientdels-IP-adresser för din programgateway.
• Målport: (enligt lyssnarkonfiguration)
• Protokoll: TCP

Utgående regel: (inget specifikt krav)

Protokoll

Välj HTTP eller HTTPS. Välj HTTPS när trafiken mellan klienten och applikationsgatewayen måste krypteras, vilket också låter gatewayen avlasta krypterings- och dekrypteringsarbetet så att dina backend-servrar inte belastas av TLS-beräkningsöverhead. Välj HTTP när den krypteringen inte krävs för trafiken som denna lyssnare accepterar.

• Om du väljer HTTP är trafiken mellan klienten och programgatewayen okrypterad.

• Välj HTTPS om du vill ha TLS-avslutning eller TLS-kryptering från slutpunkt till slutpunkt. Trafiken mellan klienten och programgatewayen krypteras och TLS-anslutningen avslutas vid programgatewayen. Om du vill ha fullständig TLS-kryptering till bakändemålet, måste du även välja HTTPS i bakändeinställningen för HTTP. Detta säkerställer att trafiken krypteras när application gateway initierar en anslutning till serverdelsmålet.

För att konfigurera TLS-avslutning måste ett TLS/SSL-certifikat läggas till i lyssnaren. På så sätt kan Application Gateway dekryptera inkommande trafik och kryptera svarstrafik till klienten. Certifikatet som tillhandahålls till Application Gateway måste vara i PFX-format (Personal Information Exchange), som innehåller både privata och offentliga nycklar.

Anmärkning

När du använder ett TLS-certifikat från Key Vault för en lyssnare måste du se till att Application Gateway alltid har åtkomst till den länkade nyckelvalvsresursen och certifikatobjektet i den. Detta möjliggör sömlösa åtgärder för TLS-avslutningsfunktionen och upprätthåller den övergripande hälsan för din gatewayresurs. Om en application gateway-resurs identifierar ett felkonfigurerat nyckelvalv placeras automatiskt de associerade HTTPS-lyssnarna i ett inaktiverat tillstånd. Läs mer.

Certifikat som stöds

Se Översikt över TLS-avslutning och end-to-end-TLS med applikationsgateway.

Ytterligare protokollstöd

HTTP/2-stöd

Application Gateway stöder HTTP/2-protokollet för klienter som ansluter till applikationsgateway-lyssnare. Kommunikationen till backend-serverpooler använder alltid HTTP/1.1. Som standard är HTTP/2-stöd inaktiverat. Följande Azure PowerShell-kodutdrag visar hur man aktiverar detta stöd:

$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm

$gw.EnableHttp2 = $true

Set-AzApplicationGateway -ApplicationGateway $gw

Viktigt!

När du skapar en applikationsgateway-resurs via Azure-portalen är standardalternativet för HTTP2 aktiverat. Du kan välja Inaktiverat under skapandet och återaktivera HTTP/2-stöd genom att välja Aktiverat under HTTP2 i applikationsgatewaykonfiguration > i Azure-portalen.

I fall där en klient inte stödjer HTTP/2 använder anslutningen HTTP/1.1. Att aktivera HTTP/2 inaktiverar inte HTTP/1.1; det tillåter stöd för båda.

Anmärkning

Application Gateway stöder endast HTTP/2 via TLS (HTTPS-lyssnare). Application Gateway stöder inte HTTP/2 Cleartext (h2c)-protokolluppgraderingsförsök från HTTP/1.1 och returnerar ett 403 Förbud-fel. Klienter som försöker uppgradera h2c bör använda inbyggda HTTP/2-anslutningar över HTTPS eller förbli på HTTP/1.1.

HTTP/3 (QUIC)-stöd

Viktigt!

HTTP/3-stöd i Azure Application Gateway är för närvarande i förhandsvisning. I förhandsversion kan funktioner, tillgänglighet och andra aspekter av den här funktionen ändras som svar på feedback.

Den här förhandsversionen tillhandahålls utan ett serviceavtal och rekommenderas inte för produktionsarbetsbelastningar. Vissa funktioner kanske inte stöds eller kan ha begränsade funktioner.

Mer information finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.

Application Gateway stöder endast HTTP/3 för klientanslutningar som använder Basic-lyssnare. En HTTP/3-aktiverad lyssnare kan också acceptera HTTP/1.1- eller HTTP/2-trafik från klienter. Kommunikationen från Application Gateway till backend-serverpooler fortsätter att använda HTTP/1.1.

HTTP/3-stöd är inaktiverat som standard.

Hur HTTP/3-stöd marknadsförs

Application Gateway annonserar stöd för HTTP/3 genom att använda HTTP-svarshuvudet Alt-Svc. När du aktiverar HTTP/3 på en lyssnare inkluderar Application Gateway följande Alt-Svc header i svaren.

Alt-Svc: h3=":<listener-port>"; ma=86400

När du inaktiverar HTTP/3 inkluderar inte Application Gateway Alt-Svc headern.

Klienter som stödjer HTTP/3 kan använda den annonserade tjänsten för att etablera en QUIC-anslutning på lyssnarporten. Klienter som inte stödjer HTTP/3 fortsätter att använda HTTP/2 eller HTTP/1.1 över TCP.

WebSocket-stöd

WebSocket-stöd är aktiverat som standard. Det finns ingen inställning som kan konfigureras av användaren för att aktivera eller inaktivera den. Du kan använda WebSockets med både HTTP- och HTTPS-lyssnare.

Anpassade felsidor

Du kan definiera anpassade felsidor för olika svarskoder som Application Gateway returnerar. Du kan konfigurera felsidor för svarskoder 400, 403, 405, 408, 500, 502, 503 och 504. Använd global eller lyssnarspecifik konfiguration av felsidor för att konfigurera dem separat för varje lyssnare. Mer information finns i Skapa anpassade felsidor för Application Gateway.

Anmärkning

Application Gateway skickar ett fel från backend-servern till klienten utan att ändra det.

TLS-policy

Du kan centralisera TLS/SSL-certifikathantering och minska kostnaderna för krypteringsdekryptering för en servergrupp på serverdelen. Centraliserad TLS-hantering låter dig också specificera en central TLS-policy som passar dina säkerhetsbehov. Du kan välja en fördefinierad eller anpassad TLS-policy.

Du konfigurerar TLS-policyn för att styra versioner av TLS-protokollet. Du kan konfigurera en applikationsgateway att använda en minimiprotokollversion för TLS-handshakes från TLS 1.0, TLS 1.1, TLS 1.2 och TLS 1.3. Som standard är SSL 2.0 och 3.0 inaktiverade och kan inte konfigureras. Mer information finns i Översikt över TLS-princip för Application Gateway.

När du har skapat en lyssnare associerar du den med en regel för begärandedirigering. Den regeln bestämmer hur förfrågningar som lyssnaren tar emot dirigeras till backend.

Nästa steg

• Läs mer om routningsregler för begäranden.