Veelgestelde vragen over Application Gateway

Azure-toepassing Gateway biedt een controller voor toepassingslevering als een service. Het biedt verschillende mogelijkheden voor taakverdeling op laag 7 voor uw toepassingen. Deze service is maximaal beschikbaar, schaalbaar en volledig beheerd door Azure.

Application Gateway biedt ondersteuning voor automatisch schalen, TLS-offloading en end-to-end TLS, een web application firewall (WAF), sessieaffiniteit op basis van cookies, routering op basis van URL-pad, hosting voor meerdere sites en andere functies. Zie Inleiding tot Application Gateway voor een volledige lijst met ondersteunde functies.

Application Gateway is een load balancer van laag 7, wat betekent dat deze alleen werkt met webverkeer (HTTP, HTTPS, WebSocket en HTTP/2). Het biedt ondersteuning voor mogelijkheden zoals TLS-beëindiging, sessieaffiniteit op basis van cookies en round robin voor taakverdelingsverkeer. Load Balancer verdeelt verkeer op laag 4 (TCP of UDP).

Application Gateway ondersteunt HTTP, HTTPS, HTTP/2 en WebSocket.

Zie http/2-ondersteuning.

Zie Ondersteunde back-endbronnen.

Application Gateway v1 (Standard en WAF) is beschikbaar in alle regio's van wereldwijde Azure. Het is ook beschikbaar in Microsoft Azure beheerd door 21Vianet en Azure Government.

Zie Ondersteunde regio's voor Application Gateway v2 (Standard_v2 en WAF_v2) voor beschikbaarheid van Application Gateway v2.

Application Gateway is een toegewezen implementatie in uw virtuele netwerk.

Omleiding wordt ondersteund. Zie overzicht van omleiding van Application Gateway.

Bekijk de volgorde van de verwerking van de listener.

Als u een openbaar IP-adres als eindpunt gebruikt, vindt u de IP- en DNS-gegevens op de openbare IP-adresresource. U kunt deze ook vinden in Azure Portal, op de overzichtspagina voor de toepassingsgateway. Als u interne IP-adressen gebruikt, zoekt u de informatie op de overzichtspagina. Voor de v1-SKU hebben gateways die na 1 mei 2023 zijn gemaakt, geen standaard-DNS-naam die automatisch is gekoppeld aan de openbare IP-resource. Open voor de v2-SKU de openbare IP-resource en selecteer Configuratie. Het veld DNS-naamlabel (optioneel) is beschikbaar om de DNS-naam te configureren.

Keep-Alive Time-out bepaalt hoe lang de toepassingsgateway wacht tot een client een andere HTTP-aanvraag verzendt op een permanente verbinding voordat deze opnieuw wordt gebruikt of wordt gesloten. De time-out voor inactiviteit van TCP bepaalt hoelang een TCP-verbinding open blijft als er geen activiteit is.

De Keep-Alive time-out in de Application Gateway v1 SKU is 120 seconden en in de v2-SKU is dit 75 seconden. Voor privé-IP-adressen is de waarde niet geconfigureerd met een time-out voor tcp-inactiviteit van 5 minuten. De time-out voor inactiviteit van TCP is een standaardwaarde van 4 minuten op het virtuele IP-adres (VIP) van zowel v1 als v2 van Application Gateway. U kunt de time-outwaarde voor TCP-inactiviteit op v1- en v2 Application Gateway-exemplaren zo configureren dat deze zich tussen 4 minuten en 30 minuten bevinden. Voor zowel v1- als v2 Application Gateway-exemplaren moet u naar het openbare IP-adres van de toepassingsgateway gaan en de time-out voor tcp-inactiviteit wijzigen in het deelvenster Configuratie van het openbare IP-adres in de portal. U kunt de time-outwaarde voor TCP-inactiviteit van het openbare IP-adres via PowerShell instellen door de volgende opdrachten uit te voeren:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Voor HTTP/2-verbindingen met het front-end-IP-adres op application gateway v2 SKU is de time-out voor inactiviteit ingesteld op 180 seconden en is deze niet geconfigureerd.

Ja. Application Gateway hergebruikt de bestaande TCP-verbindingen met een back-endserver.

Nee U kunt de naam van een Application Gateway-resource niet wijzigen. U moet een nieuwe resource met een andere naam maken.

Nee Er is geen manier om een Application Gateway-resource of het bijbehorende openbare IP-adres te herstellen na verwijdering. U moet een nieuwe resource maken.

In Application Gateway v1 SKU kan het VIP wijzigen als u de toepassingsgateway stopt en start. Maar de DNS-naam die aan de toepassingsgateway is gekoppeld, verandert niet gedurende de levensduur van de gateway. Omdat de DNS-naam niet wordt gewijzigd, moet u een CNAME-alias gebruiken en deze verwijzen naar het DNS-adres van de toepassingsgateway. Ip-adressen in Application Gateway v2 SKU zijn statisch, dus het IP-adres en de DNS-naam worden niet gewijzigd gedurende de levensduur van de toepassingsgateway.

Ja. De Application Gateway v2-SKU ondersteunt statische openbare IP-adressen en statische interne IP-adressen. De v1-SKU ondersteunt statische interne IP-adressen.

Een toepassingsgateway ondersteunt slechts één openbaar IP-adres per IP-protocol. Als de toepassingsgateway is geconfigureerd als DualStack, kan deze twee openbare IP-adressen ondersteunen, één voor IPv4 en één voor IPv6.

Zie overwegingen voor de grootte van het Toepassingsgateway-subnet.

Ja. Naast meerdere exemplaren van een bepaalde Application Gateway-implementatie kunt u een andere unieke Application Gateway-resource inrichten voor een bestaand subnet dat een andere Application Gateway-resource bevat.

Eén subnet biedt geen ondersteuning voor zowel v2- als v1 Application Gateway-SKU's.

Ja, maar alleen specifieke scenario's. Zie De configuratie van de infrastructuur van Application Gateway voor meer informatie.

Ja. Zie Wijzigingen in een aanvraag.

Het kan tot 20 minuten duren voordat nieuwe SKU-implementaties van Application Gateway v1 zijn ingericht. Wijzigingen in de instantiegrootte of het aantal zijn niet storend en de gateway blijft gedurende deze tijd actief.

Het inrichten van de meeste implementaties die gebruikmaken van de v2-SKU duurt ongeveer 6 minuten. Het proces kan echter langer duren, afhankelijk van het type implementatie. Implementaties in meerdere beschikbaarheidszones met veel exemplaren kunnen bijvoorbeeld langer dan 6 minuten duren.

Updates die zijn geïnitieerd voor Application Gateway, worden één updatedomein tegelijk toegepast. Wanneer de exemplaren van elk updatedomein worden bijgewerkt, blijven de resterende exemplaren in andere updatedomeinen verkeer¹ bedienen. Actieve verbindingen worden gedurende maximaal vijf minuten bijgewerkt van de exemplaren om verbinding te maken met exemplaren in een ander updatedomein voordat de update begint. Tijdens de update wordt Application Gateway tijdelijk uitgevoerd met een verminderde maximale capaciteit. Dit wordt bepaald door het aantal geconfigureerde exemplaren. Het updateproces wordt alleen uitgevoerd naar de volgende set exemplaren als de huidige set exemplaren is bijgewerkt.

¹ We raden een minimumaantal exemplaren van 2 aan dat moet worden geconfigureerd voor Application Gateway v1 SKU-implementaties om ervoor te zorgen dat ten minste één exemplaar verkeer kan verwerken terwijl updates worden toegepast.

Application Gateway ondersteunt tls/TCP-protocolproxy via de Layer 4-proxy in preview.

De Layer 7-proxy van Application Gateway met HTTP(S)-protocollen biedt geen ondersteuning voor e-mailprotocollen zoals SMTP, IMAP en POP3. Voor sommige ondersteunende e-mailservices, zoals Outlook Web Access (OWA), ActiveSync- en AutoDiscovery-verkeer dat gebruikmaakt van HTTP(S)-protocollen, kunt u echter laag 7-proxy gebruiken en het verkeer moet stromen. (Opmerking: uitsluitingen in de WAF-regels zijn mogelijk vereist wanneer u een WAF-SKU gebruikt).

Ja. Zie Migreren Azure-toepassing Gateway en Web Application Firewall van v1 naar v2 voor meer informatie.

Ja. De Application Gateway v1-SKU wordt nog steeds ondersteund. We raden u ten zeerste aan om over te stappen op v2 om te profiteren van de functie-updates in die SKU. Zie Automatisch schalen en zone-redundante Application Gateway v2 voor meer informatie over de verschillen tussen v1- en v2-functies. U kunt Application Gateway v1 SKU-implementaties handmatig migreren naar v2 door het migratiedocument v1-v2 te volgen.

Nee Application Gateway v2 biedt geen ondersteuning voor proxyaanvragen met NTLM- of Kerberos-verificatie.

Namen van aanvraagheaders kunnen alfanumerieke tekens en afbreekstreepjes bevatten. Namen van aanvraagheaders die andere tekens bevatten, worden verwijderd wanneer een aanvraag naar het back-enddoel wordt verzonden. Namen van antwoordheaders kunnen alfanumerieke tekens en specifieke symbolen bevatten, zoals gedefinieerd in RFC 7230.

Ja. De Chromium browserv80-update heeft een mandaat geïntroduceerd voor HTTP-cookies zonder dat het kenmerk SameSite moet worden behandeld als SameSite=Lax. Dit betekent dat de affiniteitscookie van Application Gateway niet wordt verzonden door de browser in een context van derden.

Ter ondersteuning van dit scenario injecteert Application Gateway een andere cookie die naast de bestaande ApplicationGatewayAffinity cookie wordt aangeroepenApplicationGatewayAffinityCORS. Deze cookies zijn vergelijkbaar, maar de ApplicationGatewayAffinityCORS cookie heeft nog twee kenmerken toegevoegd: SameSite=None en Secure. Deze kenmerken onderhouden plaksessies, zelfs voor cross-origin-aanvragen. Zie de sectie Affiniteit op basis van cookies voor meer informatie.

Een actieve listener is een listener die is gekoppeld aan een regel en verkeer naar een back-endpool verzendt. Een listener die alleen verkeer omleidt, is geen actieve listener. Listeners die zijn gekoppeld aan omleidingsregels, worden niet als actief beschouwd. Als de omleidingsregel een padgebaseerde regel is, moeten alle paden in die omleidingsregel verkeer omleiden, anders wordt de listener als actief beschouwd. Zie limieten, quota en beperkingen voor Azure-abonnementen en -services voor afzonderlijke onderdelen.

De Application Gateway v1-SKU ondersteunt scenario's met hoge beschikbaarheid wanneer u twee of meer exemplaren hebt geïmplementeerd. Azure distribueert deze exemplaren over update- en foutdomeinen om ervoor te zorgen dat exemplaren niet allemaal tegelijkertijd mislukken. De v1-SKU ondersteunt schaalbaarheid door meerdere exemplaren van dezelfde gateway toe te voegen om de belasting te delen.

De v2-SKU zorgt er automatisch voor dat nieuwe exemplaren worden verdeeld over foutdomeinen en updatedomeinen. Als u zoneredundantie kiest, worden de nieuwste exemplaren ook verspreid over beschikbaarheidszones om zonegebonden fouttolerantie te bieden.

Gebruik Azure Traffic Manager om verkeer te distribueren over meerdere toepassingsgateways in verschillende datacenters.

Ja. U kunt het leegmaken van verbindingen instellen om leden in een back-endpool te wijzigen zonder onderbreking. Zie de sectie Verbinding maken ion-afvoer van Application Gateway voor meer informatie.

Ja, de Application Gateway v2-SKU ondersteunt automatisch schalen. Zie Automatisch schalen en zone-redundante Application Gateway voor meer informatie.

Nee Exemplaren worden verdeeld over upgradedomeinen en foutdomeinen.

Ja.

Ja.

Ja. Application Gateway wordt altijd geïmplementeerd in een subnet van een virtueel netwerk. Dit subnet kan alleen toepassingsgateways bevatten. Zie Vereisten voor virtueel netwerk en subnet voor meer informatie.

Als u IP-connectiviteit hebt, kan Application Gateway communiceren met exemplaren buiten het virtuele netwerk waarin deze zich bevindt. Application Gateway kan ook communiceren met exemplaren buiten het abonnement waarin deze zich bevindt. Als u van plan bent om interne IP-adressen te gebruiken als leden van de back-endpool, gebruikt u peering van virtuele netwerken of Azure VPN Gateway.

Net als elke DNS-resolver wordt de TTL-waarde (Time to Live) van de DNS-record van de back-endserver door de Application Gateway-resource toegepast. Nadat de TTL is verlopen, voert de gateway een zoekopdracht uit om die DNS-gegevens bij te werken. Als uw toepassingsgateway tijdens deze zoekopdracht een probleem ondervindt bij het ophalen van een antwoord (of er geen DNS-record wordt gevonden), blijft de gateway de laatst bekende goede DNS-waarde gebruiken om het verkeer te verwerken. Zie Hoe een toepassingsgateway werkt voor meer informatie.

De exemplaren van uw toepassingsgateway gebruiken de DNS-configuratie van het virtuele netwerk voor naamomzetting. Nadat u een DNS-serverconfiguratie hebt gewijzigd, moet u de toepassingsgateway opnieuw starten (stoppen en starten) voor de nieuwe DNS-servers om toegewezen te worden. Tot die tijd kunnen op FQDN gebaseerde naamresoluties voor uitgaande connectiviteit mislukken.

Nee Maar u kunt andere toepassingsgateways implementeren in het subnet.

U kunt een toepassingsgateway alleen verplaatsen tussen subnetten binnen hetzelfde virtuele netwerk. Het wordt ondersteund met v1 met een openbare en persoonlijke front-end (dynamische toewijzing) en v2 met alleen een openbare front-end. De toepassingsgateway kan niet naar een ander subnet worden verplaatst als de privé-front-end-IP-configuratie statisch is toegewezen. De toepassingsgateway moet de status Gestopt hebben om deze actie uit te voeren. Als u v1 stopt of start, wordt het openbare IP-adres gewijzigd. Deze bewerking kan alleen worden uitgevoerd met behulp van Azure PowerShell en de Azure CLI door de volgende opdrachten uit te voeren:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Zie Set-AzApplicationGatewayIPConfiguration voor meer informatie.

Azure-CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Zie Netwerkbeveiligingsgroepen in het Application Gateway-subnet.

Zie door de gebruiker gedefinieerde routes die worden ondersteund in het Application Gateway-subnet.

Nee Beleidsregels voor service-eindpunten voor opslagaccounts worden niet ondersteund in het Application Gateway-subnet en het configureren ervan blokkeert het verkeer van de Azure-infrastructuur.

Zie Application Gateway-limieten.

Ja. Application Gateway ondersteunt één intern IP-adres en één extern IP-adres per toepassingsgateway.

Ja. Peering van virtuele netwerken helpt bij het verdelen van verkeer in andere virtuele netwerken.

Ja, zolang verkeer is toegestaan.

Microservicearchitectuur wordt ondersteund. Als u wilt testen op verschillende poorten, moet u meerdere back-endinstellingen configureren.

Nee

Zie De volgorde van verwerkingsregels.

Het veld Host geeft de naam op waarnaar de test moet worden verzonden wanneer u meerdere sites op Application Gateway hebt geconfigureerd. Gebruik anders 127.0.0.1. Deze waarde verschilt van de hostnaam van de virtuele machine. De indeling is <protocol>://<host>:<port><path>.

Ja. Zie Toegang tot specifieke bron-IP-adressen beperken.

Ja, u kunt openbare en privé-listeners met hetzelfde poortnummer gebruiken om openbare en persoonlijke clients tegelijkertijd te ondersteunen. Als een netwerkbeveiligingsgroep (NSG) is gekoppeld aan het subnet van uw toepassingsgateway, is mogelijk een specifieke regel voor inkomend verkeer nodig, afhankelijk van de configuratie. Meer informatie

Application Gateway v2 ondersteunt IPv4- en IPv6-front-ends. Momenteel is IPv6-ondersteuning alleen beschikbaar voor nieuwe toepassingsgateways. Ter ondersteuning van IPv6 moet het virtuele netwerk dubbele stack zijn. Application Gateway v1 biedt geen ondersteuning voor virtuele netwerken met dubbele stack.

Application Gateway v1-SKU's kunnen worden uitgevoerd in een door FIPS 140-2 goedgekeurde bewerkingsmodus, ook wel 'FIPS-modus' genoemd. De FIPS-modus roept een door FIPS 140-2 gevalideerde cryptografische module aan die ervoor zorgt dat FIPS-compatibele algoritmen voor versleuteling, hashing en ondertekening worden ingeschakeld. Om ervoor te zorgen dat de FIPS-modus is ingeschakeld, moet de FIPSMode instelling worden geconfigureerd via PowerShell, Azure Resource Manager-sjabloon of REST API nadat het abonnement is ingeschreven om de configuratie van FIPSmode.

Application Gateway v2 ondersteunt momenteel alleen een privé-IP-front-endconfiguratie (geen openbaar IP) via openbare preview. Zie De implementatie van Private Application Gateway (preview) voor meer informatie.

Voor de huidige ondersteuning voor algemene beschikbaarheid ondersteunt Application Gateway v2 de volgende combinaties:

• Privé-IP en openbaar IP-adres
• Alleen openbaar IP-adres

Volg dit proces om verkeer alleen te beperken tot privé-IP-adressen met de huidige functionaliteit:

1. Maak een toepassingsgateway met zowel een openbaar als een privé-front-end-IP-adres.

2. Maak geen listeners voor het openbare front-end-IP-adres. Application Gateway luistert niet naar verkeer op het openbare IP-adres als er geen listeners voor worden gemaakt.

3. Maak en koppel een netwerkbeveiligingsgroep voor het Application Gateway-subnet met de volgende configuratie in de volgorde van prioriteit:

   1. Sta verkeer van bron toe als de servicetag GatewayManager, Bestemming als Any en de doelpoortals 65200-65535. Dit poortbereik is nodig voor communicatie met de Azure-infrastructuur. Deze poorten worden beveiligd (vergrendeld) door certificaatverificatie. Externe entiteiten, waaronder de beheerders van de gatewaygebruikers, kunnen geen wijzigingen initiëren op die eindpunten zonder de juiste certificaten.

   2. Sta verkeer van Bron toe als de servicetag AzureLoadBalancer en de doelpoort als Any.

   3. Al het binnenkomende verkeer van bron weigeren als de servicetag Internet en de doelpoort als Any. Geef deze regel de minste prioriteit in de regels voor inkomend verkeer.

   4. Behoud de standaardregels, zoals AllowVNetInBound , zodat de toegang op een privé-IP-adres niet wordt geblokkeerd.

   5. Uitgaande internetverbinding kan niet worden geblokkeerd. Anders ondervindt u problemen met logboekregistratie en metrische gegevens.

Voorbeeld van NSG-configuratie voor alleen-privé-IP-toegang:

U kunt Azure PowerShell of de Azure CLI gebruiken om Application Gateway te stoppen en te starten. Wanneer u Application Gateway stopt en start, wordt de facturering ook gestopt en gestart. Elke PUT-bewerking die wordt uitgevoerd op een gestopte toepassingsgateway (zoals het toevoegen van tag, statustest of listener) activeert een start. U wordt aangeraden de toepassingsgateway te stoppen nadat de configuratie is bijgewerkt.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Application Gateway ondersteunt zelfondertekende certificaten, ca-certificaten (certificeringsinstantie), EV-certificaten (Extended Validation), SAN-certificaten (multi-domain) en jokertekencertificaten.

Application Gateway ondersteunt de volgende coderingssuites:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Zie TLS-beleidsversies en coderingssuites configureren in Application Gateway voor meer informatie over het aanpassen van TLS-opties.

Ja. Application Gateway ondersteunt TLS-offload en end-to-end TLS, waarmee verkeer naar de back-end opnieuw wordt versleuteld.

Ja. U kunt Application Gateway configureren om TLS1.0, TLS1.1 en TLS1.2 te weigeren. SSL 2.0 en 3.0 zijn standaard al uitgeschakeld en kunnen niet worden geconfigureerd.

Ja. In Application Gateway kunt u coderingssuites configureren. Als u een aangepast beleid wilt definiëren, schakelt u ten minste een van de volgende coderingssuites in:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway maakt gebruik van SHA256 voor back-endbeheer.

Application Gateway ondersteunt maximaal 100 TLS/SSL-certificaten.

Ja, Application Gateway ondersteunt certificaten met OCSP-extensies en OCSP-koppeling voor servercertificaten.

Application Gateway ondersteunt maximaal 100 verificatiecertificaten.

Ja, de Application Gateway v2-SKU ondersteunt Key Vault. Zie TLS-beëindiging met Key Vault-certificaten voor meer informatie.

Voor routering op basis van meerdere domeinen (host) kunt u listeners voor meerdere locaties maken, listeners instellen die HTTPS als protocol gebruiken en de listeners koppelen aan de routeringsregels. Zie Hosten van meerdere sites met Application Gateway voor meer informatie.

Nee Gebruik alleen alfanumerieke tekens in het PFX-bestandswachtwoord.

CA/Browser-leden hebben onlangs rapporten gepubliceerd met informatie over meerdere certificaten die zijn uitgegeven door CA-leveranciers die worden gebruikt door onze klanten, Microsoft en de grotere technologiecommunity die niet voldoen aan de industriestandaarden voor openbaar vertrouwde CA's. De rapporten met betrekking tot de niet-compatibele CA's vindt u hier:

• Bug 1649951
• Bug 1650910

Volgens de nalevingsvereisten van de branche zijn CA-leveranciers begonnen met het intrekken van niet-compatibele CA's en het uitgeven van compatibele CA's, waarvoor klanten hun certificaten opnieuw moeten laten uitgeven. Microsoft werkt nauw samen met deze leveranciers om de mogelijke impact op Azure-services te minimaliseren. Uw zelf-uitgegeven certificaten of certificaten die worden gebruikt in BYOC-scenario's (Bring Your Own Certificate) lopen echter nog steeds het risico onverwacht in te trekken.

Als u wilt controleren of certificaten die door uw toepassing worden gebruikt, zijn ingetrokken, raadpleegt u de aankondiging van DigiCert en de certificaatintrekkingstracker. Als uw certificaten zijn ingetrokken of ingetrokken, moet u nieuwe certificaten aanvragen bij de CA-leverancier die in uw toepassingen wordt gebruikt. Als u wilt voorkomen dat de beschikbaarheid van uw toepassing wordt onderbroken omdat certificaten onverwacht worden ingetrokken of als u een certificaat wilt bijwerken dat is ingetrokken, raadpleegt u Intrekking van niet-compatibele certificeringsinstanties die mogelijk van invloed zijn op de Azure-services van de klant.

Voor informatie die specifiek is voor Application Gateway:

Als u een certificaat gebruikt dat is uitgegeven door een van de ingetrokken ICA's, wordt de beschikbaarheid van uw toepassing mogelijk onderbroken. Afhankelijk van uw toepassing ontvangt u mogelijk verschillende foutberichten, waaronder maar niet beperkt tot:

• Ongeldig certificaat/ingetrokken certificaat
• Time-out opgetreden voor verbinding
• HTTP 502

Als u wilt voorkomen dat uw toepassing wordt onderbroken vanwege dit probleem of als u een CA die is ingetrokken opnieuw wilt uitgeven, moet u de volgende acties uitvoeren:

1. Neem contact op met uw certificaatprovider voor het opnieuw uitgeven van uw certificaten.
2. Nadat ze opnieuw zijn uitgegeven, werkt u uw certificaten op de Application Gateway/WAF bij met de volledige vertrouwensketen (leaf, tussenliggend en basiscertificaat). Volg de stappen hier om de certificaten bij te werken op basis van waar u uw certificaat gebruikt, op de listener of de HTTP-instellingen van de toepassingsgateway. Raadpleeg de vermelde documentatiekoppelingen voor meer informatie.
3. Werk uw back-endtoepassingsservers bij om het opnieuw uitgegeven certificaat te gebruiken. Afhankelijk van de back-endserver die u gebruikt, kunnen de stappen voor het bijwerken van certificaten variëren. Controleer de documentatie van uw leverancier.

Het certificaat in uw listener bijwerken:

1. Open uw Application Gateway-resource in Azure Portal.
2. Open de listenerinstellingen die zijn gekoppeld aan uw certificaat.
3. Selecteer Geselecteerd certificaat vernieuwen of bewerken.
4. Upload uw nieuwe PFX-certificaat met het wachtwoord en selecteer Opslaan.
5. Open de website en controleer of de site werkt zoals verwacht. Zie Application Gateway-certificaten vernieuwen voor meer informatie.

Als u verwijst naar certificaten van Key Vault in uw Application Gateway-listener, raden we u aan de volgende stappen te volgen voor een snelle wijziging:

1. Ga in Azure Portal naar uw Key Vault-instellingen die zijn gekoppeld aan de toepassingsgateway.
2. Voeg het opnieuw uitgegeven certificaat toe of importeer dit in uw archief. Zie quickstart: Een sleutelkluis maken met behulp van Azure Portal voor meer informatie.
3. Nadat het certificaat is geïmporteerd, gaat u naar de listenerinstellingen van Application Gateway en selecteert u onder Kies een certificaat uit Key Vault de vervolgkeuzelijst Certificaat en selecteert u het onlangs toegevoegde certificaat.
4. Selecteer Opslaan. Zie TLS-beëindiging met Key Vault-certificaten voor meer informatie over TLS-beëindiging op Application Gateway met Key Vault-certificaten.

Het certificaat bijwerken in uw HTTP-instellingen:

Als u de v1-SKU van de Application Gateway/WAF-service gebruikt, moet u het nieuwe certificaat uploaden als uw back-endverificatiecertificaat.

1. Open uw Application Gateway-resource in Azure Portal.
2. Open de HTTP-instellingen die zijn gekoppeld aan uw certificaat.
3. Selecteer Certificaat toevoegen, upload het opnieuw uitgegeven certificaat en selecteer Opslaan.
4. U kunt het oude certificaat later verwijderen door de knop ... opties naast het oude certificaat te selecteren. Selecteer Verwijderen en selecteer Vervolgens Opslaan. Zie End-to-end TLS configureren met Application Gateway met de portal voor meer informatie.

Als u de V2-SKU van de Application Gateway/WAF-service gebruikt, hoeft u het nieuwe certificaat niet te uploaden in de HTTP-instellingen, omdat V2 SKU gebruikmaakt van 'vertrouwde basiscertificaten' en hier geen actie hoeft te worden ondernomen.

Ja. Zowel Laag 7- als Laag 4-routering via toepassingsgateway gebruiken dezelfde front-end-IP-configuratie. Op deze manier kunt u al uw clients omleiden naar één IP-adres (openbaar of privé) en dezelfde gatewayresource stuurt deze op basis van de geconfigureerde listenerprotocollen en de poorten.

Hoewel het HTTP(S)-verkeer ook kan worden verwerkt via L4-proxyprotocollen, raden we u dit niet aan. De L7-proxyoplossing van Application Gateway biedt meer controle en beveiliging over de HTTP(S)-protocollen via geavanceerde functies zoals Herschrijven, Sessieaffiniteit, Omleiding, WebSockets, WAF en meer.

De resource-eigenschappen voor laag 4-functies verschillen van die van laag 7. Wanneer u REST API of CLI gebruikt, moet u daarom de volgende eigenschappen gebruiken.

• REST API
• CLI

Nee U kunt de eigenschappen Laag 4 en Laag 7 niet kruislings koppelen. Daarom kunt u met een routeringsregel alleen een laag 4-type listener koppelen aan een laag 4-type back-endinstelling.

U kunt niet dezelfde naam gebruiken voor een L7 (httpListeners) en L4 (listeners). Dit geldt ook voor andere L4-eigenschappen, zoals back-end Instellingen Verzameling en routingRules.

Absoluut. Net als bij laag 7-proxy kunt u een privé-eindpunt toevoegen aan de back-endpool van uw toepassingsgateway. Dit privé-eindpunt moet worden geïmplementeerd in een aangrenzend subnet van hetzelfde virtuele netwerk van uw toepassingsgateway.

Keepalive wordt niet gebruikt voor back-endverbindingen. Voor elke binnenkomende aanvraag op de front-endlistenerverbinding start Application Gateway een nieuwe back-endverbinding om aan die aanvraag te voldoen.

De back-endserver ziet het IP-adres van de toepassingsgateway. Momenteel bieden we geen ondersteuning voor 'Client IP-behoud' waarmee de back-endtoepassing op de hoogte kan worden gesteld van het IP-adres van de oorspronkelijke client.

Dezelfde SSL-beleidsconfiguratie is van toepassing voor zowel Laag 7 (HTTPS) als Laag 4 (TLS). Momenteel bieden we geen ondersteuning voor SSL-profiel (listenerspecifiek SSL-beleid of wederzijdse verificatie) voor TLS-listeners.

Nee Het routeren van een client naar dezelfde back-endserver wordt momenteel niet ondersteund. De verbindingen worden op een round robin-manier gedistribueerd naar de servers in een back-endpool.

Ja, de functie voor automatische schaalaanpassing werkt ook voor pieken en reducties in het verkeer voor TLS- of TCP-protocol.

De WAF-mogelijkheden (Web Application Firewall) werken niet voor laag 4-gebruik.

Nee UDP-ondersteuning is momenteel niet beschikbaar.

Dezelfde lijst met toegestane poortbereiken en uitzonderingen zijn ook van toepassing op de Laag 4-proxy.

Met Kubernetes kunt u een groep pods intern in het cluster maken deployment en service resources beschikbaar maken. Als u dezelfde service extern beschikbaar wilt maken, wordt een Ingress resource gedefinieerd, die taakverdeling, TLS-beëindiging en op naam gebaseerde virtuele hosting biedt. Om aan deze Ingress resource te voldoen, is een toegangsbeheerobjectcontroller vereist, die luistert naar eventuele wijzigingen in Ingress resources en het load balancer-beleid configureert.

Met de Application Gateway-ingangscontroller (AGIC) kan Application Gateway worden gebruikt als inkomend verkeer voor een Azure Kubernetes Service, ook wel bekend als een AKS-cluster.

Op dit moment kan één exemplaar van een toegangsbeheerobjectcontroller slechts aan één toepassingsgateway worden gekoppeld.

AGIC probeert de routetabelresource automatisch te koppelen aan het Application Gateway-subnet, maar kan dit niet doen vanwege gebrek aan machtigingen van de AGIC. Als AGIC de routetabel niet kan koppelen aan het Application Gateway-subnet, wordt er een fout weergegeven in de AGIC-logboeken. In dit geval moet u de routetabel die door het AKS-cluster is gemaakt, handmatig koppelen aan het subnet van Application Gateway. Zie Ondersteunde door de gebruiker gedefinieerde routes voor meer informatie.

Ja, zolang de virtuele netwerken zijn gekoppeld en ze geen overlappende adresruimten hebben. Als u AKS uitvoert met kubenet, moet u ervoor zorgen dat u de routetabel die door AKS is gegenereerd, koppelt aan het Application Gateway-subnet.

Zie Verschil tussen Helm-implementatie en AKS-invoegtoepassing voor de verschillen tussen AGIC geïmplementeerd via Helm versus geïmplementeerd als een AKS-invoegtoepassing.

Zie Voor de verschillen tussen AGIC geïmplementeerd via Helm versus geïmplementeerd als AKS-invoegtoepassing het verschil tussen Helm-implementatie en AKS-invoegtoepassing, met name de tabellen die worden beschreven welke scenario's worden ondersteund door AGIC die worden geïmplementeerd via Helm in plaats van een AKS-invoegtoepassing. Over het algemeen kunt u met implementatie via Helm bètafuncties en releasekandidaten testen vóór een officiële release.

Nee De AGIC-invoegtoepassing is een beheerde service, wat betekent dat Microsoft de invoegtoepassing automatisch bijwerken naar de nieuwste stabiele versie.

Wederzijdse verificatie is tweerichtingsverificatie tussen een client en een server. Met wederzijdse verificatie met Application Gateway kan de gateway momenteel de client verifiëren die de aanvraag verzendt. Dit is clientverificatie. Normaal gesproken is de client de enige die de toepassingsgateway verifieert. Omdat Application Gateway nu ook de client kan verifiëren, wordt het wederzijdse verificatie waarbij Application Gateway en de client elkaar wederzijds verifiëren.

Nee, wederzijdse verificatie is momenteel alleen tussen de front-endclient en de toepassingsgateway. Wederzijdse back-endverificatie wordt momenteel niet ondersteund.

Application Gateway biedt drie logboeken:

• ApplicationGatewayAccessLog: Het toegangslogboek bevat elke aanvraag die is ingediend bij de front-end van de toepassingsgateway. De gegevens bevatten het IP-adres van de aanroeper, de AANGEVRAAGDe URL, de latentie van de reactie, de retourcode en bytes in en uit. Het bevat één record per toepassingsgateway.
• ApplicationGatewayPerformanceLog: In het prestatielogboek worden prestatiegegevens vastgelegd voor elke toepassingsgateway. Informatie omvat de doorvoer in bytes, het totale aantal verzonden aanvragen, het aantal mislukte aanvragen en het aantal gezonde en beschadigde back-endinstanties.
• ApplicationGatewayFirewallLog: Voor toepassingsgateways die u met WAF configureert, bevat het firewalllogboek aanvragen die zijn vastgelegd via de detectiemodus of preventiemodus.

Alle logboeken worden elke 60 seconden verzameld. Zie back-endstatus, diagnostische logboeken en metrische gegevens voor Application Gateway voor meer informatie.

Controleer de status met behulp van de PowerShell-cmdlet Get-AzApplicationGatewayBackendHealth of de portal. Zie Application Gateway Diagnostics voor meer informatie.

Diagnostische logboeken stromen naar het opslagaccount van de klant. Klanten kunnen het bewaarbeleid instellen op basis van hun voorkeur. Diagnostische logboeken kunnen ook worden verzonden naar een Event Hub of Azure Monitor-logboeken. Zie Application Gateway Diagnostics voor meer informatie.

Selecteer in de portal in het menuvenster van een toepassingsgateway het activiteitenlogboek voor toegang tot het auditlogboek.

Ja. In Application Gateway worden waarschuwingen geconfigureerd voor metrische gegevens. Zie metrische gegevens van Application Gateway en waarschuwingsmeldingen ontvangen voor meer informatie.

U kunt toegangslogboeken op verschillende manieren bekijken en analyseren. Gebruik Azure Monitor-logboeken, Excel, Power BI, enzovoort.

U kunt ook een Resource Manager-sjabloon gebruiken waarmee de populaire GoAccess-logboekanalyse voor application gateway-toegangslogboeken wordt geïnstalleerd en uitgevoerd. GoAccess biedt waardevolle HTTP-verkeersstatistieken zoals unieke bezoekers, aangevraagde bestanden, hosts, besturingssystemen, browsers en HTTP-statuscodes. Zie het Leesmij-bestand in de map Resource Manager-sjabloon voor meer informatie in GitHub.

Meestal ziet u een onbekende status wanneer de toegang tot de back-end wordt geblokkeerd door een NSG, aangepaste DNS of door de gebruiker gedefinieerde routering op het Application Gateway-subnet. Zie back-endstatus, diagnostische logboekregistratie en metrische gegevens voor Application Gateway voor meer informatie.

Als u vanwege de huidige platformbeperkingen een NSG hebt op het Application Gateway v2-subnet (Standard_v2, WAF_v2) en als u NSG-stroomlogboeken hebt ingeschakeld, ziet u niet-deterministisch gedrag. Dit scenario wordt momenteel niet ondersteund.

Application Gateway verplaatst of slaat geen klantgegevens op uit de regio waarin deze is geïmplementeerd.

Volgende stappen

• Zie Wat is Azure-toepassing Gateway voor meer informatie over Application Gateway.
• Zie End-to-End TLS inschakelen op Azure-toepassing Gateway voor meer informatie over TLS-beëindiging en end-to-end TLS met Application Gateway.