Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
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 som matchar motsvarande värden i den inkommande begäran 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 grundläggande lyssnare kommer först i ordningen bearbetas den först och accepterar alla begäranden för den port- och IP-kombinationen. För att undvika detta konfigurerar du först reglerna med lyssnare för flera webbplatser och genomför regeln med den grundläggande lyssnaren som den sista i listan.
För V2 SKU definierar regelprioritet i vilken ordning lyssnare bearbetas. Jokertecken och grundläggande lyssnare bör definieras som en prioritet med ett tal som är större än platsspecifika lyssnare och lyssnare med flera webbplatser, för att säkerställa att platsspecifika lyssnare och lyssnare med flera platser körs före jokertecken och grundläggande 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 begäranden på den här IP-adressen.
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-terminering och end-to-end TLS med Application Gateway
Ytterligare protokollstöd
HTTP2-stöd
HTTP/2-protokollstöd är endast tillgängligt för klienter som ansluter till application gateway-lyssnare. Kommunikation till backend-serverpooler är alltid HTTP/1.1. Som standard är HTTP/2-stöd inaktiverat. Följande Kodfragment i Azure PowerShell visar hur du aktiverar detta:
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
Viktigt!
När du skapar en programgatewayresurs via Azure-portalen anges standardalternativet för HTTP2 som aktiverat. Du kan välja Inaktiverad när du skapar och återaktivera HTTP2-stöd med hjälp av Azure-portalen genom att välja Aktiverad under HTTP2 i Konfiguration av programgateway>.
I fall där HTTP2 inte stöds av en klient används HTTP1.1. Om du aktiverar HTTP2 inaktiveras inte HTTP1.1. det ger stöd för båda.
Anmärkning
Application Gateway stöder endast HTTP/2 via TLS (HTTPS-lyssnare). HTTP/2 Cleartext-protokolluppgraderingsförsök (h2c) från HTTP/1.1 stöds inte och resulterar i ett fel med 403 Förbjuden. Klienter som försöker uppgradera h2c ska använda interna HTTP/2-anslutningar via HTTPS eller vara kvar på HTTP/1.1.
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 returneras av Application Gateway. Svarskoderna som du kan konfigurera felsidor för är 400, 403, 405, 408, 500, 502, 503 och 504. Du kan använda konfiguration på global nivå eller lyssnarspecifik felsida för att ange dem detaljerat för varje lyssnare. Mer information finns i Skapa anpassade felsidor för Application Gateway.
Anmärkning
Ett fel som kommer från bakre servern skickas oförändrat av Application Gateway till klienten.
TLS-policy
Du kan centralisera TLS/SSL-certifikathantering och minska kostnaderna för krypteringsdekryptering för en servergrupp på serverdelen. Med centraliserad TLS-hantering kan du också ange en central TLS-princip som passar dina säkerhetskrav. Du kan välja fördefinierad eller anpassad TLS-princip.
Du konfigurerar TLS-principen för att kontrollera TLS-protokollversioner. Du kan konfigurera en programgateway för att använda en lägsta protokollversion för TLS-handskakningar från TLS1.0, TLS1.1, TLS1.2 och TLS1.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 avgör hur begäranden som tas emot på lyssnaren dirigeras till serverdelen.