Vanliga frågor och svar om Application Gateway

Azure Application Gateway tillhandahåller en ADC (Application Delivery Controller) som en tjänst. Den erbjuder olika layer 7-belastningsutjämningsfunktioner för dina program. Den här tjänsten har hög tillgänglig, skalbar och fullständigt hanterad av Azure.

Application Gateway har stöd för automatisk skalning, TLS-avlastning och TLS från slutet till slut, en brandvägg för webbaserade program (WAF), cookiebaserad sessionstillhörighet, URL-sökvägsbaserad routning, värdtjänster för flera platser och andra funktioner. En fullständig lista över funktioner som stöds finns i Introduktion till Application Gateway.

Application Gateway är en Layer 7-lastbalanserare, vilket innebär att den endast fungerar med webbtrafik (HTTP, HTTPS, WebSocket och HTTP/2). Den stöder funktioner som TLS-avslutning, cookiebaserad sessionstillhörighet och resursallokering för belastningsutjämning av trafik. Load Balancer belastningsutjämnar trafik på layer 4 (TCP eller UDP).

Application Gateway har stöd för HTTP, HTTPS, HTTP/2 och WebSocket.

Se HTTP/2-stöd.

Se vilka backend-resurser som stöds.

Application Gateway v1 (Standard och WAF) är tillgängligt i alla regioner i globala Azure. Det finns även i Azure China 21Vianet och Azure Government.

Information Application Gateway v2 (Standard_v2 och WAF_v2) finns i Regioner som stöds för Application Gateway v2

Application Gateway är en dedikerad distribution i ditt virtuella nätverk.

Omdirigering stöds. Se Application Gateway översikt över omdirigering.

Se ordningen på lyssnaren som bearbetar.

Om du använder en offentlig IP-adress som slutpunkt hittar du IP- och DNS-informationen på den offentliga IP-adressresursen. Du kan också hitta den i portalen på översiktssidan för programgatewayen. Om du använder interna IP-adresser hittar du informationen på översiktssidan.

För v2-SKU:n öppnar du den offentliga IP-resursen och väljer Konfiguration. Fältet DNS-namnetikett (valfritt) är tillgängligt för att konfigurera DNS-namnet.

Keep-Alive-timeout styr hur länge tidsgränsen Application Gateway vänta på att en klient skickar en annan HTTP-begäran på en beständig anslutning innan den återanvänds eller stängs. TCP-tidsgränsen för inaktivitet styr hur länge en TCP-anslutning hålls öppen om det inte finns någon aktivitet.

Keep-Alive-timeouten i SKU:n Application Gateway v1 är 120 sekunder och i v2-SKU:n är den 75 sekunder. TCP-tidsgränsen för inaktivitet är standardvärdet 4 minuter på den virtuella IP-adressen (VIP) för både v1- och v2-SKU för Application Gateway. Du kan konfigurera TCP-tidsgränsen för inaktivitet på v1- och v2 Application Gateway så att den ligger mellan 4 minuter och 30 minuter. För både v1- och v2-programgatewayer måste du gå till den offentliga IP-adressen för Application Gateway och ändra TCP-tidsgränsen för inaktivitet under bladet "Konfiguration" för den offentliga IP-adressen på portalen. Det går inte att ändra värdet för den privata IP-adressen. Du kan ange TCP-tidsgränsen för inaktivitet för den offentliga IP-adressen via PowerShell genom att köra följande kommandon:

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

Nej. Det går inte att byta namn på en Application Gateway resurs. Du måste skapa en ny resurs med ett annat namn.

Nej. Det går inte att återställa en Application Gateway eller dess offentliga IP-adress när den har tagits bort. Du måste skapa en ny resurs.

I Application Gateway V1 SKU kan VIP ändras om du stoppar och startar programgatewayen. Dns-namnet som är associerat med programgatewayen ändras dock inte under gatewayens livslängd. Eftersom DNS-namnet inte ändras bör du använda ett CNAME-alias och peka det på programgatewayens DNS-adress. I Application Gateway V2 SKU kan du ange IP-adressen som statisk, så IP- och DNS-namnet ändras inte under programgatewayens livslängd.

Ja, SKU:n Application Gateway v2 stöder statiska offentliga IP-adresser och statiska interna IP-adresser. V1-SKU:n stöder statiska interna IP-adresser.

En programgateway stöder endast en offentlig IP-adress.

Se Application Gateway storleksöverväganden för undernät.

Ja. Förutom flera instanser av en viss Application Gateway-distribution kan du etablera en annan unik Application Gateway-resurs till ett befintligt undernät som innehåller en Application Gateway resurs.

Ett enda undernät har inte stöd för både v2- och v1-Application Gateway-SKU:er.

Ja, men bara specifika scenarier. Mer information finns i Application Gateway infrastrukturkonfiguration.

Ja. Se Ändringar i en begäran.

Det kan ta Application Gateway 20 minuter att etablera nya V1-SKU-distributioner. Ändringar av instansstorlek eller antal är inte störande och gatewayen förblir aktiv under den här tiden.

De flesta distributioner som använder v2-SKU:n tar cirka 6 minuter att etablera. Det kan dock ta längre tid beroende på typen av distribution. Till exempel kan distributioner över flera Tillgänglighetszoner med många instanser ta mer än 6 minuter.

Uppdateringar som initieras Application Gateway en uppdateringsdomän i taget, utanför arbetstid för den region där gatewayen distribueras. Aktiva anslutningar töms på ett smidigt sätt från de instanser som uppdateras. Medan uppdateringen pågår körs Application Gateway tillfälligt med begränsad kapacitet, vilket bestäms av mängden konfigurerade instanser. Uppdateringsprocessen fortsätter endast till nästa uppsättning instanser om den aktuella uppsättningen instanser har uppgraderats.

Nej. Application Gateway stöder inte e-postprotokoll som SMTP, IMAP och POP3.

Ja. Mer information finns i Migrera Azure Application Gateway och Web Application Firewall från v1 till v2.

Ja. SKU:n Application Gateway v1 fortsätter att stödjas. Vi rekommenderar dock starkt att du flyttar till v2 för att dra nytta av funktionsuppdateringarna i denna SKU. Mer information finns i Autoskalning och Zonredundant lagring Application Gateway v2.

Nej. Application Gateway V2 stöder inte proxybegäranden med NTLM-autentisering.

Ja, Chromium v80-uppdateringen införde ett krav på HTTP-cookies utan SameSite-attribut som ska behandlas som SameSite=Script. Det innebär att Application Gateway tillhörighetscookie inte skickas av webbläsaren i en kontext från tredje part.

För att stödja det här Application Gateway en annan cookie som kallas ApplicationGatewayAffinityCORS utöver den befintliga ApplicationGatewayAffinity-cookien. Dessa cookies liknar varandra, men ApplicationGatewayAffinityCORS-cookien har ytterligare två attribut tillagda: SameSite=None; Skydda. De här attributen upprätthåller fästsessioner även för begäranden om korsande ursprung. Mer information finns i avsnittet cookiebaserad tillhörighet.

En aktiv lyssnare är en lyssnare som är associerad med en regel och skickar trafik till en backend-pool. Alla lyssnare som endast omdirigerar trafik är inte en aktiv lyssnare. Lyssnare som är associerade med omdirigeringsregler betraktas inte som aktiva. Om omdirigeringsreglerna är en sökvägsbaserad regel måste alla sökvägar i omdirigeringsregeln omdirigera trafik, annars anses lyssnaren vara aktiv. Information om enskilda komponentgränser finns i Azure-prenumeration och tjänstbegränsningar, kvoter och begränsningar.

SKU:n Application Gateway v1 stöder scenarier med hög tillgänglighet när du har distribuerat två eller flera instanser. Azure distribuerar dessa instanser mellan uppdaterings- och feldomäner för att säkerställa att alla instanser inte misslyckas samtidigt. V1-SKU:n stöder skalbarhet genom att lägga till flera instanser av samma gateway för att dela belastningen.

V2-SKU:n säkerställer automatiskt att nya instanser sprids över feldomäner och uppdateringsdomäner. Om du väljer zonredundans sprids även de senaste instanserna över tillgänglighetszoner för att erbjuda zonindelade felåter återhämtning.

Använd Traffic Manager för att distribuera trafik över flera programgatewayer i olika datacenter.

Ja, SKU Application Gateway v2 stöder autoskalning. Mer information finns i Autoskalning och Zonredundant Application Gateway.

Nej. Instanser distribueras mellan uppgraderingsdomäner och feldomäner.

Ja. Du kan konfigurera anslutningstömning för att ändra medlemmar i en backend-pool utan avbrott. Mer information finns i avsnittet om anslutningstömning i Application Gateway.

Ja.

Ja. Application Gateway alltid distribueras i ett undernät för ett virtuellt nätverk. Det här undernätet kan bara innehålla programgatewayer. Mer information finns i krav för virtuella nätverk och undernät.

Så länge du har IP-Application Gateway kan du kommunicera med instanser utanför det virtuella nätverket som det finns i. Application Gateway kan också kommunicera med instanser utanför den prenumeration som den finns i. Om du planerar att använda interna IP-adresser som medlemmar i serverpoolen använder du peering för virtuella nätverk eller Azure VPN Gateway.

Nej. Men du kan distribuera andra programgatewayer i undernätet.

Du kan bara flytta Application Gateway mellan undernät inom samma virtuella nätverk. Det stöds med V1 med offentlig och privat frontend och V2 med endast offentlig frontend. Det är också viktigt att observera att Application Gateway bör vara i tillståndet Stoppad för att utföra den här åtgärden. Tänk på att om du stoppar/startar V1 ändras den offentliga IP-adressen. Den här åtgärden kan bara utföras med Azure PowerShell och Azure CLI genom att köra följande kommandon:

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

Mer information finns i Set-AzApplicationGatewayIPConfiguration.

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>

Se Nätverkssäkerhetsgrupper i Application Gateway undernätet.

Se Användardefinierade vägar som stöds i Application Gateway undernät.

Nej. Tjänstslutpunktsprinciper för lagringskonton stöds inte i Application Gateway undernät och om du konfigurerar det blockeras Azure-infrastrukturtrafik.

Se Application Gateway gränser.

Ja. Application Gateway stöder en intern IP-adress och en extern IP-adress per programgateway.

Ja. Peering för virtuella nätverk hjälper till att belastningsutjämna trafik i andra virtuella nätverk.

Ja, så länge trafik tillåts.

Mikrotjänstarkitektur stöds. Om du vill söka efter olika portar måste du konfigurera flera HTTP-inställningar.

Nej.

Se Order of processing rules (Ordningsföljd för bearbetningsregler).

Fältet Värd anger namnet som avsökningen ska skickas till när du har konfigurerat multisite på Application Gateway. Använd annars "127.0.0.1". Det här värdet skiljer sig från värdnamnet för den virtuella datorn. Formatet är <protocol> :// <host> : <port> <path> .

Ja. Se Begränsa åtkomsten till specifika käll-IP-adresser.

Nej.

Application Gateway v2 stöder för närvarande inte IPv6. Det kan fungera i ett dubbelt stack-VNet med endast IPv4, men gatewayundernätet måste vara endast IPv4. Application Gateway v1 stöder inte virtuella nätverk med dubbla stackar.

Application Gateway V2 stöder för närvarande inte bara privat IP-läge. Den stöder följande kombinationer

• Privat IP och offentlig IP
• Endast offentlig IP-adress

Men om du vill använda Application Gateway V2 med endast privat IP-adress kan du följa processen nedan:

1. Skapa en Application Gateway med både offentlig och privat IP-adress för frontend

2. Skapa inte några lyssnare för den offentliga IP-adressen för frontend. Application Gateway lyssnar inte på någon trafik på den offentliga IP-adressen om inga lyssnare skapas för den.

3. Skapa och bifoga en nätverkssäkerhetsgrupp för Application Gateway-undernätet med följande konfiguration i prioritetsordning:

   a. Tillåt trafik från källa som GatewayManager-tjänsttagg och Mål som Valfri och Målport som 65200-65535. Det här portintervallet krävs för azure-infrastrukturkommunikation. Dessa portar skyddas (låsta) av certifikatautentisering. Externa entiteter, inklusive Gateway-användaradministratörer, kan inte initiera ändringar på dessa slutpunkter utan lämpliga certifikat på plats

   b. Tillåt trafik från källa som Tjänsttagg för AzureLoadBalancer och Mål- och målport som Alla

   c. Neka all inkommande trafik från Källa som Internettjänsttagg och Mål- och målport som Alla. Ge den här regeln minsta prioritet i reglerna för inkommande trafik

   d. Behåll standardreglerna som att tillåta inkommande VirtualNetwork så att åtkomsten till den privata IP-adressen inte blockeras

   e. Utgående Internetanslutning kan inte blockeras. Annars får du problem med loggning, mått osv.

Exempel på NSG-konfiguration för endast privat

Application Gateway har stöd för själv signerade certifikat, certifikatutfärdarcertifikat ,EV-certifikat (Extended Validation), SAN-certifikat (multidomän) och jokerteckencertifikat.

Application Gateway stöder följande chiffersviter.

• 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

Information om hur du anpassar TLS-alternativ finns i Konfigurera TLS-principversioner och chiffersviter på Application Gateway.

Ja. Application Gateway har stöd för TLS-avlastning och TLS från slutet till slut, som omkrypterar trafik till backend.

Ja. Du kan konfigurera Application Gateway att neka TLS1.0, TLS1.1 och TLS1.2. Som standard är SSL 2.0 och 3.0 redan inaktiverat och kan inte konfigureras.

Ja. I Application Gateway kan du konfigurera chiffersviter. Om du vill definiera en anpassad princip aktiverar du minst en av följande chiffersviter.

• 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 använder SHA256 för för hantering av backend.

Application Gateway stöder upp till 100 TLS-/SSL-certifikat.

Ja, Application Gateway stöder certifikat med OCSP-tillägg och OCSP-stapling för servercertifikat.

Application Gateway stöder upp till 100 autentiseringscertifikat.

Ja, SKU Application Gateway v2 stöder Key Vault. Läs mer i TLS-avslutning med Key Vault-certifikat.

För flera domänbaserade (värdbaserade) routning kan du skapa lyssnare för flera platser, konfigurera lyssnare som använder HTTPS som protokoll och associera lyssnarna med routningsreglerna. Mer information finns i Hosting multiple sites by using Application Gateway.

Nej, använd endast alfanumeriska tecken i ditt PFX-fillösenord.

Certifikatutfärdare (CA) Webbläsarmedlemmar publicerade nyligen rapporter som beskriver flera certifikat som utfärdats av CA-leverantörer som används av våra kunder, Microsoft och den större teknik-communityn som inte efterlever branschstandarder för offentligt betrodda certifikatutfärdare.Rapporter om icke-kompatibla CAs finns här: 

• Fel 1649951
• Fel 1650910

Enligt branschens efterlevnadskrav började CA-leverantörer återkalla icke-kompatibla certifikatutfärdare och utfärda kompatibla certifikatutfärdare som kräver att kunderna får sina certifikat utfärdade på nytt.Microsoft samarbetar nära med dessa leverantörer för att minimera den potentiella påverkan på Azure-tjänster, men dina självutgivna certifikat eller certifikat som används i "Bring Your Own Certificate"-scenarier (BYOC) riskerar fortfarande att oväntat återkallas.

Om du vill kontrollera om certifikat som används av ditt program har återkallats refererar du till DigiCerts meddelande och spårning av certifikatåterkallning. Om dina certifikat har återkallats eller kommer att återkallas måste du begära nya certifikat från certifikatutfärdaren som används i dina program. För att undvika att programmets tillgänglighet avbryts på grund av att certifikat oväntat återkallas, eller för att uppdatera ett certifikat som har återkallats, kan du gå till våra Azure-uppdateringar efter reparationslänkar för olika Azure-tjänster som stöder BYOC: https://azure.microsoft.com/updates/certificateauthorityrevocation/

Mer Application Gateway specifik information finns nedan –

Om du använder ett certifikat som utfärdats av en av de återkallade ICA:erna kan programmets tillgänglighet avbrytas och beroende på ditt program kan du få en mängd olika felmeddelanden, inklusive men inte begränsat till:

1. Ogiltigt certifikat/återkallat certifikat
2. Anslutningens tidsgräns uppnåddes
3. HTTP 502

För att undvika avbrott i programmet på grund av det här problemet eller för att utfärda en certifikatutfärdare som har återkallats på nytt måste du vidta följande åtgärder:

1. Kontakta certifikatprovidern om hur du utfärdar dina certifikat på nytt
2. När nya certifikat har utfärdats uppdaterar du certifikaten på Azure Application Gateway/WAF med hela förtroendekedjan (lövcertifikat, mellanliggande rotcertifikat). Beroende på var du använder certifikatet, antingen på lyssnaren eller HTTP-inställningarna för Application Gateway, följer du stegen nedan för att uppdatera certifikaten och kontrollerar dokumentationslänkarna som nämns för mer information.
3. Uppdatera dina serverprogramservrar för att använda det åter utfärdata certifikatet. Beroende på vilken server du använder kan stegen för certifikatuppdatering variera. Kontrollera dokumentationen från leverantören.

Så här uppdaterar du certifikatet i lyssnaren:

1. I Azure Portaldu din Application Gateway resurs
2. Öppna lyssnarinställningarna som är associerade med certifikatet
3. Klicka på Förnya eller redigera valt certifikat
4. Upload ditt nya PFX-certifikat med lösenordet och klicka på Spara
5. Gå till webbplatsen och kontrollera om webbplatsen fungerar som förväntat. Mer information finns i dokumentationen här.

Om du refererar till certifikat från Azure KeyVault i din Application Gateway lyssnare rekommenderar vi att du följer stegen för en snabb ändring –

1. I Azure Portaldu till dina Azure KeyVault-inställningar som har associerats med Application Gateway
2. Lägg till/importera certifikatet som ska utfärdas i ditt arkiv. Mer information om hur du gör finns i dokumentationen här.
3. När certifikatet har importerats går du till lyssnarinställningarna för Application Gateway och under "Välj ett certifikat från Key Vault" klickar du på listrutan "Certifikat" och väljer det nyligen tillagda certifikatet
4. Klicka på Spara. Mer information om TLS-avslutning Application Gateway med Key Vault certifikat finns i dokumentationen här.

Så här uppdaterar du certifikatet i http-Inställningar:

Om du använder V1-SKU för Application Gateway/WAF-tjänsten måste du ladda upp det nya certifikatet som ditt certifikat för serverautentisering.

1. I Azure Portaldu din Application Gateway resurs
2. Öppna DE HTTP-inställningar som är associerade med certifikatet
3. Klicka på "Lägg till certifikat" och ladda upp det återutladdade certifikatet och klicka på Spara
4. Du kan ta bort det gamla certifikatet senare genom att klicka på knappen "..." bredvid det gamla certifikatet och välj Ta bort och klicka på Spara. Mer information finns i dokumentationen här.

Om du använder V2-SKU:n för Application Gateway/WAF-tjänsten behöver du inte ladda upp det nya certifikatet i HTTP-inställningarna eftersom V2 SKU använder "betrodda rotcertifikat" och ingen åtgärd behöver vidtas här.

Med Kubernetes kan deployment du skapa resurser och exponera en grupp service poddar internt i klustret. För att exponera samma tjänst externt definieras en resurs som tillhandahåller Ingress belastningsutjämning, TLS-avslutning och namnbaserad virtuell värdhantering. För att uppfylla den här resursen krävs en ingress-kontrollant som lyssnar efter ändringar av resurser och Ingress Ingress konfigurerar lastbalanseringsprinciperna.

Med Application Gateway Ingress Controller (AGIC) kan Azure Application Gateway användas som ingress för en Azure Kubernetes Service även kallat ett AKS-kluster.

För närvarande kan en instans av ingress-kontrollanten bara associeras med en Application Gateway.

AGIC försöker automatiskt associera resursen för vägtabellen till Application Gateway undernät, men kan misslyckas med att göra det på grund av bristande behörigheter från AGIC. Om AGIC inte kan associera vägtabellen med Application Gateway-undernätet uppstår ett fel i AGIC-loggarna som säger att du då måste associera vägtabellen som skapades av AKS-klustret till Application Gateway-undernätet manuellt. Mer information finns i Användardefinierade vägar som stöds.

Ja, så länge de virtuella nätverken är peer-peerade och de inte har överlappande adressutrymmen. Om du kör AKS med kubenet måste du associera den vägtabell som genererats av AKS till Application Gateway undernätet.

Se skillnaderna mellan AGIC som distribueras via Helm och distribueras som ett AKS-tillägg här

Se skillnaderna mellan AGIC som distribueras via Helm och distribueras som ett AKS-tillägg här,särskilt de tabeller som dokumenterar vilka scenarier som stöds av AGIC som distribueras via Helm i stället för ett AKS-tillägg. I allmänhet gör distribution via Helm att du kan testa betafunktioner och lanseringskandidater innan en officiell version.

Nej, AGIC-tillägget är en hanterad tjänst, vilket innebär att Microsoft automatiskt uppdaterar tillägget till den senaste stabila versionen.

Ömsesidig autentisering är tvåvägsautentisering mellan en klient och en server. Ömsesidig autentisering med Application Gateway tillåter för närvarande att gatewayen verifierar klienten som skickar begäran, vilket är klientautentisering. Vanligtvis är klienten den enda som autentiserar Application Gateway. Eftersom Application Gateway nu också kan autentisera klienten blir det ömsesidig autentisering där Application Gateway och klienten ömsesidigt autentiserar varandra.

Nej, ömsesidig autentisering är för närvarande endast mellan klientklienten och Application Gateway. Ömsesidig autentisering i serverserver stöds inte för närvarande.

Application Gateway innehåller tre loggar:

• ApplicationGatewayAccessLog: Åtkomstloggen innehåller varje begäran som skickas till application gateway-frontend. Data omfattar anroparens IP, begärd URL, svarstid för svar, returkod och byte in och ut. Den innehåller en post per programgateway.
• ApplicationGatewayPerformanceLog: Prestandaloggen samlar in prestandainformation för varje programgateway. Informationen omfattar dataflödet i byte, totalt antal begäranden som har betjänats, antal misslyckade förfrågningar samt antalet felfria och felaktiga serverinstanser.
• ApplicationGatewayFirewallLog: För programgatewayer som du konfigurerar med WAF innehåller brandväggsloggen begäranden som loggas i identifieringsläge eller skyddsläge.

Alla loggar samlas in var 60:e sekund. Mer information finns i Backend-hälsotillstånd, diagnostikloggar och mått för Application Gateway.

Kontrollera hälsotillståndet med hjälp av PowerShell-cmdleten Get-AzApplicationGatewayBackendHealth eller portalen. Mer information finns i Application Gateway diagnostik.

Diagnostikloggar flödar till kundens lagringskonto. Kunder kan ange kvarhållningsprincipen baserat på deras önskemål. Diagnostikloggar kan också skickas till en händelsehubb eller Azure Monitor loggar. Mer information finns i Application Gateway diagnostik.

I portalen går du till menybladet för en programgateway och väljer Aktivitetslogg för att komma åt granskningsloggen.

Ja. I Application Gateway konfigureras aviseringar för mått. Mer information finns i Application Gateway mått och Ta emot aviseringsmeddelanden.

Du kan visa och analysera åtkomstloggar på flera olika sätt. Använd Azure Monitor loggar, Excel, Power BI och så vidare.

Du kan också använda en Resource Manager som installerar och kör det populära GoAccess-logganalysverktyg för att Application Gateway åtkomstloggar. GoAccess ger värdefull STATISTIK FÖR HTTP-trafik, till exempel unika besökare, begärda filer, värdar, operativsystem, webbläsare och HTTP-statuskoder. Mer information finns i GitHub readme-filen i Resource Manager mallmappen.

Vanligtvis visas en okänd status när åtkomsten till servergruppen blockeras av en nätverkssäkerhetsgrupp (NSG), anpassad DNS eller användardefinierad routning (UDR) i Application Gateway-undernätet. Mer information finns i Backend health ,diagnostics logging, and metrics for Application Gateway.

På grund av aktuella plattformsbegränsningar, om du har en NSG på undernätet Application Gateway v2 (Standard_v2, WAF_v2) och om du har aktiverat NSG-flödesloggar på det, visas icke-terministiskt beteende och det här scenariot stöds inte för närvarande.

Application Gateway flyttar eller lagrar inte kunddata från den region som de distribueras i.

Nästa steg

Mer information om Application Gateway finns i Vad är Azure Application Gateway?.