Az Application Gateway használatával kapcsolatos gyakori kérdések

Megjegyzés

Javasoljuk, hogy az Azure Az PowerShell-modult használja a Azure használatához. Első lépésként lásd: Install Azure PowerShell. Az Az PowerShell-modulra való migrálásról az Migrate Azure PowerShell az AzureRM-ből az Az című témakörben olvashat.

A Azure Application Gateway az alábbi gyakori kérdéseket kérdezi fel.

Általános

Mi az Application Gateway?

Azure Application Gateway egy alkalmazáskézbesítési vezérlőt biztosít szolgáltatásként. Különböző 7. rétegbeli terheléselosztási képességeket kínál az alkalmazások számára. Ez a szolgáltatás magas rendelkezésre állású, méretezhető és az Azure által teljes mértékben felügyelt.

Milyen funkciókat támogat az Application Gateway?

Az Application Gateway támogatja az automatikus skálázást, a TLS-kiszervezést és a végpontok közötti TLS-t, a webalkalmazási tűzfalat (WAF), a cookie-alapú munkamenet-affinitást, az URL-alapú útválasztást, a többhelyes üzemeltetést és egyéb funkciókat. A támogatott funkciók teljes listáját az Application Gateway bemutatása című témakörben találja.

Miben különbözik az Application Gateway és a Azure Load Balancer?

Az Application Gateway egy 7. rétegbeli terheléselosztó, ami azt jelenti, hogy csak webes forgalommal (HTTP, HTTPS, WebSocket és HTTP/2) működik. Támogatja az olyan képességeket, mint a TLS-lezárás, a cookie-alapú munkamenet-affinitás és a körforgó terheléselosztás. Load Balancer terheléselosztja a forgalmat a 4. rétegben (TCP vagy UDP).

Milyen protokollokat támogat az Application Gateway?

Az Application Gateway támogatja a HTTP, a HTTPS, a HTTP/2 és a WebSocket használatát.

Hogyan támogatja az Application Gateway a HTTP/2-t?

Lásd: HTTP/2-támogatás.

Milyen erőforrások támogatottak egy háttérkészlet részeként?

Lásd: Támogatott háttérerőforrások.

Milyen régiókban érhető el az Application Gateway?

Az Application Gateway v1 (Standard és WAF) 2026. április 28-tól megszűnik, és nem támogatott. Az Application Gateway v2 (Standard_v2 és WAF_v2) rendelkezésre állásáról az Application Gateway v2 támogatott régiói című témakörben olvashat.

Ez az üzembe helyezés dedikált az előfizetésemhez, vagy meg van osztva az ügyfelek között?

Az Application Gateway egy dedikált üzembe helyezés a virtuális hálózaton.

Támogatja az Application Gateway a HTTP–HTTPS átirányítást?

Az átirányítás támogatott. Tekintse meg az Application Gateway átirányításának áttekintését.

Milyen sorrendben dolgozzák fel a figyelőket?

Tekintse meg a figyelő feldolgozásának sorrendjét.

Hol található az Application Gateway IP-címe és DNS-címe?

Ha nyilvános IP-címet használ végpontként, az IP- és DNS-adatokat a nyilvános IP-címerőforrásban találja. Vagy megtalálhatja a Azure portálon, az Application Gateway áttekintési oldalán. Ha belső IP-címeket használ, keresse meg az áttekintési oldalon található információkat. A 2023. május 1. után létrehozott átjárók esetében az 1. verziójú termékváltozat esetében nem lesz automatikusan hozzárendelve alapértelmezett DNS-név a nyilvános IP-erőforráshoz. A v2 termékváltozat esetében nyissa meg a nyilvános IP-erőforrást, és válassza a Konfiguráció lehetőséget. A DNS-név konfigurálásához elérhető a DNS-névcímke (nem kötelező) mező.

Mik a Keep-Alive időtúllépés és a TCP tétlen időtúllépés alapértelmezései?

Keep-Alive az időtúllépés azt szabályozza, hogy az Application Gateway mennyi ideig várja meg, amíg az ügyfél egy állandó kapcsolaton egy másik HTTP-kérést küld, mielőtt újrahasználja vagy bezárja azt. A TCP tétlen időtúllépése szabályozza, hogy a TCP-kapcsolat mennyi ideig legyen nyitva, ha nincs tevékenység.

HTTP/1.1-kapcsolatok esetén az Keep-Alive Application Gateway v1 és v2 termékváltozatának időtúllépése 120 másodperc. Privát IP-címek esetén az érték nem konfigurálható 5 perces TCP-tétlenségi időtúllépéssel. A TCP tétlenségi időkorlátja az Application Gateway v1 és v2 SKU-jának külső virtuális IP-címén (VIP) 4 perc alapértelmezett érték. A TCP tétlen időtúllépési értékét 1- és 2-s verziójú Application Gateway-példányokon 4 perc és 30 perc közötti értékre konfigurálhatja. Az 1-es és a 2-es verziójú Application Gateway-példányok esetében is az Application Gateway nyilvános IP-címére kell lépnie, és módosítania kell a TCP tétlenség időtúllépését a portál nyilvános IP-címének Konfiguráció paneljén. A nyilvános IP-cím TCP-tétlen időtúllépési értékét a PowerShellen keresztül az alábbi parancsok futtatásával állíthatja be:

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

Az Application Gateway v2 termékváltozatának előtérbeli IP-címéhez való HTTP/2-kapcsolatok esetén az üresjárati időtúllépés 180 másodpercre van állítva, és nem konfigurálható.

Az ütközés és a váratlan viselkedés megakadályozása érdekében győződjön meg arról, hogy a TCP tétlen időtúllépése megegyezik vagy hosszabb, mint az életben tartási időtúllépés.

Az Application Gateway újra felhasználja a háttérkiszolgálóval létrehozott TCP-kapcsolatot?

Igen. Az Application Gateway újra felhasználja a meglévő TCP-kapcsolatokat egy háttérkiszolgálóval.

Átnevezhetem az Application Gateway-erőforrásomat?

Nem Az Application Gateway-erőforrás nem nevezhető át. Egy másik nevű új erőforrást kell létrehoznia.

Van mód az Application Gateway-erőforrás és a nyilvános IP-cím visszaállítására, ha törölték?

Nem A törlés után nem állítható vissza az Application Gateway-erőforrás vagy annak nyilvános IP-címe. Létre kell hoznia egy új erőforrást.

Változik az IP- vagy DNS-név az Application Gateway élettartama során?

Az Application Gateway v1 termékváltozatban a VIP megváltozhat, ha leállítja és elindítja az Application Gatewayt. Az application gatewayhez társított DNS-név azonban nem változik az átjáró élettartama során. Mivel a DNS-név nem változik, egy CNAME alias-t kell használnia, amely az alkalmazás átjáró DNS-címére mutat. Az Application Gateway v2 termékváltozatban az IP-címek statikusak, így az IP-cím és a DNS-név nem változik az Application Gateway élettartama során.

Támogatja az Application Gateway a statikus IP-címet?

Igen. Az Application Gateway v2 termékváltozata támogatja a statikus nyilvános IP-címeket és a statikus belső IP-címeket. A v1 termékváltozat támogatja a statikus belső IP-címeket.

Támogatja az Application Gateway több nyilvános IP-címet az átjárón?

Az Application Gateway IP-protokollonként csak egy nyilvános IP-címet támogat. Ha az application gateway DualStackként van konfigurálva, két nyilvános IP-címet támogat, egyet az IPv4-hez és egyet az IPv6-hoz.

Mekkora legyen az alhálózatom az Application Gatewayhez?

Lásd az Application Gateway alhálózatának méretére vonatkozó szempontokat.

Üzembe helyezhetek egynél több Application Gateway-erőforrást egyetlen alhálózaton?

Igen. Egy adott Application Gateway-telepítés több példányán kívül egy másik egyedi Application Gateway-erőforrást is kiépítheti egy meglévő alhálózatra, amely egy másik Application Gateway-erőforrást tartalmaz.

Egyetlen alhálózat nem támogatja a v2 és a v1 Application Gateway termékváltozatokat.

Támogatja az Application Gateway v2 a felhasználó által definiált útvonalakat?

Igen, de csak bizonyos forgatókönyvek. További információ: Application Gateway-infrastruktúra konfigurációja.

Támogatja az Application Gateway az x-forwarded-for fejléceket?

Igen. Lásd a kérések módosításait.

Mennyi ideig tart az Application Gateway egy példányának üzembe helyezése? Működni fog az Application Gateway a frissítés közben?

A v2 SKU-t használó legtöbb üzembe helyezés körülbelül 6 percet vesz igénybe. A folyamat azonban az üzembe helyezés típusától függően hosszabb időt is igénybe vehet. Több rendelkezésre állási zónát és számos példányt érintő telepítések például több mint 6 percet is igénybe vehetnek.

Használhatom a Exchange Server az Application Gateway háttérrendszereként?

Az Application Gateway a 4. rétegbeli proxyn keresztül támogatja a TLS/TCP protokollproxyt az előzetes verzióban.

Az Application Gateway 7. rétegbeli proxyja HTTP(S) protokollokkal nem támogatja az olyan e-mail protokollokat, mint az SMTP, az IMAP és a POP3. Egyes támogató e-mail-szolgáltatások, például az Outlook Web Access (OWA), az ActiveSync és az AutoDiscovery http(s) protokollt használó forgalma esetén azonban használhatja a 7. rétegbeli proxyt, és a forgalomnak át kell haladnia. (Megjegyzés: Előfordulhat, hogy WAF SKU használatakor szükség van a WAF-szabályok kizárására).

Elérhető útmutatás a v1 termékváltozatról a v2 termékváltozatra való migráláshoz?

Igen. További információért lásd: Az Azure Application Gateway és a Webalkalmazás-tűzfal migrálása v1-ről v2-re.

Támogatott az Application Gateway v1 termékváltozata?

Nem Az Application Gateway v1 termékváltozata 2026. április 28-án megszűnt, és már nem támogatott. Javasoljuk, hogy a legkorábbi időpontban térjen át a v2-be, mivel a fennmaradó V1-átjárók leszerelési folyamatát megkezdjük.

Az Application Gateway v2 támogatja az NTLM- vagy Kerberos-hitelesítéssel rendelkező proxykéréseket?

Igen. Az Application Gateway v2 mostantól támogatja az NTLM- vagy Kerberos-hitelesítéssel rendelkező proxykéréseket. További információ: Dedikált háttérkapcsolat.

Miért nem jelennek meg egyes fejlécértékek, amikor a kérelmeket továbbítják az alkalmazásnak?

A kérelemfejlécek neve tartalmazhat alfanumerikus karaktereket és kötőjeleket. Az olyan kérelemfejlécek neveit, amelyek más karaktereket tartalmaznak, elvetik, amikor kérést küld a rendszer a háttérrendszer célpontjához. A válaszfejlécek nevei az RFC 7230-ban meghatározott alfanumerikus karaktereket és szimbólumokat tartalmazhatnak.

Igen. A Chromium browserv80 frissítése olyan http-cookie-kat vezetett be, amelyeknek a SameSite attribútuma nem kezelhető.SameSite=Lax Ez azt jelenti, hogy az Application Gateway affinitási cookie-t a böngésző nem küldi el harmadik féltől származó környezetben.

A forgatókönyv támogatásához az Application Gateway a meglévő ApplicationGatewayAffinityCORS cookie mellett egy másik, úgynevezett ApplicationGatewayAffinity cookie-t is injektál. Ezek a cookie-k hasonlóak, de a ApplicationGatewayAffinityCORS cookie-hoz még két attribútum tartozik: SameSite=None és Secure. Ezek az attribútumok még a forrásközi kérések esetében is megtartják a perzisztens munkameneteket. További információ: Cookie-alapú affinitás szakasz.

Mi az aktív figyelő és az inaktív figyelő?

Az aktív hallgató olyan hallgató, amely egy szabályhoz van társítva, és forgalmat küld egy háttérkészletnek. Minden olyan figyelő, amely csak átirányítja a forgalmat, nem aktív figyelő. Az átirányítási szabályokhoz társított figyelők nem tekinthetők aktívnak. Ha az átirányítási szabály egy útvonalalapú szabály, az átirányítási szabályban szereplő összes elérési útnak átirányítania kell a forgalmat, különben a figyelő aktívnak minősül. Az egyes összetevőkre vonatkozó korlát részleteiért lásd: Azure előfizetési és szolgáltatási korlátok, kvóták és korlátozások.

Miért látható az Application Gatewayben a(z) „SKU family Generation_1”, pedig v2-es SKU-t (WAF_v2 vagy Standard_v2) használok?

Ez várható, és nem jelenti azt, hogy az átjáró a v1 verzión fut. Az "SKU-család" és az "termékváltozat neve" két különálló tulajdonság:

Tulajdonság Mit jelent ez? Példa
Termékváltozat neve A kiválasztott termékszint. Meghatározza a funkciókat, a teljesítményt és a viselkedést. Standard_v2, WAF_v2
SKU-család Az alapul szolgáló hardvergeneráció belső Azure-platformcímkéje. Csak tájékoztató jellegű. Generation_1
  • Ha az SKU neve Standard_v2 vagy WAF_v2, akkor Application Gateway v2-t használ az összes v2-es képességgel – függetlenül attól, hogy mi szerepel a SKU-családnál.
  • SKU-család Azure automatikusan hozzárendeli. A portálon, az ARM-ben, a Bicepben vagy a CLI-ben nem módosítható, és nincs is rá szükség. Nincs hatással a működésre, a teljesítményre, a funkciókra vagy a számlázásra.

Teljesítmény

Hogyan támogatja az Application Gateway a magas rendelkezésre állást és a méretezhetőséget?

A v2 termékváltozat automatikusan biztosítja, hogy az új példányok el legyenek osztva a hibatartományok és frissítési tartományok között. Ha zónaredundanciát választ, a legújabb példányok szét vannak osztva a rendelkezésre állási zónák között, hogy az zónális meghibásodások esetén rugalmasságot nyújtson.

Hogyan vészhelyreállítási forgatókönyvet valósít meg az adatközpontokban az Application Gateway használatával?

A Azure Traffic Manager használatával több alkalmazásátjáró között oszthatja el a forgalmat különböző adatközpontokban.

Támogatja az Application Gateway a kapcsolat kiürítését?

Igen. A háttérkészleten belüli tagok megszakítás nélküli módosításához beállíthatja a kapcsolatleürítést. További információért lásd az Application Gateway kapcsolatürítés szakaszát.

Támogatja az Application Gateway az automatikus skálázást?

Igen, az Application Gateway v2 termékváltozata támogatja az automatikus skálázást. További információkért lásd: Automatikus skálázás és zónaredundanciás Application Gateway.

A manuális vagy automatikus felskálázás vagy a leskálázás leállást okoz?

Nem A példányok a frissítési tartományok és a hiba tartományok között vannak elosztva.

Válthatok standardról WAF termékváltozatra megszakítás nélkül?

Igen.

Megváltoztathatom a példány méretét közepesről nagyra megszakítás nélkül?

Igen.

Maintenance

Hogyan kezeli az Application Gateway a rutinszerű karbantartást?

Az Application Gatewayen kezdeményezett frissítéseket a rendszer egyszerre csak egy frissítési tartományra alkalmazza. Az egyes frissítési tartományok példányainak frissítése során a többi frissítési tartományban lévő többi példány továbbra is kiszolgálja a forgalmat. Az aktív kapcsolatokat a rendszer akár 5 percig is zökkenőmentesen üríti ki a frissített példányokból, hogy a frissítés megkezdése előtt kapcsolatot létesítsen egy másik frissítési tartományban lévő példányokkal. A frissítési folyamat csak akkor halad tovább a következő példánykészletre, ha az aktuális példánykészlet frissítése sikeresen megtörtént.

Azure Application Gateway támogatja a MaxSurge funkciót is, amely lehetővé teszi az új példányok üzembe helyezését a működés közbeni frissítések során anélkül, hogy a meglévőket offline állapotba kellene helyeznie. Lehetővé teszi az ügyfelek számára, hogy kapacitáscsökkenés nélkül térjenek át az újabb átjáróverziókra. A MaxSurge automatikusan engedélyezve van az Application Gatewayen, és nincs szükség konfigurálásra.

Jegyzet: A MaxSurge által használt ideiglenes példányok kiépítéséhez további IP-terület szükséges. Ha a frissítés során nem áll rendelkezésre elegendő IP-cím, az Application Gateway visszaáll a hagyományos frissítési módszerre, ami a példányok száma alapján csökkentheti a maximális kapacitást.

Konfiguráció

Az Application Gateway mindig virtuális hálózaton van üzembe helyezve?

Igen. Az Application Gateway mindig egy virtuális hálózati alhálózaton van üzembe helyezve. Ez az alhálózat csak alkalmazásátjárókat tartalmazhat. További információ: Virtuális hálózat és alhálózat követelményei.

Kommunikálhat-e az Application Gateway olyan példányokkal, amelyek a virtuális hálózatán vagy az előfizetésén kívül vannak?

Ha rendelkezik IP-kapcsolattal, az Application Gateway képes a virtuális hálózaton kívüli példányokkal kommunikálni. Az Application Gateway a benne lévő előfizetésen kívüli példányokkal is tud kommunikálni. Ha belső IP-címeket szeretne használni háttérkészlet-tagokként, használja virtual network peering vagy Azure VPN Gateway.

Hogyan frissül egy FQDN-alapú háttérkiszolgáló IP-címe?

A DNS-feloldóhoz hasonlóan az Application Gateway-erőforrás is tiszteletben tartja a háttérkiszolgáló DNS-rekordjának Élettartam (TTL) értékét. A TTL lejárta után az átjáró végrehajt egy keresést a DNS-adatok frissítéséhez. A keresés során, ha az application gateway problémát tapasztal a válasz kérése során (vagy nem található DNS-rekord), az átjáró továbbra is az utolsó ismert dns-értéket használja a forgalom kiszolgálásához. További információ: Az Application Gateway működése.

Miért jelenik meg 502 hiba vagy nem megfelelő állapotú háttérkiszolgáló a virtuális hálózat DNS-kiszolgálóinak módosítása után?

Az Application Gateway példányai a virtuális hálózat DNS-konfigurációját használják a névfeloldáshoz. Miután módosította a DNS-kiszolgáló konfigurációját, újra kell indítania (leállítani, majd újraindítani) az alkalmazásátjárót, hogy az új DNS-kiszolgálók legyenek hozzárendelve. Addig előfordulhat, hogy a FQDN-alapú névfeloldások sikertelenek lesznek kimenő kapcsolatok esetén.

Támogatja az Application Gateway a rövid neveket vagy az egycímkés tartományneveket?

Igen. Az Application Gateway a háttérkészletekben lévő rövid neveket (például server1 vagy backend) fel tudja oldani, ha a DNS-kiszolgáló meg tudja oldani őket. Ez bármilyen hálózati beállításban működik, beleértve a helyszíni, Azure virtuális hálózatokat vagy hibrid környezeteket.

Annak érdekében, hogy a rövid névfeloldás működjön:

  • A virtuális hálózat DNS-kiszolgálójának képesnek kell lennie a rövid név IP-címgé alakítására
  • A rövid nevek ugyanúgy működnek, mint a teljes tartománynevek (FQDN-ek) – az átjáró megkérdezi a DNS-kiszolgálót az IP-címről, és használja azt

Megjegyzés: Ha Azure alapértelmezett DNS-ét (168.63.129.16) használja, az csak az ugyanazon a virtuális hálózaton lévő erőforrások rövid nevét tudja feloldani. A helyszíni rövid nevek feloldásához állítson be egy egyéni DNS-kiszolgálót, amely képes kezelni a belső tartományneveket.

További információ: Az Application Gateway DNS-feloldásának ismertetése.

Üzembe helyezhetek bármi mást az Application Gateway alhálózatán?

Nem Az alhálózaton azonban más alkalmazásátjárókat is üzembe helyezhet.

Módosíthatom egy meglévő application gateway virtuális hálózatát vagy alhálózatát?

Az alkalmazásátjárók csak ugyanazon virtuális hálózaton belüli alhálózatok között helyezhetők át. Az 1. verzió támogatott nyilvános és privát előtérrendszerrel (dinamikus foglalással), míg a 2. verzió csak nyilvános előtérrendszerrel rendelkezik. Az application gateway nem helyezhető át egy másik alhálózatra, ha a privát előtérbeli IP-konfiguráció statikusan van lefoglalva. A művelet végrehajtásához az application gatewaynek le kell állítania a leállított állapotot. Az 1. verzió leállítása vagy indítása módosítja a nyilvános IP-címet. Ez a művelet csak a Azure PowerShell és a Azure CLI használatával végezhető el a következő parancsok futtatásával:

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

További információ: 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>

Támogatottak a hálózati biztonsági csoportok az Application Gateway alhálózatán?

Lásd: Hálózati biztonsági csoportok az Application Gateway alhálózatán.

Támogatja az Application Gateway alhálózata a felhasználó által megadott útvonalakat?

Lásd az Application Gateway alhálózatán támogatott, felhasználó által megadott útvonalakat.

Támogatottak a szolgáltatásvégpont-szabályzatok az Application Gateway alhálózatában?

Nem Szolgáltatási végpontszabályzatok tárfiókokhoz nem támogatottak az Application Gateway alhálózatában, és ha ezek konfigurálva vannak, az blokkolja az Azure infrastruktúra forgalmát.

Mik az Application Gateway korlátai? Növelhetem ezeket a korlátokat?

Lásd az Application Gateway korlátait.

Használhatom egyidejűleg az Application Gatewayt külső és belső forgalomhoz is?

Igen. Az Application Gateway egy belső IP-címet és egy külső IP-címet támogat alkalmazásátjárónként.

Támogatja az Application Gateway a virtuális hálózatok közötti társviszony-létesítést?

Igen. A virtuális hálózatok közötti társviszony-létesítés segít a többi virtuális hálózat forgalmának terheléselosztásában.

Beszélhetek helyszíni kiszolgálókkal, ha Azure ExpressRoute vagy VPN-alagutak csatlakoznak hozzájuk?

Igen, amíg a forgalom engedélyezett.

Egy háttérkészlet számos alkalmazást kiszolgálhat különböző portokon?

A mikroszolgáltatás-architektúra támogatott. A különböző portokon való mintavételhez több háttérbeállítást kell konfigurálnia.

Az egyéni keresések támogatják a helyettesítő karaktereket vagy reguláris kifejezéseket a válaszadatokon?

Nem

Hogyan dolgozzák fel az útválasztási szabályokat az Application Gatewayben?

Lásd a feldolgozási szabályok sorrendjét.

Az egyéni mintavételek esetében mit jelent a **Host** mező?

A Host mező azt a nevet adja meg, amelyre a próbát küldeni kell, amikor többhelyes konfigurációt állított be az Application Gatewayen. Ellenkező esetben használja a 127.0.0.1-et. Ez az érték eltér a virtuális gép gazdagépének nevétől. Formátuma a <protokoll>://<gazdagép>:<port><elérési útja>.

Engedélyezhetem, hogy az Application Gateway csak néhány forrás IP-címhez férhessen hozzá?

Igen. Lásd: Adott forrás IP-címekhez való hozzáférés korlátozása.

Használhatom ugyanazt a portot a külső és belső hallgatókhoz?

Igen, az azonos portszámú nyilvános és privát figyelőkkel egyidejűleg támogathatja a nyilvános és magánügyfeleket. Ha egy hálózati biztonsági csoport (NSG) az application gateway alhálózatához van társítva, a konfigurációjától függően szükség lehet egy adott bejövő szabályra. Tudjon meg többet.

Támogatja az Application Gateway az IPv6-ot?

Az Application Gateway v2 támogatja az IPv4- és IPv6-előtérrendszereket. Az IPv6-támogatás jelenleg csak az új alkalmazásátjárókhoz érhető el. Az IPv6 támogatásához a virtuális hálózatnak dual stacknek kell lennie. Az Application Gateway 1-es verzió nem támogatja a kettős veremű virtuális hálózatokat.

Támogatja az Application Gateway a FIPS-t?

Az Application Gateway termékváltozatai fips 140-2 jóváhagyott működési módban futtathatók, amelyet gyakran "FIPS módnak" neveznek. A FIPS mód egy FIPS 140-2-alapú hitelesített titkosítási modult hív meg, amely lehetővé teszi a FIPS-kompatibilis algoritmusok titkosítását, kivonatolását és aláírását, ha engedélyezve van. A FIPS mód engedélyezésének biztosításához a FIPSMode beállítást a Portalon (V2), PowerShellen, Azure Resource Manager sablonon vagy REST API-n keresztül kell konfigurálni.

Steps a FIPS mód engedélyezéséhez V2 SKU-ban: Lásd: A FIPS mód engedélyezése az Azure Application Gateway V2 termékváltozathoz.

A FIPS mód engedélyezésének lépései a V1 termékváltozatban:

1. lépés: Regisztrálja az "AllowApplicationGatewayEnableFIPS" funkciót a FIPS mód konfigurációjához tartozó előfizetés regisztrálásához.

Az Azure PowerShell használatával történő regisztrációhoz nyisson meg egy Cloud Shell parancssort, és írja be a következőket:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Regisztráció a Azure portálon:

  • Jelentkezzen be a Azure portálra, és keresse meg a Preview funkciókat.
  • Adja meg az AllowApplicationGatewayEnableFIPS értéket a szűrőmezőbe. Válassza az Application Gateway V1 Allow FIPS Mode (FIPS-mód engedélyezése) lehetőséget, majd válassza a Regisztráljon.

Step 2: Állítsa a enableFips tulajdonságot True PowerShell, Azure Resource Manager sablon vagy REST API használatával.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

A FIPS mód módosítása nem befolyásolja a titkosítási csomagok általános elérhetőségét a V1-átjárókon. Ha azonban elliptikus görbe titkosítását használja a titkosításhoz, a FIPS mód letiltása esetén használhatja a curve25519, a NistP256 és a NistP384 görbét, míg a FIPS mód engedélyezésével csak a NistP256 és a NistP384, a curve25519 pedig le van tiltva. Mivel a curve25519 FIPS módban elérhetetlenné válik, a FIPS engedélyezése előtt győződjön meg arról, hogy az ügyfelek támogatják az NistP256 vagy az NistP384 protokollt a biztonságos kommunikáció érdekében.

Hogyan lehet az Application Gateway v2-t csak privát frontend IP-címmel használni?

Az Application Gateway v2 mostantól csak a privát IP-címelőtér-konfigurációt támogatja. További információ: Privát Application Gateway üzembe helyezése.

Az Application Gateway v2 a következő kombinációkat támogatja:

  • Privát IP-cím és nyilvános IP-cím
  • Csak nyilvános IP-cím
  • Csak privát IP-cím

Hogyan állíthatom le és indíthatom el az „Application Gateway”-t?

Az Application Gateway leállításához és elindításához használhatja a Azure PowerShell vagy a Azure CLI. Amikor leállítja és elindítja az Application Gatewayt, a számlázás is leáll és elindul. A leállított Application Gatewayen (például címke, állapotadat-mintavétel vagy figyelő hozzáadása) végzett PUT-műveletek elindítják az indítást. Javasoljuk, hogy a konfiguráció frissítése után állítsa le az Application Gatewayt.

# 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

Konfiguráció: TLS

Milyen tanúsítványokat támogat az Application Gateway?

Az Application Gateway támogatja az önaláírt tanúsítványokat, a hitelesítésszolgáltatói (CA-) tanúsítványokat, a kiterjesztett érvényesítési (EV) tanúsítványokat, a többtartományos (SAN) tanúsítványokat és a helyettesítő tanúsítványokat.

Milyen titkosítási csomagokat támogat az Application Gateway?

Az Application Gateway a következő titkosítási csomagokat támogatja:

  • 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

A TLS-beállítások testreszabásáról további információt az Application Gateway TLS-szabályzatverzióinak és titkosítási csomagjainak konfigurálása című témakörben talál.

Támogatja az Application Gateway a háttérrendszer felé irányuló forgalom újrakódolását?

Igen. Az Application Gateway támogatja a TLS tehermentesítést és a végponttól végpontig terjedő TLS-t, amely újra titkosítja a háttérrendszer felé irányuló forgalmat.

Konfigurálhatom a TLS-szabályzatot a TLS protokollverziók szabályozására?

Igen. Az Application Gateway konfigurálható úgy, hogy megtagadja a TLS1.0, a TLS1.1 és a TLS1.2 használatát. Alapértelmezés szerint az SSL 2.0 és 3.0 már le van tiltva, és nem konfigurálható.

Konfigurálhatok titkosítási csomagokat és szabályzatrendet?

Igen. Az Application Gatewayben titkosítócsomagokat konfigurálhat. Egyéni szabályzat definiálásához engedélyezze legalább az alábbi titkosítási csomagok egyikét:

  • 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

Az Application Gateway SHA256-ot használ a háttérkezeléshez.

Hány TLS/SSL-tanúsítványt támogat az Application Gateway?

Az Application Gateway legfeljebb 100 TLS/SSL-tanúsítványt támogat.

Támogatja az Application Gateway az OCSP-t és az OCSP staplinget?

Igen, az Application Gateway támogatja az OCSP-bővítményekkel és a kiszolgálótanúsítványok OCSP-hez való csatlakoztatásával rendelkező tanúsítványokat.

Hány hitelesítési tanúsítványt támogat az Application Gateway a háttérbeli újrakódoláshoz?

Az Application Gateway legfeljebb 100 hitelesítési tanúsítványt támogat.

Natív módon integrálódik az Application Gateway az Azure Key Vault-val?

Igen, az Application Gateway v2 termékváltozata támogatja a Key Vault. További információ: TLS-leállítás Key Vault tanúsítványokkal.

Miért nem tudok Azure kulcstartót kiválasztani egy másik előfizetésből a Azure portálon, amikor TLS-figyelőtanúsítványt konfigurálok az Application Gatewayen?

Az Azure portál jelenleg csak az ugyanabból az előfizetésből származó kulcstartók kiválasztását engedélyezi, mint az Application Gateway. Ez egy ismert portálkorlátozás. Az Application Gateway azonban támogatja egy másik előfizetésből (ugyanazon Microsoft Entra ID bérlőn belül) származó kulcstartó használatát azáltal, hogy a tanúsítványt a Azure CLI vagy a PowerShell használatával konfigurálja a kulcstartó titkos azonosítójával, feltéve, hogy az Application Gateway által felügyelt identitás rendelkezik a kulcstartóhoz szükséges engedélyekkel.

Hogyan konfigurálhatok HTTPS-figyelőket .com és .NET webhelyekhez?

Több tartományalapú (gazdagépalapú) útválasztáshoz többhelyes figyelőket hozhat létre, beállíthat https protokollt használó figyelőket, és társíthatja a figyelőket az útválasztási szabályokkal. További információ: Több webhely üzemeltetése az Application Gateway használatával.

Használhatok speciális karaktereket a .pfx fájljelszómban?

Nem Csak alfanumerikus karaktereket használjon a .pfx fájljelszóban.

Az EV-tanúsítványomat a DigiCert állítja ki, és a köztes tanúsítványomat visszavonták. Hogyan megújítani a tanúsítványomat az Application Gatewayen?

A CA/Browser tagjai nemrég tettek közzé jelentéseket, amelyek részletesen ismertetik a ca-szállítók által kibocsátott több tanúsítványt, amelyeket az ügyfeleink, Microsoft és a nagyobb technológiai közösség használ, amelyek nem felelnek meg a nyilvánosan megbízható hitelesítésszolgáltatókra vonatkozó iparági szabványoknak. A nem megfelelő hitelesítésszolgáltatókkal kapcsolatos jelentések itt találhatók:

Az iparág megfelelőségi követelményei szerint a ca-szállítók elkezdték visszavonni a nem megfelelő hitelesítésszolgáltatókat, és megfelelő hitelesítésszolgáltatókat bocsátanak ki, ami megköveteli az ügyfelek számára a tanúsítványaik újbóli kiadását. Microsoft szorosan együttműködik ezekkel a szállítókkal, hogy minimalizálja az Azure szolgáltatásokra gyakorolt lehetséges hatást. A saját kibocsátású tanúsítványok vagy a Saját Tanúsítvány Használata (BYOC) forgatókönyvekben használt tanúsítványok azonban továbbra is veszélyben vannak, hogy váratlanul visszavonják őket.

Annak ellenőrzéséhez, hogy az alkalmazás által használt tanúsítványok visszavonva lettek-e, tekintse meg a DigiCert közleményét és a tanúsítvány-visszavonási nyomkövetőt. Ha visszavonták, vagy vissza fogják vonni a tanúsítványokat, új tanúsítványokat kell kérnie az Ön alkalmazásaihoz használt hitelesítésszolgáltatótól. Annak érdekében, hogy az alkalmazás rendelkezésre állása ne szakadjon meg a tanúsítványok váratlan visszavonása vagy a visszavont tanúsítványok frissítése miatt, tekintse meg a A nem megfelelő hitelesítésszolgáltatók meghívása, amelyek potenciálisan hatással lehetnek az ügyfél Azure szolgáltatásaira.

Az Application Gatewayre vonatkozó információk:

Ha a visszavont hitelesítésszolgáltatók egyike által kiadott tanúsítványt használ, előfordulhat, hogy az alkalmazás rendelkezésre állása megszakad. Az alkalmazástól függően különböző hibaüzenetek jelenhetnek meg, többek között a következőkre:

  • Érvénytelen tanúsítvány/visszavont tanúsítvány
  • A kapcsolat időtúllépés miatt megszakadt
  • HTTP 502

A probléma miatt az alkalmazás megszakításának elkerülése vagy a visszavont hitelesítésszolgáltató (CA) újbóli kiadása érdekében a következő műveleteket kell végrehajtania:

  1. Lépjen kapcsolatba a tanúsítványszolgáltatóval a tanúsítványok újbóli kiadásával kapcsolatban.
  2. Miután újra kiadta őket, frissítse a tanúsítványokat az Application Gatewayen/WAF-en a teljes megbízhatósági lánccal (levél, köztes és főtanúsítvány). A tanúsítvány használatának helye alapján, akár a figyelőn, akár az Application Gateway HTTP-beállításain, kövesse az alábbi lépéseket a tanúsítványok frissítéséhez. További információkért tekintse meg az említett dokumentációs hivatkozásokat.
  3. Frissítse a háttéralkalmazás-kiszolgálókat az újra kiadott tanúsítvány használatára. A használt háttérkiszolgálótól függően a tanúsítványfrissítés lépései eltérőek lehetnek. Ellenőrizze a szállító dokumentációját.

A tanúsítvány frissítése a figyelőben:

  1. A Azure portálon nyissa meg az Application Gateway-erőforrást.
  2. Nyissa meg a tanúsítványhoz társított figyelőbeállításokat.
  3. Válassza a Kijelölt tanúsítvány megújítása vagy szerkesztése lehetőséget.
  4. Töltse fel az új PFX-tanúsítványt a jelszóval, és válassza a Mentés lehetőséget.
  5. A webhely elérése és annak ellenőrzése, hogy a webhely a várt módon működik-e. További információ: Application Gateway-tanúsítványok megújítása.

Ha Key Vault tanúsítványára hivatkozik az Application Gateway figyelőjében, a gyors módosításhoz az alábbi lépéseket javasoljuk:

  1. A Azure portálon nyissa meg az application gatewayhez társított Key Vault beállításokat.
  2. Adja hozzá vagy importálja az újra kiadott tanúsítványt az áruházban. További információ: Gyors kezdés: Kulcstartalmatár létrehozása az Azure portál használatával.
  3. A tanúsítvány importálása után nyissa meg az Application Gateway figyelőbeállításait, és a A tanúsítvány létrehozása Key Vault területen válassza ki a Certificate legördülő menüt, és válassza ki a nemrég hozzáadott tanúsítványt.
  4. Válassza a Mentés lehetőséget. További információ az Application Gateway Key Vault tanúsítványokkal történő TLS-leállításáról: TLS-leállítás Key Vault tanúsítványokkal.

A tanúsítvány frissítése a HTTP-beállításokban:

Ha az Application Gateway/WAF szolgáltatás 1. verziós termékváltozatát használja, az új tanúsítványt fel kell töltenie háttér-hitelesítési tanúsítványként.

  1. A Azure portálon nyissa meg az Application Gateway-erőforrást.
  2. Nyissa meg a tanúsítványhoz társított HTTP-beállításokat.
  3. Válassza a Tanúsítvány hozzáadása lehetőséget, töltse fel az újra kiadott tanúsítványt, és válassza a Mentés lehetőséget.
  4. A régi tanúsítványt később eltávolíthatja a régi tanúsítvány melletti ... beállítások gombra kattintva. Válassza a Törlés, majd a Mentés lehetőséget. További információ: Teljes körű TLS konfigurálása az Application Gateway és a portál használatával.

Ha az Application Gateway/WAF szolgáltatás V2 termékváltozatát használja, nem kell feltöltenie az új tanúsítványt a HTTP-beállításokba, mivel a V2 termékváltozat "megbízható főtanúsítványokat" használ, és itt nem kell műveletet tennie.

Konfiguráció – TLS/TCP-proxy

Az Application Gateway 7. és 4. rétege ugyanazokat az előtérbeli IP-címeket használja?

Igen. Az Application Gatewayen keresztüli 7. és 4. rétegbeli útválasztás ugyanazt az előtérbeli IP-konfigurációt használja. Így az összes ügyfelet egyetlen (nyilvános vagy privát) IP-címre irányíthatja, és ugyanez az átjáró-erőforrás a konfigurált figyelőprotokollok és a portok alapján irányítja őket.

Használhatok TCP- vagy TLS-proxyt HTTP(S) forgalomhoz?

Bár a HTTP(S) forgalom L4 proxyprotokollokon keresztül is kiszolgálható, ezt nem javasoljuk. Az Application Gateway L7 proxymegoldása nagyobb felügyeletet és biztonságot nyújt a HTTP(S) protokollok felett olyan speciális funkciókon keresztül, mint az átírás, a munkamenet-affinitás, az átirányítás, a WebSockets, a WAF stb.

Mik a 4. rétegbeli proxy tulajdonságnevei?

A 4. rétegbeli szolgáltatások erőforrás-tulajdonságai eltérnek a 7. rétegtől. Ennek megfelelően a REST API vagy a parancssori felület használatakor a következő tulajdonságokat kell használnia.

Tulajdonság Cél
figyelő TLS- vagy TCP-alapú figyelők esetén
útválasztási szabály 4. réteg figyelő hozzárendelése a 4. réteg háttérbeállításához
háttérbeállításokGyűjteménye TLS- vagy TCP-alapú háttérbeállítások esetén

Megjegyzés

A HTTP- vagy HTTPS-protokollbeállításokhoz nem használhat 4. rétegbeli tulajdonságokat.

Társíthatok egy TCP/TLS protokollfigyelőt egy HTTP(S) protokoll háttérbeállítással?

Nem A 4. réteg és a 7. réteg tulajdonságai nem kapcsolhatók össze. Ezért az útválasztási szabály csak a 4. rétegbeli figyelők csatlakoztatását teszi lehetővé egy 4. réteg típusú háttérrendszer-beállításhoz.

Az L7 és az L4 tulajdonságnak lehetnek azonos nevei?

Nem használhatja ugyanazt a nevet az L7 (httpListeners) és az L4 (listeners) számára. Ez vonatkozik más L4-tulajdonságokra is, például a backendSettingsCollectionre és az routingRulesre.

Hozzáadhatok privát végpontot egy háttérkészlethez a 4. réteg (TCP- vagy TLS-protokollok) használatakor?

Természetesen. A 7. rétegbeli proxyhoz hasonlóan hozzáadhat egy privát végpontot az application gateway háttérkészletéhez. Ezt a privát végpontot az application gateway ugyanazon virtuális hálózatának egy szomszédos alhálózatán kell üzembe helyezni.

Az Application Gateway keepalive kapcsolatot használ a háttérkiszolgálókhoz?

Nem használja a Keepalive-t háttérkapcsolatokhoz. Az előtérbeli figyelőkapcsolat minden bejövő kéréséhez az Application Gateway új háttérkapcsolatot kezdeményez a kérés teljesítéséhez.

Melyik IP-címet látja a háttérkiszolgáló, amikor létrejön egy kapcsolat az Application Gatewayrel?

A háttérkiszolgáló az Application Gateway IP-címét látja. Jelenleg nem támogatjuk az "ügyfél IP-címének megőrzését", amelyen keresztül a háttéralkalmazás értesülhet az eredeti ügyfél IP-címéről.

Hogyan állíthatom be a TLS-figyelők TLS-szabályzatát?

Ugyanez a TLS/SSL-szabályzatkonfiguráció a 7. rétegre (HTTPS) és a 4. rétegre (TLS) is érvényes. Mostantól használhatja az SSL-profilt (figyelőspecifikus TLS-házirendekhez és kölcsönös hitelesítéshez) a TLS-figyelők számára. Jelenleg azonban egy SSL-profil csak a parancssori felület, a PowerShell vagy a REST API használatával társítható TLS-figyelőhöz.

Támogatja az Application Gateway a munkamenet-affinitást a 4. rétegbeli útválasztáshoz?

Nem Az ügyfél ugyanarra a háttérkiszolgálóra való átirányítása jelenleg nem támogatott. A kapcsolatok körkörösen lesznek elosztva a háttérszerver csoport kiszolgálói között.

Működik az automatikus skálázási funkció a 4. rétegbeli proxyval?

Igen, az automatikus skálázási funkció a TLS vagy a TCP protokoll forgalmának kiugrása és csökkentése érdekében is működik.

Támogatott a Web Application Firewall (WAF) a 4. rétegbeli forgalomhoz?

A Web Application Firewall (WAF) képességei nem működnek a 4. rétegbeli használathoz.

Támogatja az Application Gateway 4. rétegbeli proxyja az UDP protokollt?

Nem Az UDP-támogatás jelenleg nem érhető el.

Mely portok támogatottak a TLS-/TCP-figyelők számára?

Az engedélyezett porttartományok és kivételek listája a 4. rétegbeli proxyra is vonatkozik.

Hogyan használhatom ugyanazt a portszámot nyilvános és privát TLS-/TCP-proxyfigyelőkhöz?

A TLS/TCP-figyelők közös portjának használata jelenleg nem támogatott.

Konfiguráció – bejövőforgalom-vezérlő az AKS-hez

Mi az a bejövőforgalom-vezérlő?

A Kubernetes lehetővé teszi deployment és service erőforrások létrehozását, hogy egy csoport podot a fürtön belül elérhetővé tegyen. Ha ugyanazt a szolgáltatást külsőleg szeretné elérhetővé tenni, egy Ingress erőforrás van definiálva, amely terheléselosztást, TLS-leállást és névalapú virtuális üzemeltetést biztosít. Az Ingress erőforrás kielégítése érdekében bejövőforgalom-vezérlőre van szükség, amely figyeli az erőforrások módosításait Ingress , és konfigurálja a terheléselosztó szabályzatait.

Az Application Gateway Bejövő forgalom-vezérlő (AGIC) lehetővé teszi, hogy a Alkalmazási átjáró bejövőként szolgáljon az Azure Kubernetes Service, más néven AKS-fürt számára.

Konfigurálhatom közvetlenül az Application Gatewayt a bejövőforgalom-vezérlő használata helyett?

Az Application Gateway közvetlen konfigurálása nem támogatott.

Ha módosítani kell a beállításokat az Application Gatewayen, végezze el a módosítást a bejövőforgalom-vezérlő vagy más Kubernetes-objektumok közzétett konfigurációjának használatával, például támogatott széljegyzetek használatával. Miután az Application Gateway az Application Gateway bejövőforgalom-vezérlőhöz (AGIC) van csatolva, az átjáró szinte minden konfigurációját szinkronizálja és vezérli a bejövőforgalom-vezérlő. Ha az Application Gatewayt imperatív módon vagy kódként az infrastruktúrán keresztül szeretné közvetlenül konfigurálni, akkor ezeket a módosításokat végül felülírja a bejövőforgalom-vezérlő.

Egy bejövőforgalom-vezérlőpéldány több alkalmazásátjárót is kezelhet?

Jelenleg egy bejövőforgalom-vezérlő egy példánya csak egy application gatewayhez társítható.

Miért nem működik a kubenettel rendelkező AKS-fürt az AGIC-vel?

Az AGIC megpróbálja automatikusan társítani az útvonaltábla-erőforrást az Application Gateway alhálózatához, de előfordulhat, hogy az AGIC engedélyeinek hiánya miatt nem sikerül. Ha az AGIC nem tudja társítani az útvonaltáblát az Application Gateway alhálózatához, hiba jelenik meg az AGIC-naplókban. Ebben az esetben manuálisan kell társítania az AKS-fürt által létrehozott útvonaltáblát az Application Gateway alhálózatához. További információ: Támogatott, felhasználó által megadott útvonalak.

Csatlakoztathatom az AKS-fürtemet és az Application Gatewayt külön virtuális hálózatokban?

Igen, mindaddig, amíg a virtuális hálózatok össze vannak kapcsolva, és nem rendelkeznek átfedő címtérrel. Ha az AKS-t kubenettel futtatja, mindenképpen társítsa az AKS által létrehozott útvonaltáblát az Application Gateway alhálózatához.

Milyen funkciók nem támogatottak az AGIC-bővítményben?

A Helmen keresztül üzembe helyezett AGIC és az AKS-bővítmények közötti különbségekért lásd a Helm üzembe helyezése és az AKS-bővítmény közötti különbséget.

Mikor érdemes használni a bővítményt a Helm üzembe helyezésével szemben?

A Helm segítségével telepített AGIC és az AKS bővítményként telepített AGIC közötti különbségekért lásd a Helm telepítés és az AKS bővítmény közötti különbségekről szóló dokumentumot, különösen azokat a táblázatokat, amelyek dokumentálják az AGIC által a Helm útján, szemben egy AKS bővítményként telepítés esetén támogatott forgatókönyveket. Általánosságban elmondható, hogy a Helm használata lehetővé teszi a bétafunkciók tesztelését és a kiadásra jelölt verziók kipróbálását a hivatalos kiadás előtt.

Szabályozhatom, hogy az AGIC melyik verziója legyen üzembe helyezve a bővítményrel?

Nem Az AGIC-bővítmény egy felügyelt szolgáltatás, ami azt jelenti, Microsoft automatikusan frissíti a bővítményt a legújabb stabil verzióra.

Frissíthetem a Kubenetet vagy Azure CNI-t futtató fürtöt az Azure CNI Overlay-re, ha AGIC telepítve van?

Igen, az Application Gateway bejövőforgalom-vezérlője automatikusan észleli az AKS-fürt Kubenetről vagy CNI-ről CNI-átfedésre való frissítését. Javasoljuk, hogy a frissítés ütemezése a karbantartási időszak alatt történjen, mivel a forgalom megszakadhat. A vezérlő a fürtfrissítés után néhány percet is igénybe vehet a CNI Overlay támogatásának észleléséhez és konfigurálásához.

Konfiguráció: Kölcsönös hitelesítés

Mi a kölcsönös hitelesítés?

A kölcsönös hitelesítés kétirányú hitelesítés egy ügyfél és egy kiszolgáló között. Az Application Gatewayrel való kölcsönös hitelesítés jelenleg lehetővé teszi, hogy az átjáró ellenőrizze a kérést küldő ügyfelet, vagyis az ügyfél-hitelesítést. Általában az ügyfél az egyetlen, amely hitelesíti az Application Gatewayt. Mivel az Application Gateway mostantól az ügyfelet is hitelesítheti, kölcsönös hitelesítéssé válik, ahol az Application Gateway és az ügyfél kölcsönösen hitelesítik egymást.

Elérhető kölcsönös hitelesítés az Application Gateway és annak háttérkészletei között?

Nem, a kölcsönös hitelesítés jelenleg csak az előtérbeli ügyfél és az application gateway között történik. A háttérbeli kölcsönös hitelesítés jelenleg nem támogatott.

Diagnosztika és naplózás

Milyen típusú naplókat biztosít az Application Gateway?

Az Application Gateway három naplót biztosít:

  • ApplicationGatewayAccessLog: A hozzáférési napló tartalmazza az Application Gateway előtérnek küldött összes kérelmet. Az adatok tartalmazzák a hívó IP-címét, a kért URL-címet, a válasz késését, a visszatérési kódot és a bájtokat. Alkalmazásátjárónként egy rekordot tartalmaz.
  • ApplicationGatewayPerformanceLog: A teljesítménynapló rögzíti az egyes application gatewayek teljesítményadatait. Az információk közé tartozik az átvitel bájtokban, a teljes kiszolgált kérések száma, a sikertelen kérelmek száma, valamint a háttérpéldányok egészséges és nem egészséges száma.
  • ApplicationGatewayFirewallLog: A WAF-vel konfigurált application gatewayek esetében a tűzfalnapló olyan kéréseket tartalmaz, amelyek észlelési vagy megelőzési módban vannak naplózva.

A rendszer minden naplót 60 másodpercenként gyűjt. További információ: Háttérállapot, diagnosztikai naplók és metrikák az Application Gatewayhez.

Honnan tudom, hogy a hátérrendszer részhalmaz tagjai rendben vannak-e?

Ellenőrizze az állapotot a PowerShell-parancsmaggal Get-AzApplicationGatewayBackendHealth vagy a portállal. További információ: Application Gateway-diagnosztika.

Mi a diagnosztikai naplók adatmegőrzési szabályzata?

A diagnosztikai naplók az ügyfél tárfiókjába áramlanak. Az ügyfelek a saját preferenciájuk alapján állíthatják be a megőrzési szabályzatot. A diagnosztikai naplók eseményközpontba vagy Azure Monitor naplókba is elküldhetők. További információ: Application Gateway-diagnosztika.

Hogyan lehet lekérni az auditnaplókat az Application Gatewayhez?

A portálon az Application Gateway menüpanelén válassza a Tevékenységnapló lehetőséget az auditnapló eléréséhez.

Beállíthatok riasztásokat az Application Gateway használatával?

Igen. Az Application Gatewayben a riasztások metrikákon vannak konfigurálva. További információ: Application Gateway-metrikák és riasztási értesítések fogadása.

Hogyan elemezni az Application Gateway forgalmi statisztikáit?

A hozzáférési naplókat többféleképpen is megtekintheti és elemezheti. Használja Azure Monitor naplókat, Excel, Power BI stb.

Olyan Resource Manager sablont is használhat, amely telepíti és futtatja a népszerű GoAccess naplóelemzőt az Application Gateway hozzáférési naplóihoz. A GoAccess értékes HTTP-forgalmi statisztikákat biztosít, például egyedi látogatókat, kért fájlokat, gazdagépeket, operációs rendszereket, böngészőket és HTTP-állapotkódokat. További információt a GitHub Readme fájljában talál a Resource Manager sablonmappában.

Mi okozhatja, hogy a háttérrendszer állapota ismeretlen állapotot ad vissza?

Általában ismeretlen állapot jelenik meg, ha a háttérrendszerhez való hozzáférést egy NSG, egyéni DNS vagy felhasználó által meghatározott útválasztás blokkolja az Application Gateway alhálózatán. További információ: Háttérállapot, diagnosztikai naplózás és metrikák az Application Gatewayhez.

Támogatva vannak az NSG-k folyamati naplói az Application Gateway v2 alhálózathoz kapcsolódó NSG-k esetében?

Az aktuális platformkorlátozások miatt, ha az Application Gateway v2 (Standard_v2, WAF_v2) alhálózatán NSG van, és engedélyezte az NSG-folyamatnaplókat rajta, akkor nemdeterminista viselkedés jelenik meg. Ez a forgatókönyv jelenleg nem támogatott.

Hol tárolja az Application Gateway az ügyféladatokat?

Az Application Gateway nem helyezi át és nem tárolja az ügyféladatokat azon a régión kívül, ahol az üzembe lett helyezve.

Következő lépések

  • Last updated on