Vanliga frågor och svar om Application Gateway

Azure Application Gateway tillhandahåller en programleveranskontrollant som en tjänst. Den erbjuder olika lager 7-belastningsutjämningsfunktioner för dina program. Den här tjänsten är mycket tillgänglig, skalbar och fullständigt hanterad av Azure.

Application Gateway stöder automatisk skalning, TLS-avlastning och TLS från slutpunkt till slutpunkt, en brandvägg för webbprogram (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ämningstrafik. Load Balancer lastbalanserar trafik på nivå 4 (TCP eller UDP).

Application Gateway stöder HTTP, HTTPS, HTTP/2 och WebSocket.

Se HTTP/2-stöd.

Se Serverdelsresurser som stöds.

Application Gateway v1 (Standard och WAF) är tillgängligt i alla regioner i globala Azure. Den är också tillgänglig i Microsoft Azure som drivs av 21Vianet och Azure Government.

För Tillgänglighet för 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 Översikt över omdirigering av Application Gateway.

Se ordningen för lyssnarbearbetning.

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 Azure-portalen på översiktssidan för programgatewayen. Om du använder interna IP-adresser hittar du informationen på översiktssidan. För v1-SKU:n har gatewayer som skapats efter den 1 maj 2023 inte ett dns-standardnamn som automatiskt associeras med den offentliga IP-resursen. För V2 SKU ö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 programgatewayen väntar på att en klient ska skicka en annan HTTP-begäran på en beständig anslutning innan den återanvänds eller stängs. Tidsgränsen för TCP-inaktivitet styr hur länge en TCP-anslutning hålls öppen om det inte finns någon aktivitet.

Tidsgränsen Keep-Alive i Application Gateway v1 SKU är 120 sekunder och i V2 SKU är det 75 sekunder. För privata IP-adresser kan värdet inte konfigureras med en TCP-timeout på 5 minuter. Tidsgränsen för TCP-inaktivitet är en 4-minuters standardinställning på klientdelens virtuella IP (VIP) för både v1 och v2 SKU för Application Gateway. Du kan konfigurera TCP-timeoutvärdet för inaktivitet på v1- och v2 Application Gateway-instanser så att det är någonstans mellan 4 minuter och 30 minuter. För både v1- och v2 Application Gateway-instanser måste du gå till den offentliga IP-adressen för programgatewayen och ändra tidsgränsen för TCP-inaktivitet under fönstret Konfiguration för den offentliga IP-adressen i portalen. Du kan ange TCP-timeoutvärdet 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

För HTTP/2-anslutningar till klientdelens IP-adress på Application Gateway v2 SKU är tidsgränsen för inaktivitet inställd på 180 sekunder och kan inte konfigureras.

Ja. Application Gateway återanvänder befintliga TCP-anslutningar med en serverdelsserver.

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-resurs eller dess offentliga IP-adress efter borttagningen. Du måste skapa en ny resurs.

I Application Gateway v1 SKU kan VIP-adressen ändras om du stoppar och startar programgatewayen. Men DNS-namnet som är associerat med programgatewayen ändras inte under gatewayens livslängd. Eftersom DNS-namnet inte ändras bör du använda ett CNAME-alias och peka det på DNS-adressen för programgatewayen. I Application Gateway v2 SKU är IP-adresser statiska, så IP-adressen och DNS-namnet ändras inte under programgatewayens livslängd.

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

En programgateway stöder endast en offentlig IP-adress per IP-protokoll. Om programgatewayen har konfigurerats som DualStack kan den ha stöd för två offentliga IP-adresser, en för IPv4 och en för IPv6.

Se Storleksöverväganden för Application Gateway-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 annan Application Gateway-resurs.

Ett enda undernät kan inte stödja både v2- och v1 Application Gateway-SKU:er.

Ja, men bara specifika scenarier. Mer information finns i Konfiguration av Application Gateway-infrastruktur.

Ja. Se Ändringar i en begäran.

Nya Application Gateway v1 SKU-distributioner kan ta upp till 20 minuter att etablera. Ändringar i 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. Processen kan dock ta längre tid beroende på typen av distribution. Distributioner över flera tillgänglighetszoner med många instanser kan till exempel ta mer än 6 minuter.

Uppdateringar initieras till Application Gateway tillämpas en uppdateringsdomän i taget. När varje uppdateringsdomäns instanser uppdateras fortsätter de återstående instanserna i andra uppdateringsdomäner att hantera trafik¹. Aktiva anslutningar töms korrekt från de instanser som uppdateras i upp till 5 minuter för att upprätta anslutningar till instanser i en annan uppdateringsdomän innan uppdateringen påbörjas. Under uppdateringen körs Application Gateway tillfälligt med reducerad maximal kapacitet, vilket bestäms av antalet konfigurerade instanser. Uppdateringsprocessen fortsätter endast till nästa uppsättning instanser om den aktuella uppsättningen instanser har uppgraderats.

¹ Vi rekommenderar att minst 2 instanser konfigureras för Application Gateway v1 SKU-distributioner för att säkerställa att minst en instans kan hantera trafik medan uppdateringar tillämpas.

Application Gateway stöder TLS/TCP-protokollproxy via dess Layer 4-proxy i förhandsversionen.

Application Gateways Layer 7-proxy med HTTP-protokoll (S) stöder inte e-postprotokoll som SMTP, IMAP och POP3. För vissa e-posttjänster som stöds, till exempel Outlook Web Access (OWA), ActiveSync och AutoDiscovery-trafik som använder HTTP(S)-protokoll, kan du dock använda Layer 7-proxy och deras trafik bör flöda igenom. (Obs! Undantag i WAF-reglerna kan krävas när du använder en WAF SKU).

Ja. Mer information finns i Migrera Azure Application Gateway och Brandvägg för webbprogram från v1 till v2.

Ja. Application Gateway v1 SKU stöds fortfarande. Vi rekommenderar starkt att du flyttar till v2 för att dra nytta av funktionsuppdateringarna i den SKU:n. Mer information om skillnaderna mellan v1- och v2-funktioner finns i Autoskalning och zonredundant Application Gateway v2. Du kan migrera Application Gateway v1 SKU-distributioner manuellt till v2 genom att följa migreringsdokumentet v1-v2.

Nej. Application Gateway v2 stöder inte proxybegäranden med NTLM- eller Kerberos-autentisering.

Namn på begäranderubriker kan innehålla alfanumeriska tecken och bindestreck. Namn på begäranderubriker som innehåller andra tecken ignoreras när en begäran skickas till serverdelsmålet. Namn på svarshuvud kan innehålla alfanumeriska tecken och specifika symboler enligt definitionen i RFC 7230.

Ja. Chromium browserv80-uppdateringen introducerade ett mandat på HTTP-cookies utan attributet SameSite som skulle behandlas som SameSite=Lax. Det innebär att tillhörighetscookien för Application Gateway inte skickas av webbläsaren i en kontext från tredje part.

För att stödja det här scenariot matar Application Gateway in en annan cookie som anropas ApplicationGatewayAffinityCORS utöver den befintliga ApplicationGatewayAffinity cookien. Dessa cookies liknar dem, men cookien ApplicationGatewayAffinityCORS har ytterligare två attribut: SameSite=None och Secure. Dessa attribut underhåller klibbiga sessioner även för begäranden mellan ursprung. Mer information finns i avsnittet Cookiebaserad tillhörighet.

En aktiv lyssnare är en lyssnare som är associerad med en regel och som skickar trafik till en serverdelspool. Alla lyssnare som bara omdirigerar trafik är inte en aktiv lyssnare. Lyssnare som är associerade med omdirigeringsregler anses inte vara aktiva. Om omdirigeringsregeln är en sökvägsbaserad regel måste alla sökvägar i omdirigeringsregeln omdirigera trafik, annars anses lyssnaren vara aktiv. Information om enskilda komponenter finns i Azure-prenumerations- och tjänstgränser, kvoter och begränsningar.

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

V2 SKU säkerställer automatiskt att nya instanser sprids över feldomäner och uppdateringsdomäner. Om du väljer zonredundans är de senaste instanserna också spridda över tillgänglighetszoner för att erbjuda zonindelad återhämtning av fel.

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

Ja. Du kan konfigurera anslutningsdränering för att ändra medlemmar i en serverdelspool utan avbrott. Mer information finns i avsnittet Anslut dränering i Application Gateway.

Ja, Application Gateway v2 SKU stöder automatisk skalning. Mer information finns i Autoskalning och zonredundant Application Gateway.

Nej. Instanser distribueras över uppgraderingsdomäner och feldomäner.

Ja.

Ja.

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

Om du har IP-anslutning kan Application Gateway kommunicera med instanser utanför det virtuella nätverk som den 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 serverdelspoolen använder du peering för virtuella nätverk eller Azure VPN Gateway.

Precis som alla DNS-matchare respekterar Application Gateway-resursen TTL-värdet (Time to Live) för serverdelsserverns DNS-post. När TTL upphör att gälla utför gatewayen en sökning för att uppdatera DNS-informationen. Om din programgateway under den här sökningen får problem med att få ett svar (eller om ingen DNS-post hittas) fortsätter gatewayen att använda det senast kända DNS-värdet för att hantera trafiken. Mer information finns i Så här fungerar en programgateway.

Instanserna av din programgateway använder det virtuella nätverkets DNS-konfiguration för namnmatchning. När du har ändrat dns-serverkonfigurationen måste du starta om (stoppa och starta) programgatewayen för att de nya DNS-servrarna ska tilldelas. Fram till dess kan FQDN-baserade namnmatchningar för utgående anslutning misslyckas.

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

Du kan bara flytta en programgateway mellan undernät inom samma virtuella nätverk. Det stöds med v1 med en offentlig och privat klientdel (dynamisk allokering) och v2 med endast en offentlig klientdel. Vi kan inte flytta programgatewayen till ett annat undernät om IP-konfigurationen för den privata klientdelen är statiskt allokerad. Programgatewayen ska vara i tillståndet Stoppad för att utföra den här åtgärden. Om du stoppar eller startar v1 ändras den offentliga IP-adressen. Den här åtgärden kan bara utföras med hjälp av 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ätet.

Nej. Tjänstslutpunktsprinciper för lagringskonton stöds inte i Application Gateway-undernätet och konfigurerar den blockerar Azure-infrastrukturtrafik.

Se Begränsningar för Application Gateway.

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 belastningsbalansera trafik i andra virtuella nätverk.

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

Mikrotjänstarkitektur stöds. Om du vill avsöka på olika portar måste du konfigurera flera serverdelsinställningar.

Nej.

Se Regler för bearbetningsordning.

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

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

Ja, du kan använda offentliga och privata lyssnare med samma portnummer för att samtidigt stödja offentliga och privata klienter. Om en nätverkssäkerhetsgrupp (NSG) är associerad med programgatewayens undernät kan en specifik inkommande regel behövas beroende på dess konfiguration. Få mer information.

Application Gateway v2 stöder IPv4- och IPv6-klientdelar. För närvarande är IPv6-stöd endast tillgängligt för nya programgatewayer. För att stödja IPv6 bör det virtuella nätverket vara en dubbel stack. Application Gateway v1 stöder inte virtuella nätverk med dubbla staplar.

Application Gateway v1 SKU:er kan köras i ett FIPS 140-2-godkänt driftsläge, vilket ofta kallas "FIPS-läge". FIPS-läge anropar en FIPS 140-2-verifierad kryptografimodul som säkerställer FIPS-kompatibla algoritmer för kryptering, hashning och signering när det är aktiverat. För att säkerställa att FIPS-läget är aktiverat FIPSMode måste inställningen konfigureras via PowerShell, Azure Resource Manager-mallen eller REST-API:et när prenumerationen har registrerats för att aktivera konfigurationen av FIPSmode.

Application Gateway v2 stöder för närvarande endast privat IP-klientdelskonfiguration (ingen offentlig IP-adress) via offentlig förhandsversion. Mer information finns i Distribution av privat Application Gateway (förhandsversion).

För den aktuella allmänna tillgänglighetssupporten stöder Application Gateway v2 följande kombinationer:

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

Följ den här processen om du bara vill begränsa trafik till privata IP-adresser med aktuella funktioner:

1. Skapa en programgateway med både offentlig och privat klientdels-IP-adress.

2. Skapa inga lyssnare för den offentliga IP-adressen för klientdelen. Application Gateway lyssnar inte på någon trafik på den offentliga IP-adressen om inga lyssnare har skapats för den.

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

   1. Tillåt trafik från Källa som tjänsttaggen GatewayManager, Mål som alla och målporten som 65200-65535. Det här portintervallet krävs för Azure-infrastrukturkommunikation. Dessa portar skyddas (låsta) av certifikatautentisering. Externa entiteter, inklusive gatewayanvändarens administratörer, kan inte initiera ändringar på dessa slutpunkter utan lämpliga certifikat på plats.

   2. Tillåt trafik från källan som tjänsttaggen AzureLoadBalancer och målporten som alla.

   3. Neka all inkommande trafik från Källan som tjänsttaggen Internet och målporten som alla. Ge den här regeln minst prioritet i reglerna för inkommande trafik.

   4. Behåll standardreglerna som AllowVNetInBound så att åtkomsten till en privat IP-adress inte blockeras.

   5. Utgående internetanslutning kan inte blockeras. Annars får du problem med loggning och mått.

Exempel på NSG-konfiguration för åtkomst med endast privat IP-adress:

Du kan använda Azure PowerShell eller Azure CLI för att stoppa och starta Application Gateway. När du stoppar och startar Application Gateway stoppas och startas även faktureringen . En PUT-åtgärd som utförs på en stoppad programgateway (som att lägga till tagg, hälsoavsökning eller lyssnare) utlöser en start. Vi rekommenderar att du stoppar programgatewayen när konfigurationen har uppdaterats.

# 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 stöder självsignerade certifikat, certifikatutfärdarcertifikat (CA), EV-certifikat (Extended Validation), SAN-certifikat (Multi-Domain) 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 stöder TLS-avlastning och TLS från slutpunkt till slutpunkt, som omkrypterar trafik till serverdelen.

Ja. Du kan konfigurera Application Gateway för att neka TLS1.0, TLS1.1 och TLS1.2. Som standard är SSL 2.0 och 3.0 redan inaktiverade 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 serverdelshantering.

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

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

Application Gateway stöder upp till 100 autentiseringscertifikat.

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

För flera domänbaserade (värdbaserade) routningar kan du skapa lyssnare med flera platser, konfigurera lyssnare som använder HTTPS som protokoll och associera lyssnarna med routningsreglerna. Mer information finns i Hantera flera webbplatser med hjälp av Application Gateway.

Nej. Använd endast alfanumeriska tecken i .pfx-fillösenordet.

CA/Browser-medlemmar 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 teknikcommunityn som inte uppfyllde branschstandarderna för offentligt betrodda certifikatutfärdare. Rapporterna om de icke-kompatibla certifikatutfärdarna finns här:

• Bugg 1649951
• Bugg 1650910

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

Information om hur du kontrollerar om certifikat som används av ditt program har återkallats finns i DigiCerts meddelande och spåraren för återkallade certifikat. Om dina certifikat har återkallats eller kommer att återkallas måste du begära nya certifikat från ca-leverantören som används i dina program. Information om hur du undviker att programmets tillgänglighet avbryts på grund av att certifikat oväntat återkallas eller för att uppdatera ett certifikat som har återkallats finns i Återkallande av icke-kompatibla certifikatutfärdare som potentiellt påverkar kundens Azure-tjänster.

Information som är specifik för Application Gateway:

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

• Ogiltigt certifikat/återkallat certifikat
• Anslutningens tidsgräns uppnåddes
• HTTP 502

För att undvika avbrott i ditt program på grund av det här problemet eller för att återisera en ca som har återkallats, måste du vidta följande åtgärder:

1. Kontakta certifikatleverantören om hur du återutfärdar dina certifikat.
2. När de har återutfärdats uppdaterar du dina certifikat på Application Gateway/WAF med den fullständiga förtroendekedjan (löv-, mellan- och rotcertifikat). Baserat på var du använder certifikatet, antingen på lyssnaren eller HTTP-inställningarna för programgatewayen, följer du stegen här för att uppdatera certifikaten. Mer information finns i de dokumentationslänkar som nämns.
3. Uppdatera serverdelsprogramservrarna så att de använder det återutgivna certifikatet. Beroende på vilken serverdelsserver du använder kan stegen för certifikatuppdatering variera. Sök efter dokumentationen från leverantören.

Så här uppdaterar du certifikatet i lyssnaren:

1. Öppna din Application Gateway-resurs i Azure-portalen.
2. Öppna lyssnarinställningarna som är associerade med certifikatet.
3. Välj Förnya eller redigera markerat certifikat.
4. Ladda upp ditt nya PFX-certifikat med lösenordet och välj Spara.
5. Öppna webbplatsen och kontrollera om webbplatsen fungerar som förväntat. Mer information finns i Förnya Application Gateway-certifikat.

Om du refererar till certifikat från Key Vault i Application Gateway-lyssnaren rekommenderar vi följande steg för en snabb ändring:

1. I Azure-portalen går du till dina Key Vault-inställningar som är associerade med programgatewayen.
2. Lägg till eller importera det återutgivna certifikatet i ditt arkiv. Mer information finns i Snabbstart: Skapa ett nyckelvalv med azure-portalen.
3. När certifikatet har importerats går du till inställningarna för Application Gateway-lyssnaren och under Välj ett certifikat från Key Vault väljer du listrutan Certifikat och väljer det nyligen tillagda certifikatet.
4. Välj Spara. Mer information om TLS-avslutning på Application Gateway med Key Vault-certifikat finns i TLS-avslutning med Key Vault-certifikat.

Så här uppdaterar du certifikatet i HTTP-inställningarna:

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

1. Öppna din Application Gateway-resurs i Azure-portalen.
2. Öppna DE HTTP-inställningar som är associerade med certifikatet.
3. Välj Lägg till certifikat, ladda upp det återutgivna certifikatet och välj Spara.
4. Du kan ta bort det gamla certifikatet senare genom att välja knappen ... alternativ bredvid det gamla certifikatet. Välj Ta bort och välj sedan Spara. Mer information finns i Konfigurera TLS från slutpunkt till slutpunkt med hjälp av Application Gateway med portalen.

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.

Ja. Både Layer 7- och Layer 4-routning via programgatewayen använder samma IP-konfiguration på klientdelen. På så sätt kan du dirigera alla dina klienter till en enda IP-adress (offentlig eller privat) och samma gatewayresurs dirigerar dem baserat på de konfigurerade lyssnarprotokollen och portarna.

Även om HTTP-trafik (S) kan hanteras via L4-proxyprotokoll, rekommenderar vi inte att du gör det. L7-proxylösningen för Application Gateway ger större kontroll och säkerhet över HTTP(S)-protokollen via avancerade funktioner som Omskrivningar, Sessionstillhörighet, Omdirigering, WebSockets, WAF med mera.

Resursegenskaperna för Layer 4-funktioner skiljer sig från Layer 7-funktionerna. När du använder REST API eller CLI måste du därför använda följande egenskaper.

• REST-API
• CLI

Nej. Du kan inte korslänka layer 4- och layer 7-egenskaper. Därför kan du med en routningsregel endast länka en lyssningsfunktion av Layer 4-typ till en serverdelsinställning av Layer 4-typ.

Du kan inte använda samma namn för en L7 (httpListeners) och L4 (lyssnare). Detta gäller även för andra L4-egenskaper som backend Inställningar Collection och routingRules.

Absolut. På samma sätt som med Layer 7-proxyn kan du lägga till en privat slutpunkt i serverdelspoolen för din programgateway. Den här privata slutpunkten måste distribueras i ett intilliggande undernät i samma virtuella nätverk för din programgateway.

Den använder inte Keepalive för serverdelsanslutningar. För varje inkommande begäran på klientdelslyssnaranslutningen initierar Application Gateway en ny serverdelsanslutning för att uppfylla den begäran.

Serverdelsservern ser IP-adressen för programgatewayen. För närvarande stöder vi inte "Klient-IP-bevarande" genom vilket serverdelsprogrammet kan göras medvetet om den ursprungliga klientens IP-adress.

Samma SSL-principkonfiguration gäller för både Layer 7 (HTTPS) och Layer 4 (TLS). För närvarande stöder vi inte SSL-profil (lyssnarspecifik SSL-princip eller ömsesidig autentisering) för TLS-lyssnare.

Nej. Routning av en klient till samma serverdelsserver stöds inte just nu. Anslutningarna distribueras på ett resursallokeringssätt till servrarna i en serverdelspool.

Ja, autoskalningsfunktionen fungerar även för toppar och minskningar av trafiken för TLS- eller TCP-protokoll.

Waf-funktionerna (Web Application Firewall) fungerar inte för Layer 4-användning.

Nej. UDP-stöd är inte tillgängligt just nu.

Kubernetes gör det möjligt att skapa deployment och service resurser för att exponera en grupp poddar internt i klustret. För att exponera samma tjänst externt definieras en Ingress resurs som tillhandahåller belastningsutjämning, TLS-avslutning och namnbaserad virtuell värd. För att uppfylla den här Ingress resursen krävs en ingresskontrollant som lyssnar efter ändringar Ingress i resurser och konfigurerar lastbalanseringsprinciperna.

Application Gateway Ingress Controller (AGIC) tillåter att Application Gateway används som ingress för en Azure Kubernetes-tjänst, även kallat ett AKS-kluster.

För närvarande kan en instans av en ingresskontrollant endast associeras till en programgateway.

AGIC försöker automatiskt associera routningstabellresursen till Application Gateway-undernätet, men kan misslyckas på grund av bristande behörigheter från AGIC. Om AGIC inte kan associera routningstabellen till Application Gateway-undernätet visas ett fel i AGIC-loggarna. I det här fallet måste du manuellt associera routningstabellen som skapats av AKS-klustret till Application Gateways undernät. Mer information finns i Användardefinierade vägar som stöds.

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

Skillnaderna mellan AGIC som distribueras via Helm jämfört med distribueras som ett AKS-tillägg finns i Skillnaden mellan Helm-distribution och AKS-tillägg.

Skillnaderna mellan AGIC som distribueras via Helm jämfört med distribueras som ett AKS-tillägg finns i Skillnaden mellan Helm-distribution och AKS-tillägg, särskilt tabellerna som dokumenterar vilka scenarier som stöds av AGIC som distribueras via Helm i stället för ett AKS-tillägg. När du distribuerar via Helm kan du i allmänhet testa betafunktioner och släppa kandidater 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 dubbelriktad autentisering mellan en klient och en server. Ömsesidig autentisering med Application Gateway gör för närvarande att gatewayen kan verifiera att klienten skickar begäran, vilket är klientautentisering. Vanligtvis är klienten den enda som autentiserar programgatewayen. Eftersom Application Gateway nu också kan autentisera klienten blir det ömsesidig autentisering där Application Gateway och klienten autentiserar varandra ömsesidigt.

Nej, ömsesidig autentisering är för närvarande endast mellan klientdelsklienten och programgatewayen. Ömsesidig autentisering i serverdelen stöds för närvarande inte.

Application Gateway innehåller tre loggar:

• ApplicationGatewayAccessLog: Åtkomstloggen innehåller varje begäran som skickas till programgatewayens klientdel. Data inkluderar anroparens IP-adress, begärda URL:er, svarssvarstid, 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 hanteras, antal misslyckade begäranden och felfritt antal serverdelsinstanser.
• ApplicationGatewayFirewallLog: För programgatewayer som du konfigurerar med WAF innehåller brandväggsloggen begäranden som loggas via antingen identifieringsläge eller förebyggande läge.

Alla loggar samlas in var 60:e sekund. Mer information finns i Serverdelshälsa, 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 menyfönstret i 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 aviseringsaviseringar.

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

Du kan också använda en Resource Manager-mall som installerar och kör den populära GoAccess-logganalysen för Application Gateway-åtkomstloggar. GoAccess tillhandahåller värdefull HTTP-trafikstatistik, till exempel unika besökare, begärda filer, värdar, operativsystem, webbläsare och HTTP-statuskoder. Mer information finns i GitHub i Readme-filen i resource manager-mallmappen.

Vanligtvis ser du en okänd status när åtkomsten till serverdelen blockeras av en NSG, anpassad DNS eller användardefinierad routning i Application Gateway-undernätet. Mer information finns i Serverdelshälsa, diagnostikloggning och mått för Application Gateway.

Om du har en NSG på Application Gateway v2-undernätet (Standard_v2, WAF_v2) på grund av aktuella plattformsbegränsningar och om du har aktiverat NSG-flödesloggar på den ser du ett icke-förutbestämt beteende. Det här scenariot stöds för närvarande inte.

Application Gateway flyttar eller lagrar inte kunddata från den region där den distribueras.

Nästa steg

• Mer information om Application Gateway finns i Vad är Azure Application Gateway.
• Mer information om TLS-avslutning och TLS från slutpunkt till slutpunkt med Application Gateway finns i Aktivera TLS från slutpunkt till slutpunkt på Azure Application Gateway.