Veelgestelde vragen over Application Gateway

Azure Application Gateway biedt een ADC (Application Delivery Controller) als een service. Het biedt verschillende taakverdelingsmogelijkheden van laag 7 voor uw toepassingen. Deze service is zeer beschikbaar, schaalbaar en volledig beheerd door Azure.

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

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

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

Zie HTTP/2-ondersteuning.

Zie ondersteunde back-end-resources.

Application Gateway v1 (Standard en WAF) is beschikbaar in alle regio's van azure wereldwijd. Het is ook beschikbaar in Azure China 21Vianet en Azure Government.

Zie Application Gateway v2 (Standard_v2 en WAF_v2) voor meer informatie over Application Gateway v2

Application Gateway is een toegewezen implementatie in uw virtuele netwerk.

Omleiding wordt ondersteund. Zie Application Gateway overzicht van omleidingen.

Bekijk de volgorde van de verwerking van de listener.

Als u een openbaar IP-adres als eindpunt gebruikt, vindt u de IP- en DNS-informatie op de resource van het openbare IP-adres. Of u vindt deze in de portal op de overzichtspagina voor de toepassingsgateway. Als u interne IP-adressen gebruikt, vindt u de informatie op de overzichtspagina.

Open de openbare IP-resource voor de v2-SKU en selecteer Configuratie. Het veld DNS-naamlabel (optioneel) is beschikbaar om de DNS-naam te configureren.

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

De time-out Keep-Alive in de Application Gateway v1 SKU is 120 seconden en in de v2-SKU is dit 75 seconden. De time-out voor inactieve TCP is een standaardwaarde van 4 minuten op het virtuele IP-adres (VIP) van de front-Application Gateway. U kunt de time-outwaarde voor inactieve TCP op v1- en v2-toepassingsgateways zo configureren dat deze tussen 4 en 30 minuten liggen. Voor zowel v1- als v2-toepassingsgateways moet u naar het openbare IP-adres van de Application Gateway navigeren en de time-out voor TCP-inactieve gegevens wijzigen onder de blade Configuratie van het openbare IP-adres in de portal. Het wijzigen van de waarde van het privé-IP-adres wordt niet ondersteund. U kunt de time-outwaarde voor TCP-inactieve gegevens van het openbare IP-adres instellen via PowerShell door de volgende opdrachten uit te voeren:

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

Nee. Er is geen manier om de naam van een Application Gateway wijzigen. U moet een nieuwe resource met een andere naam maken.

Nee. Er is geen manier om een resource of het openbare IP Application Gateway te herstellen nadat deze is verwijderd. U moet een nieuwe resource maken.

In Application Gateway V1 SKU kan het VIP wijzigen als u de toepassingsgateway stopt en start. De DNS-naam die aan de toepassingsgateway is gekoppeld, verandert echter niet gedurende de levensduur van de gateway. Omdat de DNS-naam niet verandert, moet u een CNAME-alias gebruiken en deze laten wijzen naar het DNS-adres van de toepassingsgateway. In Application Gateway V2 SKU kunt u het IP-adres instellen als statisch, zodat de IP- en DNS-naam niet veranderen 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's.

Een toepassingsgateway ondersteunt slechts één openbaar IP-adres.

Zie Application Gateway overwegingen voor de grootte van het 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 bevat.

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

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

Ja. Zie Wijzigingen in een aanvraag.

Het Application Gateway implementaties van nieuwe V1-SKU's kan tot 20 minuten duren. Wijzigingen in de grootte of het aantal exemplaren zijn niet verstorend en de gateway blijft actief gedurende deze periode.

De meeste implementaties die gebruikmaken van de v2-SKU, duren ongeveer 6 minuten. Het kan echter langer duren, afhankelijk van het type implementatie. Implementaties op meerdere Beschikbaarheidszones met veel exemplaren kunnen bijvoorbeeld meer dan 6 minuten duren.

Updates die zijn geïnitieerd Application Gateway worden één updatedomein tegelijk toegepast, buiten bedrijfsuren voor de regio waarin de gateway is geïmplementeerd. Actieve verbindingen worden zonder al te veel tijd ontdaan van de exemplaren die worden bijgewerkt. Terwijl de update wordt uitgevoerd, Application Gateway tijdelijk uitgevoerd met een verminderde capaciteit, wat wordt bepaald door het aantal exemplaren dat is geconfigureerd. Het updateproces gaat alleen door naar de volgende set exemplaren als de huidige set exemplaren is bijgewerkt.

Nee. Application Gateway biedt geen ondersteuning voor e-mailprotocollen zoals SMTP, IMAP en POP3.

Ja. Zie Migrate Azure Application Gateway and Web Application Firewall from v1 to v2 (Gegevens migreren van v1 naar v2) voor meer informatie.

Ja. De Application Gateway v1 SKU wordt nog steeds ondersteund. Het wordt echter sterk aanbevolen om over te gaan naar v2 om te profiteren van de functie-updates in die SKU. Zie Automatisch schalen en zone-redundante Application Gateway v2 voor meer informatie.

Nee. Application Gateway V2 biedt geen ondersteuning voor proxyaanvragen met NTLM-verificatie.

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

Ter ondersteuning van dit scenario Application Gateway een andere cookie met de naam ApplicationGatewayAffinityCORS, naast de bestaande ApplicationGatewayAffinity-cookie. Deze cookies zijn vergelijkbaar, maar aan de cookie ApplicationGatewayAffinityCORS zijn nog twee kenmerken toegevoegd: SameSite=None; Beveilig. Deze kenmerken behouden 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-mailpool stuurt. Een listener die alleen verkeer omleiden is geen actieve listener. Listeners die zijn gekoppeld aan omleidingsregels worden niet beschouwd als actief. Als de omleidingsregels een padgebaseerde regel zijn, moeten alle paden in die omleidingsregel verkeer omleiden, anders wordt de listener als actief beschouwd. Zie Limieten, quota's en beperkingen voor Azure-abonnementen en -service voor meer informatie over de limiet 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 tegelijk 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 zone-redundantie kiest, worden de nieuwste exemplaren ook verdeeld over beschikbaarheidszones om tolerantie voor zonelijke fouten te bieden.

Gebruik Traffic Manager verkeer te verdelen over meerdere toepassingsgateways in verschillende datacenters.

Ja, de Application Gateway v2 SKU ondersteunt automatisch schalen. Zie Autoscaling and Zone-redundant Application Gateway (Automatisch schalen en zone-redundante Application Gateway).

Nee. Exemplaren worden gedistribueerd over upgradedomeinen en foutdomeinen.

Ja. U kunt de verbindingsafvoer instellen om leden in een back-uppool zonder onderbreking te wijzigen. Zie voor meer informatie de sectie Verbindingsafvoer van Application Gateway.

Ja.

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

Zolang u een IP-verbinding hebt, Application Gateway communiceren met exemplaren buiten het virtuele netwerk waarin het zich in zich. Application Gateway kunnen ook communiceren met exemplaren buiten het abonnement waarin het zich ook voordeed. Als u van plan bent interne IP's te gebruiken als leden van de back-endpool, gebruikt u peering voor virtuele netwerken of Azure VPN Gateway.

Nee. Maar u kunt andere toepassingsgateways in het subnet implementeren.

U kunt een Application Gateway alleen tussen subnetten binnen hetzelfde virtuele netwerk verplaatsen. Het wordt ondersteund met V1 met openbare en privé-front-en V2 met alleen openbare front-end. Het is ook belangrijk te weten dat de Application Gateway de status Gestopt moet hebben om deze actie uit te voeren. Houd er rekening mee dat het openbare IP-adres wordt gewijzigd als u V1 stopt/start. Deze bewerking kan alleen worden uitgevoerd met Azure PowerShell en 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 Application Gateway subnet.

Nee. Beleidsregels voor service-eindpunten voor opslagaccounts worden niet ondersteund in 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 voor virtuele netwerken zorgt voor een gelijke load balancer van verkeer in andere virtuele netwerken.

Ja, zolang verkeer is toegestaan.

Microservicearchitectuur wordt ondersteund. Als u wilt controleren op verschillende poorten, moet u meerdere HTTP-instellingen configureren.

Nee.

Zie Volgorde van verwerkingsregels.

Het veld Host geeft de naam op waar de test naar moet worden verzenden wanneer u meerdere locatie op de Application Gateway. 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 De toegang tot specifieke bron-IP's beperken.

Nee.

Application Gateway v2 biedt momenteel geen ondersteuning voor IPv6. Het kan worden gebruikt in een dual stack VNet met behulp van alleen IPv4, maar het gatewaysubnet moet alleen IPv4 zijn. Application Gateway v1 biedt geen ondersteuning voor VNets met dubbele stack.

Application Gateway V2 ondersteunt momenteel niet alleen de privé-IP-modus. Het ondersteunt de volgende combinaties

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

Maar als u V2 alleen wilt gebruiken Application Gateway privé-IP-adres, kunt u het onderstaande proces volgen:

1. Een front-Application Gateway met zowel een openbaar als een privé-front-en-ip-adres maken

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 volgorde van prioriteit:

   a. Sta verkeer van Bron toe als GatewayManager-servicetag en Doel als Any- en Destination-poort als 65200-65535. Dit poortbereik is vereist voor communicatie met de Azure-infrastructuur. Deze poorten worden beveiligd (vergrendeld) door certificaatverificatie. Externe entiteiten, waaronder de gebruikersbeheerders van de gateway, kunnen geen wijzigingen op die eindpunten initiëren zonder de juiste certificaten

   b. Verkeer van bron toestaan als AzureLoadBalancer-servicetag en Doel- en doelpoort als Any

   c. Weiger al het binnenkomende verkeer van Bron als internetservicetag en Doel- en doelpoort als Any. Geef deze regel de minste prioriteit in de regels voor binnenkomende verkeer

   d. Houd de standaardregels aan zoals het toestaan van inkomende virtualNetwork-toegang, zodat de toegang tot het privé-IP-adres niet wordt geblokkeerd

   e. Uitgaande internetverbinding kan niet worden geblokkeerd. Anders krijgt u problemen met logboekregistratie, metrische gegevens, enzovoort.

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

Application Gateway ondersteunt zelf-ondertekende certificaten, CA-certificaten (certificeringsinstantie), EV-certificaten (Extended Validation), SAN-certificaten (multi-domain) en certificaten met jokertekens.

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 coderingssuitesconfigureren op de pagina voor meer informatie over het aanpassen van TLS-Application Gateway.

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

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

Ja. In Application Gateway kunt u coderingssuites configureren. Als u een aangepast beleid wilt definiëren, moet u ten minste één van de volgende coderingssuites inschakelen.

• 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 naar voor back-endbeheer.

Application Gateway ondersteunt maximaal 100 TLS/SSL-certificaten.

Ja, Application Gateway ondersteunt certificaten met OCSP-extensies en OCSP-nieting 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 (op basis van een host) kunt u listeners voor meerdere locaties maken, listeners instellen die HTTPS als protocol gebruiken en de listeners koppelen aan de routeringsregels. Zie Hosting multiple sites by using Application Gateway (Meerdere sites hosten met behulp van Application Gateway).

Nee, gebruik alleen alfanumerieke tekens in het wachtwoord van uw PFX-bestand.

Leden van de certificeringsinstantie (CA) Browser hebben onlangs rapporten gepubliceerd met gedetailleerde informatie over meerdere certificaten die zijn uitgegeven door CA-leveranciers die worden gebruikt door onze klanten, Microsoft en de grotere technologie-community die niet voldoen aan de industrienormen voor openbaar vertrouwde CA's.De rapporten met betrekking tot de niet-compatibele CAs vindt u hier: 

• Fout 1649951
• Fout 1650910

Volgens de nalevingsvereisten van de branche zijn CA-leveranciers begonnen met het in trekken 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 gevolgen voor Azure-services te minimaliseren, maar uw zelf uitgegeven certificaten of certificaten die worden gebruikt in BYOC-scenario's (Bring Your Own Certificate) lopen nog steeds het risico om onverwacht in te trekken.

Als u wilt controleren of certificaten die door uw toepassing worden gebruikt, zijn ingetrokken, verwijst u naar aankondiging van DigiCert en de Certificate Revocation Tracker. Als uw certificaten zijn ingetrokken of worden 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 ons Bericht over Azure-updates voor herstelkoppelingen van verschillende Azure-services die ondersteuning bieden voor BYOC: https://azure.microsoft.com/updates/certificateauthorityrevocation/

Zie Application Gateway voor meer informatie.

Als u een certificaat gebruikt dat is uitgegeven door een van de ingetrokken ICA's, kan de beschikbaarheid van uw toepassing worden onderbroken. Afhankelijk van uw toepassing kunt u diverse foutberichten ontvangen, waaronder, maar niet beperkt tot:

1. Ongeldig certificaat/ingetrokken certificaat
2. Time-out opgetreden voor verbinding
3. HTTP 502

Als u wilt voorkomen dat uw toepassing wordt onderbroken als gevolg van dit probleem of om een ingetrokken CA opnieuw uit te geven, moet u de volgende acties uitvoeren:

1. Neem contact op met uw certificaatprovider over het opnieuw uitgeven van uw certificaten
2. Nadat de certificaten opnieuw zijn uitgegeven, moet u uw certificaten op de Azure Application Gateway/WAF bijwerken met de volledige vertrouwensketen (leaf, tussenliggend, basiscertificaat). Op basis van waar u uw certificaat gebruikt, op de listener of de HTTP-instellingen van de Application Gateway, volgt u de onderstaande stappen om de certificaten bij te werken en controleert u de documentatiekoppelingen die worden vermeld 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 het certificaat variëren. Raadpleeg de documentatie van uw leverancier.

Het certificaat in uw listener bijwerken:

1. Open in Azure Portalde resource Application Gateway resource
2. Open de listener-instellingen die aan uw certificaat zijn gekoppeld
3. Klik op 'Het geselecteerde certificaat vernieuwen of bewerken'
4. Upload pfx-certificaat met het wachtwoord en klik op Opslaan
5. Ga naar de website en controleer of de site werkt zoals verwacht. Raadpleeg hier de documentatie voor meer informatie.

Als u verwijst naar certificaten van Azure KeyVault in uw Application Gateway-listener, raden we u aan de volgende stappen uit te voeren voor een snelle wijziging:

1. Navigeer in Azure Portalnaar uw Azure KeyVault-instellingen die zijn gekoppeld aan de Application Gateway
2. Voeg het opnieuw uitgegeven certificaat toe aan of importeer het in uw winkel. Zie de documentatie hier voor meer informatie over hoe u dit kunt doen.
3. Nadat het certificaat is geïmporteerd, gaat u naar uw Application Gateway-listenerinstellingen en klikt u onder Een certificaat kiezen uit Key Vault op de vervolgkeuzepagina Certificaat en kiest u het onlangs toegevoegde certificaat
4. Klik op Opslaan Raadpleeg de documentatie hier voor meer informatie over TLS-beëindiging Application Gateway met Key Vault certificaten.

Het certificaat in uw HTTP-Instellingen:

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

1. Open in Azure Portalde resource Application Gateway resource
2. Open de HTTP-instellingen die aan uw certificaat zijn gekoppeld
3. Klik op Certificaat toevoegen, upload het opnieuw uitgegeven certificaat en klik op Opslaan
4. U kunt het oude certificaat later verwijderen door op '...' te klikken naast het oude certificaat, selecteer Verwijderen en klik op Opslaan. Raadpleeg hier de documentatie 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.

Met Kubernetes kunt u een groep pods intern in het cluster maken en een deployment service resource maken. Om dezelfde service extern weer te geven, wordt een resource gedefinieerd die taakverdeling, TLS-beëindiging en op Ingress naam gebaseerde virtuele hosting biedt. Om aan deze resource te voldoen, is een controller voor load balancer vereist. Hiermee wordt naar wijzigingen in Ingress Ingress resources geluisterd en load balancer geconfigureerd.

Met Application Gateway Ingress Controller (AGIC) kunnen Azure Application Gateway worden gebruikt als het toegangspunt voor een Azure Kubernetes Service ook wel een AKS-cluster genoemd.

Op dit moment kan één exemplaar van de controller voor ingress slechts aan één Application Gateway.

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

Ja, zolang de virtuele netwerken zijn verbonden en ze geen overlappende adresruimten hebben. Als u AKS met kubenet gebruikt, moet u de routetabel die door AKS wordt gegenereerd, koppelen aan het Application Gateway subnet.

Bekijk hier de verschillen tussen AGIC geïmplementeerd via Helm en geïmplementeerd als een AKS-invoeg-on

Bekijk hier de verschillen tussen AGIC geïmplementeerd via Helm en geïmplementeerd als een AKS-invoeg-on, met name de tabellen die documenteren welke scenario('s) worden ondersteund door AGIC die zijn geïmplementeerd via Helm, in plaats van een AKS-invoeg-on. Over het algemeen kunt u met de implementatie via Helm bèta-functies en releasekandidaten testen vóór een officiële release.

Nee, AGIC-invoegversie is een beheerde service, wat betekent dat Microsoft de invoeg-app automatisch zal bijwerken naar de nieuwste stabiele versie.

Wederzijdse verificatie is verificatie in twee punten tussen een client en een server. Wederzijdse verificatie met Application Gateway de gateway momenteel in staat om te controleren of de client de aanvraag verstuurt. Dit is clientverificatie. Normaal gesproken is de client de enige die de Application Gateway. 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 mogelijk tussen de front-Application Gateway. Wederzijdse back-endverificatie wordt momenteel niet ondersteund.

Application Gateway biedt drie logboeken:

• ApplicationGatewayAccessLog: het toegangslogboek bevat elke aanvraag die wordt verzonden naar de front-end van de toepassingsgateway. De gegevens omvatten het IP-adres van de aanroeper, aangevraagde URL, reactielatentie, retourcode en bytes in en uit. Het bevat één record per toepassingsgateway.
• ApplicationGatewayPerformanceLog: Het prestatielogboek legt prestatiegegevens vast voor elke toepassingsgateway. Informatie omvat de doorvoer in bytes, het totale aantal aanvragen dat wordt ingediend, het aantal mislukte aanvragen en het aantal back-exemplaren met een goede en slechte status.
• ApplicationGatewayFirewallLog: voor toepassingsgateways die u configureert met WAF, bevat het firewalllogboek aanvragen die zijn geregistreerd via de detectiemodus of preventiemodus.

Alle logboeken worden elke 60 seconden verzameld. Zie Back-end-status, diagnostische logboekenen metrische gegevens voor Application Gateway.

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

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

Selecteer in de portal op de menublade van een toepassingsgateway activiteitenlogboek om toegang te krijgen tot het auditlogboek.

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

U kunt toegangslogboeken op verschillende manieren weergeven en analyseren. Gebruik Azure Monitor logboeken, Excel, Power BI, en meer.

U kunt ook een Resource Manager gebruiken die de populaire GoAccess-logboekanalyse installeert en uit te Application Gateway logboeken. GoAccess biedt waardevolle HTTP-verkeersstatistieken, zoals unieke bezoekers, aangevraagde bestanden, hosts, besturingssystemen, browsers en HTTP-statuscodes. Zie voor meer informatie in GitHub het leesmij-bestand in de Resource Manager sjabloonmap.

Normaal gesproken ziet u een onbekende status wanneer de toegang tot de back-end wordt geblokkeerd door een netwerkbeveiligingsgroep (NSG), aangepaste DNS of door de gebruiker gedefinieerde routering (UDR) op het subnet van de toepassingsgateway. Zie Back-end-status, logboekregistratie vandiagnostische gegevens en metrische gegevens voor Application Gateway.

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

Application Gateway verplaatst of opgeslagen klantgegevens niet uit de regio waarin deze is geïmplementeerd.

Volgende stappen

Zie Wat is Application Gateway? voor meer informatie over Azure Application Gateway.