Az App Service-környezet konfigurálása kényszerített bújtatással

Cikk
10/16/2024

Fontos

Ez a cikk az App Service Environment v2-ről szól, amelyet izolált App Service-csomagokkal használnak. Az App Service Environment 1- és v2-s verziójának kivonása 2024. augusztus 31-én megtörténik. Az App Service Environment új verziója egyszerűbben használható és hatékonyabb infrastruktúrán futtatható. Az új verzióról az App Service-környezet bemutatása című cikkből tudhat meg többet. Ha jelenleg az App Service Environment 1-es verzióját használja, kövesse a cikkben leírt lépéseket az új verzióra való migráláshoz.

2024 . augusztus 31-től a szolgáltatásiszint-szerződés (SLA) és a szolgáltatási kreditek már nem vonatkoznak az App Service Environment 1-es és v2-es számítási feladataira, amelyek továbbra is éles környezetben vannak, mivel kivont termékek. Megkezdődött az App Service Environment v1 és v2 hardver leszerelése, ami hatással lehet az alkalmazások és adatok rendelkezésre állására és teljesítményére.

Azonnal be kell fejeznie az App Service Environment 3-ra való migrálást, vagy előfordulhat, hogy az alkalmazások és az erőforrások törlődnek. A helyszíni migrálási funkcióval megpróbáljuk automatikusan migrálni a fennmaradó App Service Environment 1-et és v2-t, de a Microsoft az automatikus migrálást követően nem vállal semmilyen igényt vagy garanciát az alkalmazások rendelkezésre állására vonatkozóan. Előfordulhat, hogy manuális konfigurációt kell végrehajtania a migrálás elvégzéséhez, és optimalizálnia kell az App Service-csomag termékváltozatát az igényeinek megfelelően. Ha az automatikus migrálás nem lehetséges, az erőforrások és a kapcsolódó alkalmazásadatok törlődnek. Határozottan sürgetjük, hogy most cselekedjen, hogy elkerülje a szélsőséges forgatókönyvek egyikét.

Ha további időre van szüksége, egyszeri 30 napos türelmi időszakot biztosítunk a migrálás befejezéséhez. További információkért és a türelmi időszak kéréséhez tekintse át a türelmi időszak áttekintését, majd nyissa meg az Azure Portalt , és keresse fel az Egyes App Service-környezetek Áttelepítés paneljét.

Az App Service Environment v1/v2-beli kivonásával kapcsolatos legfrissebb információkért tekintse meg az App Service Environment 1- és v2-beli kivonási frissítését.

Az App Service-környezet (ASE) az Azure App Service üzemelő példánya az ügyfelek Azure Virtual Network-hálózatában. Számos ügyfél konfigurálja az Azure-beli virtuális hálózatait VPN-ek vagy Azure ExpressRoute-kapcsolatok segítségével úgy, hogy azok a helyszíni hálózatok kiterjesztéseként működjenek. A kényszerített bújtatás átirányítja az internetre irányuló forgalmat a VPN-re vagy egy virtuális berendezésre. A virtuális berendezéseket gyakran használják a kimenő hálózati forgalom vizsgálatára és naplózására.

Az ASE több külső függőséggel rendelkezik, amelyek leírását megtalálhatja az App Service-környezet hálózati architektúráját ismertető dokumentumban. Általában az ASE minden kimenő függőségének az ASE virtuális IP-címén kell keresztülmennie. Ha az alábbi információk felhasználása nélkül módosítja a forgalom útválasztását az ASE-re vagy az ASE-ről, az ASE működése leáll.

Egy Azure-beli virtuális hálózatban az útválasztás a leghosszabb előtag-megfeleltetés (LPM) alapján történik. Ha egynél több útvonal rendelkezik ugyanazzal az LPM megfeleltetéssel, akkor a rendszer az útvonalat a kiindulás alapján választja ki, az alábbi sorrendben:

Felhasználó által meghatározott útvonal (UDR)
BGP-útvonal (ExpressRoute használatánál)
Rendszerútvonal

Ha többet szeretne megtudni a virtuális hálózatokban történő útválasztásról, olvassa el a felhasználó által megadott útvonalakat és IP-továbbítást ismertető cikket.

Ha nem közvetlenül az internetre szeretné átirányítani a kimenő ASE-forgalmat, az alábbi lehetőségei vannak:

Közvetlen internetelérés engedélyezése az ASE számára
ASE-alhálózat konfigurálása a BGP-útvonalak figyelmen kívül hagyására
Az ASE alhálózat konfigurálása szolgáltatásvégpontok használatára az Azure SQL-hez és az Azure Storage szolgáltatáshoz
Saját IP-címek hozzáadása az ASE Azure SQL-tűzfalhoz

Közvetlen internetelérés engedélyezése az App Service-környezet számára

Ha engedélyezni szeretné, hogy az ASE közvetlenül az internethez csatlakozzon akkor is, ha az Azure-beli virtuális hálózat ExpressRoute-tal van konfigurálva, a következőket teheti:

Konfigurálja az ExpressRoute-ot a 0.0.0.0/0 tartomány meghirdetésére. Ez alapértelmezés szerint átirányít minden kimenő forgalmat a helyszíni hálózatba.
Hozzon létre egy UDR-t a 0.0.0.0/0 címelőtaggal és következő ugrási típusú internettel, és alkalmazza azt az ASE-alhálózatra.

Ha végrehajtja ezt a két módosítást, az App Service-környezet alhálózatából származó, internetre küldött forgalom nem lesz rákényszerítve az ExpressRoute-kapcsolatra.

Ha a hálózat már irányít forgalmat a helyszínen, létre kell hozni egy alhálózatot az ASE üzemeltetéséhez és az UDR konfigurálásához az ASE számára, mielőtt megkísérelni üzembe helyezni az ASE-t.

Fontos

Az UDR-ben meghatározott útvonalaknak annyira pontosnak kell lenniük, hogy prioritást kapjanak az ExpressRoute-konfiguráció által meghirdetett bármely útvonallal szemben. Az előző példa a széles 0.0.0.0/0 címtartományt használja. Ezt véletlenül felülírhatják olyan útvonalhirdetések, amelyek pontosabb címtartományokat használnak.

Az App Service-környezetek nem támogatottak olyan ExpressRoute-konfigurációk esetén, amelyek keresztbe hirdetnek útvonalakat a nyilvános társviszony-létesítési útvonalról a privát társviszony-létesítési útvonalra. A konfigurált nyilvános társviszonyt létesítő ExpressRoute-konfigurációk útvonalhirdetéseket kapnak a Microsofttól. A meghirdetések Microsoft Azure-címtartományok nagy készletét tartalmazzák. Ha a címtartományokat keresztbe hirdetik a privát társviszony-létesítési útvonalon, az összes, az App Service-környezet alhálózatából származó kimenő hálózati csomag átirányítással kerül az ügyfél helyszíni hálózati infrastruktúrájába. Az App Service-környezetek alapértelmezés szerint nem támogatják ezt a hálózati kialakítást. Egy megoldás erre a problémára az, ha leállítja az útvonalak keresztbe hirdetését a nyilvános társviszony-létesítési útvonalról a privát társviszony-létesítési útvonalra. Egy másik megoldás az, ha lehetővé teszi az App Service-környezet működését kényszerített bújtatásos konfigurációban.

Közvetlen internet-hozzáférés

ASE-alhálózat konfigurálása a BGP-útvonalak figyelmen kívül hagyására

Az ASE-alhálózatot konfigurálhatja a BGP-útvonalak figyelmen kívül hagyására. Ha úgy van konfigurálva, hogy figyelmen kívül hagyja a BGP-útvonalakat, az ASE probléma nélkül hozzáférhet a függőségeihez. Ahhoz azonban, hogy az alkalmazásai hozzá tudjanak férni a helyszíni erőforrásokhoz, UDR-eket is létre kell hoznia.

ASE-alhálózat konfigurálása a BGP-útvonalak figyelmen kívül hagyására:

Hozzon létre egy UDR-t, és rendelje hozzá az ASE-alhálózathoz, ha ez még nem történt meg.
Az Azure Portalon nyissa meg az ASE-alhálózathoz rendelt útválasztási táblázat felhasználói felületét. Válassza a Konfiguráció lehetőséget. Állítsa be a virtuális hálózati átjáró útvonalának propagálását Letiltva értékre. Kattintson a Mentés gombra. A beállítás kikapcsolására vonatkozó információkat az útválasztási táblázat létrehozásával foglalkozó témakörben találja meg.

Miután konfigurálta az ASE alhálózatot, hogy figyelmen kívül hagyja az összes BGP-útvonalat, az alkalmazások többé nem fognak tudni elérni a helyszínen. Ahhoz, hogy az alkalmazások hozzáférhessenek a helyszíni erőforrásokhoz, szerkessze az ASE-alhálózathoz rendelt UDR-t, és adja hozzá a helyszíni címtartományokhoz tartozó útvonalakat. A Következő ugrási típus értéke legyen Virtuális hálózati átjáró.

Az ASE konfigurálása szolgáltatásvégpontokkal

Ha az Azure SQL és az Azure Storage felé irányuló forgalmon kívül az ASE összes kimenő forgalmát át szeretné irányítani, végezze el a következő lépéseket:

Hozzon létre egy útválasztási táblázatot, és rendelje hozzá az ASE-alhálózathoz. Keresse meg a régiójának megfelelő címeket az App Service-környezet kezelési címeit ismertető szakaszban. Útvonalakat hozhat létre ezekhez a címekhez, vagy használhatja az AppServiceManagement szolgáltatás címkéjét az internet következő ugrásával. Ezekre az útvonalakra azért van szükség, mert az App Service Environment bejövő felügyeleti forgalmának ugyanabból a címről kell válaszolnia, amelyre a rendszer elküldte.
Engedélyezze a szolgáltatásvégpontokat az Azure SQL-hez és az Azure Storage-hoz az ASE-alhálózattal. Miután ezt a lépést elvégezte, konfigurálhatja virtuális hálózatát kényszerített bújtatással.

Az ASE sablonnal való üzembe helyezésével kapcsolatos részletekért olvassa el az App Service-környezet létrehozása sablonnal című cikket.

A szolgáltatásvégpontokkal Azure-beli virtuális hálózatok és alhálózatok készletére korlátozhatja a több-bérlős szolgáltatásokhoz való hozzáférést. A szolgáltatásvégpontokról bővebben a virtuális hálózatok szolgáltatásvégpontjaival kapcsolatos dokumentációban olvashat.

Amikor engedélyezi a szolgáltatásvégpontokat egy erőforráson, az összes többi útvonalhoz képest nagyobb prioritású útvonalak jönnek létre. Ha kényszerítetten bújtatott ASE-vel használ szolgáltatásvégpontokat, az Azure SQL és az Azure Storage felügyeleti forgalma nem kényszerítetten bújtatott. Az ASE többi függőségi forgalma kényszerítetten bújtatott, és nem veszhet el, különben az ASE nem működik megfelelően.

Amikor a szolgáltatásvégpontok engedélyezettek egy Azure SQL-példánnyal rendelkező alhálózaton, akkor az erről az alhálózatról elért összes Azure SQL-példányhoz engedélyezve kell lennie a szolgáltatásvégpontoknak. Ha több Azure SQL-példányt szeretne elérni ugyanarról az alhálózatról, nem engedélyezheti a szolgáltatásvégpontokat csak az egyik Azure SQL-példányon, egy másikon pedig nem. Az Azure Storage nem úgy viselkedik, mint az Azure SQL. Amikor az Azure Storage szolgáltatáshoz engedélyezi a szolgáltatásvégpontokat, azzal zárolja az erőforráshoz való hozzáférést az alhálózatról, de továbbra is elérhet más Azure Storage-fiókokat, még akkor is, ha azokon nincsenek engedélyezve a szolgáltatásvégpontok.

Ha kényszerített bújtatást konfigurál egy hálózatszűrő berendezéssel, akkor ne feledje, hogy az ASE az Azure SQL és az Azure Storage mellett más függőségekkel is rendelkezik. Ha a forgalom le van tiltva ezekre a függőségekre, az ASE nem fog megfelelően működni.

Kényszerített bújtatás szolgáltatásvégpontokkal

Saját IP-címek hozzáadása az ASE Azure SQL-tűzfalhoz

Ha az Azure Storage felé irányuló forgalmon kívül bújtatni szeretné az ASE összes kimenő forgalmát, végezze el a következő lépéseket:

Hozzon létre egy útválasztási táblázatot, és rendelje hozzá az ASE-alhálózathoz. Keresse meg a régiójának megfelelő címeket az App Service-környezet kezelési címeit ismertető szakaszban. Hozzon létre útvonalakat ezekhez a címekhez egy következő ugrási típusú internettel. Ezekre az útvonalakra azért van szükség, mert az App Service Environment bejövő felügyeleti forgalmának ugyanabból a címről kell válaszolnia, amelyre a rendszer elküldte.
Szolgáltatásvégpontok engedélyezése az Azure Storage szolgáltatáshoz az ASE alhálózattal
Szerezze be az App Service-környezetből az internetre irányuló összes kimenő forgalomhoz használt címeket. Ha a helyszínen irányítja át a forgalmat, ezek a címek a NAT-ok és az átjárók IP-címei. Ha az App Service-környezet kimenő forgalmát egy hálózati virtuális berendezésen keresztül szeretné vezetni, a kimenő forgalom címe a hálózati virtuális berendezés nyilvános IP-címe lesz.
Ha meglévő App Service-környezetben szeretné beállítani a kimenő címeket: Lépjen a resources.azure.com, és válassza az Előfizetés/<előfizetés azonosítója>/resourceGroups/<ase erőforráscsoport>/szolgáltatók/Microsoft.Web/hostingEnvironments/<ase nevet>. Itt láthatja az App Service-környezetet leíró JSON-t. Győződjön meg arról, hogy a lap tetején ott az olvasás/írás felirat. Válassza a Szerkesztés lehetőséget. Görgessen le a lap aljáig. Módosítsa a userWhitelistedIpRanges beállítást null értékről az alábbihoz hasonlóra. Használja azokat a címeket, amelyeket a kimenő forgalom címtartományának kíván beállítani.
```
"userWhitelistedIpRanges": ["11.22.33.44/32", "55.66.77.0/24"]
```
A lap tetején kattintson a PUT elemre. Ez a lehetőség aktivál egy méretezési műveletet az App Service-környezetben, és beállítja a tűzfalat.

Az ASE létrehozása a kimenő forgalmi címekkel: Kövesse az App Service-környezet sablonnal történő létrehozását ismertető cikk utasításait, és kérje le a megfelelő sablont. Szerkessze az azuredeploy.json fájl „resources” (erőforrások) szakaszát, de a „properties” (tulajdonságok) blokkot ne, és a userWhitelistedIpRanges értékhez adjon hozzá egy sort a saját értékeivel.

"resources": [
    {
        "apiVersion": "2015-08-01",
        "type": "Microsoft.Web/hostingEnvironments",
        "name": "[parameters('aseName')]",
        "kind": "ASEV2",
        "location": "[parameters('aseLocation')]",
        "properties": {
            "name": "[parameters('aseName')]",
            "location": "[parameters('aseLocation')]",
            "ipSslAddressCount": 0,
            "internalLoadBalancingMode": "[parameters('internalLoadBalancingMode')]",
            "dnsSuffix" : "[parameters('dnsSuffix')]",
            "virtualNetwork": {
                "Id": "[parameters('existingVnetResourceId')]",
                "Subnet": "[parameters('subnetName')]"
            },
            "userWhitelistedIpRanges":  ["11.22.33.44/32", "55.66.77.0/30"]
        }
    }
]

Ezek a változások közvetlenül az Azure Storage felé küldik a forgalmat az ASE-ből, továbbá az ASE virtuális IP-címétől eltérő további címekről is engedélyezik az Azure SQL elérését.

Kényszerített alagút SQL-engedélyezési listával

Hibák megelőzése

Ha megszakad a kommunikáció az ASE és annak függőségeit között, az ASE sérült állapotba kerül. Ha túl sokáig marad sérült, akkor az ASE fel lesz függesztve. Az ASE felfüggesztésének megszüntetéséhez kövesse az ASE portál utasításait.

A kommunikáció egyszerű megszakítása mellett a túl sok késés bevezetésével kedvezőtlen hatással lehet az ASE-re. Túl sok késés léphet fel, ha az ASE túl messze van a helyszíni hálózattól. Túl messze van például, ha át kell szelni egy óceánt vagy egy kontinenst a helyszíni hálózat eléréséhez. Késés az intranetes torlódás vagy a kimenő sávszélesség korlátozásai miatt is előfordulhat.

Megosztás a következőn keresztül: