Configuratie van Application Gateway-listener

Notitie

Het wordt aanbevolen de Azure Az PowerShell-module te gebruiken om te communiceren met Azure. Zie Azure PowerShell installeren om aan de slag te gaan. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.

Een listener is een logische entiteit die controleert op binnenkomende verbindingsaanvragen met behulp van de poort, het protocol, de host en het IP-adres. Wanneer je de luisteraar configureert, moet je waarden invoeren voor deze instellingen die overeenkomen met de overeenkomstige waarden in het binnenkomende verzoek op de gateway.

Wanneer u een toepassingsgateway maakt met behulp van Azure Portal, maakt u ook een standaardlistener door het protocol en de poort voor de listener te kiezen. U kunt kiezen of u HTTP2-ondersteuning wilt inschakelen voor de listener. Nadat u de toepassingsgateway hebt gemaakt, kunt u de instellingen van die standaardlistener (appGatewayHttpListener) bewerken of nieuwe listeners maken.

Luisteraartype

Wanneer u een nieuwe listener maakt, kiest u tussen basic en meerdere sites. De keuze hangt af van of routering afhangt van de hostnaam in het binnenkomende verzoek.

Routing hangt af van de hostnaam	Luisteraartype	Gedrag
No	Basic	Accepteer en stuur alle verzoeken voor elk domein door naar backendpools. Meer informatie over het maken van een toepassingsgateway met een basislistener.
Yes	Multi-site	Stuur verzoeken door naar verschillende backendpools op basis van de hostheader of hostnamen. Application Gateway maakt gebruik van HTTP 1.1-hostheaders voor het hosten van meer dan één website op hetzelfde openbare IP-adres en dezelfde poort. Om verzoeken op dezelfde poort te onderscheiden, moet je een hostnaam specificeren die overeenkomt met het binnenkomende verzoek.

Voor meer informatie over multi-site listeners, zie het hosten van meerdere sites met Application Gateway.

Volgorde van verwerking van listeners

Voor de v1-SKU worden aanvragen gematcht volgens de volgorde van de regels en het type listener. Als een regel met een basisluisteraar eerst in de volgorde komt, verwerkt deze eerst en accepteert elke aanvraag voor die poort- en IP-combinatie. Om dit gedrag te voorkomen, configureer je de regels eerst met luisteraars met meerdere locaties en schuif je de regel met de basisluisteraar naar de laatste in de lijst.

Voor de v2-SKU definieert de regelprioriteit de volgorde waarin listeners worden verwerkt. Definieer wildcard- en basisluisteraars met een prioriteitsnummer dat hoger is dan site-specifieke en multi-site luisteraars. Deze configuratie zorgt ervoor dat site-specifieke en multi-site listeners worden uitgevoerd vóór de wildcard- en basislisteners.

De volgende tabel vat samen hoe de verwerkingsvolgorde in elke SKU wordt bepaald.

Artikelnummer (SKU)	Wat bepaalt de volgorde	Aanbevolen configuratie
v1	De volgorde van de regels en het type luisteraar. Een regel met een basisluisteraar die eerst in de volgorde komt, wordt als eerste verwerkt en accepteert elk verzoek voor die poort- en IP-combinatie.	Configureer eerst de regels met multisite-listeners en verplaats de regel met de basislistener naar de laatste plaats in de lijst.
v2	Regelprioriteit.	Definieer wildcard- en basislisteners met een prioriteitsnummer dat hoger is dan het nummer dat wordt gebruikt voor sitespecifieke en multisite-listeners, zodat de sitespecifieke en multisite-listeners als eerste worden uitgevoerd.

IP-adres voor front-end

Kies het front-end-IP-adres dat u aan deze listener wilt koppelen. De luisteraar luistert naar binnenkomende verzoeken op deze IP.

Kies een openbaar frontend IP-adres wanneer clients via internet de applicatie achter deze luisteraar bereiken. Kies een privé frontend IP-adres voor een intern eindpunt dat niet aan het internet is blootgesteld, zoals een interne line-of-business-applicatie of een laag van een multitier applicatie die nog steeds belastingverdeling, sessiestickiness of TLS-beëindiging vereist. Voor de ondersteunde combinaties, zie Frontend IP-adresconfiguratie.

Notitie

Application Gateway-front-end ondersteunt IP-adressen met dubbele stack. U kunt maximaal vier front-end-IP-adressen maken: twee IPv4-adressen (openbaar en privé) en twee IPv6-adressen (openbaar en privé).

Frontendpoort

Koppel een front-endpoort. U kunt een bestaande poort selecteren of een nieuwe poort maken. Kies een waarde uit het toegestane bereik van poorten. U kunt niet alleen bekende poorten gebruiken, zoals 80 en 443, maar elke toegestane aangepaste poort die geschikt is. Dezelfde poort kan worden gebruikt voor openbare en privé-listeners.

Port 80 is de typische keuze voor een HTTP-luisteraar, en poort 443 is de typische keuze voor een HTTPS-luisteraar. Gebruik een aangepaste poort wanneer je applicatie die vereist, en bevestig dat de waarde binnen het toegestane bereik van je SKU valt, omdat het ondersteunde bereik verschilt tussen de v1- en v2-SKU's.

Notitie

Wanneer u privé- en openbare listeners met hetzelfde poortnummer gebruikt, wijzigt uw toepassingsgateway de bestemming van de binnenkomende stroom in de front-end-IP's van uw gateway. Afhankelijk van de configuratie van uw netwerkbeveiligingsgroep hebt u mogelijk een binnenkomende regel met doel-IP-adressen nodig als de openbare en persoonlijke front-end-IP-adressen van uw toepassingsgateway.

Regel voor inkomend verkeer:

• Bron: (volgens uw behoeften)
• Doel-IP-adressen: openbare en privé-front-end-IP-adressen van uw toepassingsgateway.
• Doelpoort: (volgens de configuratie van de listener)
• Protocol: TCP

Uitgaande regel: (geen specifieke vereiste)

protocol

Kies tussen HTTP en HTTPS. Kies HTTPS wanneer het verkeer tussen de client en de applicatiegateway versleuteld moet zijn, wat de gateway ook in staat stelt de encryptie- en ontsleutelingswerk af te lasten zodat je backendservers niet belast worden door TLS-berekeningsoverhead. Kies HTTP wanneer die encryptie niet vereist is voor het verkeer dat deze luisteraar accepteert.

• Als u HTTP kiest, wordt het verkeer tussen de client en de toepassingsgateway niet versleuteld.

• Kies HTTPS als u TLS-beëindiging of end-to-end TLS-versleuteling wilt. Het verkeer tussen de client en de toepassingsgateway wordt versleuteld en de TLS-verbinding wordt beëindigd op de toepassingsgateway. Als u end-to-end TLS-versleuteling naar het back-enddoel wilt, moet u ook HTTPS kiezen binnen de back-end-HTTP-instelling . Dit zorgt ervoor dat verkeer wordt versleuteld wanneer application gateway een verbinding met het back-enddoel initieert.

Als u TLS-beëindiging wilt configureren, moet een TLS/SSL-certificaat worden toegevoegd aan de listener. Hierdoor kan application gateway binnenkomend verkeer ontsleutelen en antwoordverkeer naar de client versleutelen. Het certificaat dat aan de Application Gateway wordt verstrekt, moet de PFX-indeling (Personal Information Exchange) hebben, die zowel de persoonlijke als openbare sleutels bevat.

Notitie

Wanneer u een TLS-certificaat van Key Vault gebruikt voor een listener, moet u ervoor zorgen dat uw Application Gateway altijd toegang heeft tot die gekoppelde sleutelkluisresource en het certificaatobject erin. Hiermee kunnen naadloze processen van de functie TLS-beëindiging worden uitgevoerd en blijft de algemene toestand van uw gatewayresource gewaarborgd. Als een application gateway-resource een onjuist geconfigureerde sleutelkluis detecteert, worden de bijbehorende HTTPS-listener(s) automatisch in een uitgeschakelde status geplaatst. Meer informatie.

Ondersteunde certificaten

Zie Overzicht van TLS-beëindiging en end-to-end TLS met Application Gateway.

Aanvullende protocolondersteuning

HTTP/2-ondersteuning

Application Gateway ondersteunt het HTTP/2-protocol voor clients die verbinding maken met application gateway-luisteraars. Communicatie met backend-serverpools gebruikt altijd HTTP/1.1. Http/2-ondersteuning is standaard uitgeschakeld. Het volgende Azure PowerShell-codefragment laat zien hoe je deze ondersteuning kunt inschakelen:

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

$gw.EnableHttp2 = $true

Set-AzApplicationGateway -ApplicationGateway $gw

Belangrijk

Wanneer je een applicatiegateway-resource aanmaakt via het Azure-portaal, wordt de standaardoptie voor HTTP2 ingeschakeld. Je kunt tijdens het aanmaken Uitgeschakeld kiezen en HTTP/2-ondersteuning opnieuw inschakelen door Ingeschakeld te selecteren onder HTTP2 in Application gateway > Configuration in het Azure-portaal.

In gevallen waarin een client HTTP/2 niet ondersteunt, gebruikt de verbinding HTTP/1.1. HTTP/2 inschakelen schakelt HTTP/1.1 niet uit; het ondersteunt beide.

Notitie

Application Gateway ondersteunt alleen HTTP/2 via TLS (HTTPS-listeners). Application Gateway ondersteunt geen HTTP/2 Cleartext (h2c) protocol-upgradepogingen vanuit HTTP/1.1 en geeft een 403 Forbidden foutmelding. Clients die h2c-upgrades proberen, moeten native HTTP/2-verbindingen gebruiken in plaats van HTTPS of op HTTP/1.1 blijven.

HTTP/3 (QUIC) ondersteuning

Belangrijk

HTTP/3-ondersteuning in Azure Application Gateway is momenteel in preview. Tijdens de previewfase kunnen functionaliteit, beschikbaarheid en andere aspecten van deze functie veranderen naar aanleiding van feedback.

Deze preview-versie wordt geleverd zonder service level agreement en wordt niet aanbevolen voor productieworkloads. Bepaalde functies worden mogelijk niet ondersteund of kunnen beperkte mogelijkheden hebben.

Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews voor meer informatie.

Application Gateway ondersteunt HTTP/3 alleen voor clientverbindingen die Basic-luisteraars gebruiken. Een HTTP/3-geschikte luisteraar kan ook HTTP/1.1- of HTTP/2-verkeer van clients accepteren. De communicatie van Application Gateway naar backend-serverpools blijft HTTP/1.1 gebruiken.

HTTP/3-ondersteuning is standaard uitgeschakeld.

Hoe HTTP/3-ondersteuning wordt gepromoot

Application Gateway adverteert HTTP/3-ondersteuning door gebruik te maken van de Alt-Svc HTTP-responsheader. Wanneer je HTTP/3 inschakelt op een luisteraar, bevat Application Gateway de volgende Alt-Svc header in antwoorden.

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

Wanneer je HTTP/3 uitschakelt, bevat Application Gateway de Alt-Svc-header niet.

Clients die HTTP/3 ondersteunen kunnen de geadverteerde dienst gebruiken om een QUIC-verbinding op de luisterpoort op te zetten. Clients die HTTP/3 niet ondersteunen blijven HTTP/2 of HTTP/1.1 gebruiken via TCP.

Ondersteuning voor WebSocket

WebSocket-ondersteuning is standaard ingeschakeld. Er is geen door de gebruiker configureerbare instelling om deze in of uit te schakelen. U kunt WebSockets gebruiken met zowel HTTP- als HTTPS-listeners.

Aangepaste foutenpagina's

Je kunt aangepaste foutpagina's definiëren voor verschillende responscodes die Application Gateway teruggeeft. Je kunt foutpagina's instellen voor de antwoordcodes 400, 403, 405, 408, 500, 502, 503 en 504. Gebruik de configuratie van de foutpagina op globaal niveau of luisteraar-specifiek om ze voor elke luisteraar nauwkeurig in te stellen. Zie voor meer informatie Aangepaste foutpagina's maken voor Application Gateway.

Notitie

Application Gateway geeft een fout door van de backendserver naar de client zonder deze aan te passen.

TLS-beleid

U kunt TLS/SSL-certificaatbeheer centraliseren en de overhead voor versleutelingsontsleuteling voor een back-endserverfarm verminderen. Gecentraliseerde TLS-afhandeling laat je ook een centraal TLS-beleid specificeren dat aansluit bij jouw beveiligingsbehoeften. Je kunt kiezen voor een vooraf gedefinieerd of aangepast TLS-beleid.

Je configureert het TLS-beleid om versies van het TLS-protocol te beheren. Je kunt een applicatiegateway zo instellen dat je een minimumprotocolversie gebruikt voor TLS-handshakes uit TLS 1.0, TLS 1.1, TLS 1.2 en TLS 1.3. SSL 2.0 en 3.0 zijn standaard uitgeschakeld en kunnen niet worden geconfigureerd. Zie overzicht van tls-beleid voor Application Gateway voor meer informatie.

Nadat u een listener hebt gemaakt, koppelt u deze aan een regel voor aanvraagroutering. Die regel bepaalt hoe verzoeken die de luisteraar ontvangt naar de backend worden gestuurd.

Volgende stappen

• Meer informatie over regels voor aanvraagroutering.