A fordított proxy és a háttérbeli webalkalmazás közötti eredeti HTTP-gazdagépnév megőrzése

Javasoljuk, hogy ha fordított proxyt használ egy webalkalmazás előtt, őrizze meg az eredeti HTTP-gazdagépnevet. Ha a háttéralkalmazás-kiszolgálóhoz megadottól eltérő gazdanév van a fordított proxyn, az olyan cookie-khoz vagy átirányítási URL-címekhez vezethet, amelyek nem működnek megfelelően. Előfordulhat például, hogy a munkamenet állapota elveszik, a hitelesítés sikertelen lehet, vagy a háttérBELI URL-címek véletlenül elérhetővé válnak a végfelhasználók számára. Ezeket a problémákat elkerülheti, ha megőrzi a kezdeti kérés állomásnevét, hogy az alkalmazáskiszolgáló ugyanazt a tartományt láthassa, mint a webböngésző.

Ez az útmutató különösen azokra az alkalmazásokra vonatkozik, amelyek szolgáltatásként nyújtott platformon (PaaS) futnak, például Azure-alkalmazás Szolgáltatás és Azure Spring Apps. Ez a cikk konkrét megvalósítási útmutatást nyújt az Azure-alkalmazás Gatewayhez, az Azure Front Doorhoz és az Azure API Managementhez, amelyeket gyakran használnak fordított proxyszolgáltatásokként.

Ha teljes körű TLS/SSL-t igényel (a fordított proxy és a háttérszolgáltatás közötti kapcsolat HTTPS-t használ), a háttérszolgáltatásnak egy megfelelő TLS-tanúsítványra is szüksége van az eredeti gazdagépnévhez. Ez a követelmény összetettebbé teszi a tanúsítványok üzembe helyezése és megújítása során, de számos PaaS-szolgáltatás ingyenes, teljes körűen felügyelt TLS-tanúsítványokat kínál.

Környezet

HTTP-kérés gazdagépe

Sok esetben az alkalmazáskiszolgálónak vagy a kérelemfolyamat valamely összetevőjének a böngésző által használt internetes tartománynévre van szüksége a hozzáféréshez. Ez a kérés gazdagépe . Lehet IP-cím, de általában egy hasonló contoso.com név (amelyet a böngésző ezután a DNS használatával felold egy IP-címre). A gazdagép értékét általában a kérelem URI-jának gazdagépösszetevője határozza meg, amelyet a böngésző HTTP-fejlécként küld az Host alkalmazásnak.

Bizonyos esetekben, különösen ha a kérelemláncban HTTP fordított proxy található, az eredeti gazdagépfejléc megváltozhat, mielőtt elérné az alkalmazáskiszolgálót. A fordított proxy bezárja az ügyfél hálózati munkamenetét, és beállít egy új kapcsolatot a háttérrendszerhez. Ebben az új munkamenetben átviheti az ügyfél-munkamenet eredeti állomásnevét, vagy beállíthat egy újat. Az utóbbi esetben a proxy gyakran továbbra is elküldi az eredeti gazdagép értékét más HTTP-fejlécekben, például Forwarded vagy X-Forwarded-Host. Ez az érték lehetővé teszi az alkalmazások számára, hogy meghatározzák az eredeti állomásnevet, de csak akkor, ha a fejlécek olvasására vannak kódolva.

Miért használják a webplatformok a gazdagép nevét?

A több-bérlős PaaS-szolgáltatások gyakran igényelnek regisztrált és érvényesített gazdagépnevet, hogy a bejövő kéréseket a megfelelő bérlő háttérkiszolgálójára irányíthassák. Ennek az az oka, hogy általában a terheléselosztók megosztott készlete fogadja az összes bérlő bejövő kéréseit. A bérlők általában a bejövő gazdagép nevét használják az ügyfélbérlõ megfelelő háttérrendszerének kereséséhez.

Az első lépések megkönnyítése érdekében ezek a platformok általában egy alapértelmezett tartományt biztosítanak, amely előre konfigurálva van a forgalom az üzembe helyezett példányhoz való átirányításához. Az App Service esetében ez az alapértelmezett tartomány.azurewebsites.net Minden létrehozott webalkalmazás saját altartományt kap, például contoso.azurewebsites.net. Hasonlóképpen, az alapértelmezett tartomány az azuremicroservices.io Azure Spring Appshez és azure-api.net az API Managementhez tartozik.

Éles környezetben nem használja ezeket az alapértelmezett tartományokat. Ehelyett saját tartományt ad meg, hogy igazodjon a szervezet vagy az alkalmazás márkájához. Megoldhatja például contoso.com a színfalak mögött az contoso.azurewebsites.net App Service webalkalmazását, de ez a tartomány nem lehet látható a webhelyet látogató végfelhasználó számára. Ezt az egyéni contoso.com gazdagépnevet azonban regisztrálni kell a PaaS szolgáltatásban, hogy a platform azonosíthassa azt a háttérkiszolgálót, amelynek válaszolnia kell a kérésre.

Miért használják az alkalmazások a gazdagép nevét?

Az alkalmazáskiszolgálók gazdagépnevének két gyakori oka az abszolút URL-címek létrehozása és egy adott tartomány cookie-jának kiadása. Ha például az alkalmazáskódnak a következőre van szüksége:

• Relatív URL-cím helyett abszolút url-t ad vissza a HTTP-válaszában (bár általában a webhelyek általában relatív hivatkozásokat jelenítenek meg, ha lehetséges).
• Hozzon létre egy URL-címet, amelyet a HTTP-válaszán kívül kell használni, ahol a relatív URL-címek nem használhatók, például a webhelyre mutató hivatkozás felhasználónak való elküldéséhez.
• Hozzon létre egy abszolút átirányítási URL-címet egy külső szolgáltatáshoz. Például egy olyan hitelesítési szolgáltatásba, mint a Microsoft Entra ID, amely jelzi, hogy a sikeres hitelesítés után hol kell visszaadnia a felhasználót.
• Olyan HTTP-cookie-kat ad ki, amelyek egy adott gazdagépre korlátozódnak a cookie Domain attribútumában meghatározottak szerint.

Ezeknek a követelményeknek úgy felelhet meg, hogy hozzáadja a várt gazdagépnevet az alkalmazás konfigurációjába, és ezt a statikusan definiált értéket használja a kérés bejövő állomásneve helyett. Ez a megközelítés azonban bonyolítja az alkalmazások fejlesztését és üzembe helyezését. Emellett az alkalmazás egyetlen telepítése több gazdagépet is kiszolgálhat. Egy webalkalmazás például több olyan alkalmazásbérlőhöz is használható, amelyek mindegyike saját egyedi gazdagépnevekkel rendelkezik (például tenant1.contoso.com és tenant2.contoso.com).

Néha a bejövő gazdagép nevét az alkalmazáskódon kívüli összetevők vagy az alkalmazáskiszolgáló köztes szoftverében használják, amelyek felett nincs teljes hozzáférése. Íme néhány példa:

• Az App Service-ben kényszerítheti a HTTPS-t a webalkalmazáshoz. Ez azt eredményezi, hogy a HTTP-kérések nem biztonságosak a HTTPS-hez való átirányításhoz. Ebben az esetben a rendszer a bejövő gazdagép nevét használja a HTTP-átirányítás fejlécének abszolút URL-címének Location létrehozásához.
• Az Azure Spring Apps hasonló funkciót használ a HTTPS kényszerítéséhez. Emellett a bejövő gazdagépet használja a HTTPS URL-cím létrehozásához.
• Az App Service ARR affinitási beállítással rendelkezik a ragadós munkamenetek engedélyezéséhez, így az ugyanabból a böngészőpéldányból érkező kérelmeket mindig ugyanaz a háttérkiszolgáló szolgálja ki. Ezt az App Service előtérvége hajtja végre, amely egy cookie-t ad hozzá a HTTP-válaszhoz. A cookie Domain a bejövő gazdagépre van állítva.
• Az App Service hitelesítési és engedélyezési képességeket biztosít, amelyekkel a felhasználók egyszerűen bejelentkezhet és hozzáférhetnek az API-kban tárolt adatokhoz.
  • A bejövő gazdagépnév arra az átirányítási URL-címre szolgál, amelyre az identitásszolgáltatónak vissza kell adnia a felhasználót a sikeres hitelesítés után.
  • Ennek a funkciónak az engedélyezése alapértelmezés szerint a HTTP-https átirányítást is bekapcsolja. A rendszer ismét a bejövő gazdagép nevét használja az átirányítási hely létrehozásához.

Miért lehet kísértés a gazdagép nevének felülbírálására?

Tegyük fel, hogy létrehoz egy webalkalmazást az App Service-ben, amelynek alapértelmezett tartománya contoso.azurewebsites.neta következő: . (Vagy egy másik szolgáltatásban, például az Azure Spring Appsben.) Nem konfigurált egyéni tartományt az App Service-ben. Ha az Application Gatewayhez (vagy bármely hasonló szolgáltatáshoz hasonló) fordított proxyt szeretne az alkalmazás elé helyezni, a DNS-rekordot contoso.com az Application Gateway IP-címére kell beállítania. Ezért megkapja a kérést contoso.com a böngészőtől, és úgy van konfigurálva, hogy a kérést a következő IP-címre contoso.azurewebsites.net továbbítsa: ez a kért gazdagép végső háttérszolgáltatása. Ebben az esetben azonban az App Service nem ismeri fel az contoso.com egyéni tartományt, és elutasítja az állomásnévre vonatkozó összes bejövő kérést. Nem tudja meghatározni, hogy hová kell irányítani a kérést.

Úgy tűnhet, hogy a konfiguráció egyszerű módja, ha felülbírálja vagy újraírja a Host HTTP-kérés fejlécét az Application Gatewayben, és beállítja a következő értékre contoso.azurewebsites.net: . Ha igen, az Application Gateway kimenő kérése úgy tűnik, hogy az eredeti kérés valóban a contoso.azurewebsites.net következő helyett contoso.comlett volna megcélzva:

Ezen a ponton az App Service felismeri a gazdagép nevét, és anélkül fogadja el a kérést, hogy egyéni tartománynevet kellene konfigurálni. Az Application Gateway megkönnyíti a gazdagép fejlécének felülbírálását a háttérkészlet gazdagépével. Az Azure Front Door alapértelmezés szerint ezt is teszi.

Ezzel a megoldással azonban az a probléma, hogy különböző problémákat okozhat, ha az alkalmazás nem látja az eredeti gazdagép nevét.

Lehetséges problémák

Helytelen abszolút URL-címek

Ha az eredeti gazdagépnév nem őrződik meg, és az alkalmazáskiszolgáló a bejövő gazdagépnevet használja az abszolút URL-címek létrehozásához, előfordulhat, hogy a háttértartományt közzéteszi a végfelhasználó. Ezeket az abszolút URL-címeket az alkalmazáskód vagy a korábban már említett platformfunkciók hozhatják létre, például az App Service és az Azure Spring Apps HTTP-ről HTTPS-ra történő átirányításának támogatása. Ez az ábra a következő problémát szemlélteti:

1. A böngésző kérést küld a fordított proxynak contoso.com .
2. A fordított proxy újraírja a gazdagép nevét contoso.azurewebsites.net a háttérbeli webalkalmazásnak (vagy egy másik szolgáltatáshoz hasonló alapértelmezett tartománynak) küldött kérésben.
3. Az alkalmazás létrehoz egy abszolút URL-címet, amely a bejövő contoso.azurewebsites.net gazdagép neve alapján jön létre, például https://contoso.azurewebsites.net/.
4. A böngésző ezt az URL-címet követi, amely közvetlenül a háttérszolgáltatáshoz kerül, nem pedig a fordított proxyhoz contoso.com.

Ez akár biztonsági kockázatot is jelenthet abban a gyakori esetben, amikor a fordított proxy webalkalmazási tűzfalként is szolgál. A felhasználó kap egy URL-címet, amely közvetlenül a háttéralkalmazáshoz kerül, és átadja a fordított proxyt.

Helytelen átirányítási URL-címek

Az előző forgatókönyv gyakori és pontosabb esete az abszolút átirányítási URL-címek létrehozásakor következik be. Ezekre az URL-címekre olyan identitásszolgáltatásoknak van szüksége, mint a Microsoft Entra ID, amikor böngészőalapú identitásprotokollokat használ, például OpenID Connect, Nyílt hitelesítés (OAuth) 2.0 vagy Security Assertion Markup Language (SAML) 2.0. Ezeket az átirányítási URL-címeket az alkalmazáskiszolgáló vagy a köztes szoftver hozhatja létre, vagy – amint azt korábban már említettük – olyan platformfunkciók, mint az App Service hitelesítési és engedélyezési képességei. Ez az ábra a következő problémát szemlélteti:

1. A böngésző kérést küld a fordított proxynak contoso.com .
2. A fordított proxy újraírja a gazdagép nevét contoso.azurewebsites.net a háttérbeli webalkalmazásnak (vagy egy másik szolgáltatáshoz hasonló alapértelmezett tartománynak) küldött kérésen.
3. Az alkalmazás létrehoz egy abszolút átirányítási URL-címet, amely a bejövő contoso.azurewebsites.net gazdagép neve alapján jön létre, például https://contoso.azurewebsites.net/.
4. A böngésző az identitásszolgáltatóhoz fordul a felhasználó hitelesítéséhez. A kérés tartalmazza a generált átirányítási URL-címet, amely jelzi, hogy a sikeres hitelesítés után hol adja vissza a felhasználót.
5. Az identitásszolgáltatóknak általában előre kell regisztrálniuk az átirányítási URL-címeket, ezért ezen a ponton az identitásszolgáltatónak el kell utasítania a kérést, mert a megadott átirányítási URL-cím nincs regisztrálva. (Nem kellett volna használni.) Ha azonban valamilyen okból az átirányítási URL-cím regisztrálva van, az identitásszolgáltató átirányítja a böngészőt a hitelesítési kérelemben megadott átirányítási URL-címre. Ebben az esetben az URL-cím a következő https://contoso.azurewebsites.net/: .
6. A böngésző ezt az URL-címet követi, amely a fordított proxy helyett közvetlenül a háttérszolgáltatáshoz kerül.

Hibás cookie-k

A gazdagépnév-eltérés akkor is problémákhoz vezethet, ha az alkalmazáskiszolgáló cookie-kat ad ki, és a bejövő gazdagép nevével hozza létre a Domain cookie attribútumát. A Domain attribútum biztosítja, hogy a cookie csak az adott tartományhoz legyen használva. Ezeket a cookie-kat az alkalmazáskód vagy a korábban már említett platformfunkciók, például az App Service ARR affinitási beállítása hozhatja létre. Ez az ábra a következő problémát szemlélteti:

1. A böngésző kérést küld a fordított proxynak contoso.com .
2. A fordított proxy újraírja a háttérbeli webalkalmazásnak (vagy egy másik szolgáltatáshoz hasonló alapértelmezett tartománynak) küldött kérésben szereplő contoso.azurewebsites.net gazdagépnevet.
3. Az alkalmazás létrehoz egy cookie-t, amely egy tartományt használ a bejövő contoso.azurewebsites.net gazdagép neve alapján. A böngésző a felhasználó által ténylegesen használt tartomány helyett contoso.com az adott tartományhoz tartozó cookie-t tárolja.
4. A böngésző nem tartalmazza a cookie-t semmilyen későbbi kéréshez contoso.com , mert a cookie tartománya contoso.azurewebsites.net nem egyezik meg a kérés tartományával. Az alkalmazás nem kapja meg a korábban kiadott cookie-t. Ennek következtében előfordulhat, hogy a felhasználó elveszíti a cookie-ban található állapotot, vagy az olyan funkciók, mint az ARR affinitás nem működnek. Sajnos ezek közül a problémák közül egyik sem okoz hibát, vagy közvetlenül látható a végfelhasználó számára. Ez megnehezíti a hibaelhárítást.

Bevezetési útmutató a gyakori Azure-szolgáltatásokhoz

Az itt tárgyalt lehetséges problémák elkerülése érdekében javasoljuk, hogy a fordított proxy és a háttéralkalmazás-kiszolgáló közötti hívásban őrizze meg az eredeti gazdagépnevet:

Háttérkonfiguráció

Számos webes üzemeltetési platform megköveteli, hogy explicit módon konfigurálja az engedélyezett bejövő gazdagépneveket. A következő szakaszok bemutatják, hogyan implementálható ez a konfiguráció a leggyakoribb Azure-szolgáltatásokhoz. Más platformok általában hasonló módszereket biztosítanak az egyéni tartományok konfigurálásához.

Ha a webalkalmazást az App Service-ben üzemelteti, csatolhat egy egyéni tartománynevet a webalkalmazáshoz, és elkerülheti az alapértelmezett azurewebsites.net gazdagépnevet a háttér felé. Ha egyéni tartományt csatol a webalkalmazáshoz, nem kell módosítania a DNS-feloldást: a tartományt rekord használatával TXT ellenőrizheti anélkül, hogy az hatással lenne a normál CNAME vagy A a rekordjaira. (Ezek a rekordok továbbra is a fordított proxy IP-címére lesznek feloldva.) Ha végpontok közötti TLS/SSL-t igényel, importálhat egy meglévő tanúsítványt a Key Vaultból, vagy használhat egy App Service-tanúsítványt az egyéni tartományához. (Vegye figyelembe, hogy az ingyenes Az App Service által felügyelt tanúsítvány ebben az esetben nem használható, mivel a tartomány DNS-rekordját közvetlenül az App Service-nek kell feloldani, nem pedig a fordított proxyt.)

Hasonlóképpen, ha Spring Appst használ, használhat egy egyéni tartományt az alkalmazáshoz, hogy elkerülje a azuremicroservices.io gazdagép nevét. Meglévő vagy önaláírt tanúsítványt importálhat, ha végpontok közötti TLS/SSL-t igényel.

Ha fordított proxyval rendelkezik az API Management előtt (amely maga is fordított proxyként működik), konfigurálhat egy egyéni tartományt az API Management-példányon, hogy elkerülje a azure-api.net gazdagépnév használatát. Meglévő vagy ingyenes felügyelt tanúsítványt importálhat, ha végpontok közötti TLS/SSL-t igényel. Ahogy korábban már említettük, az API-k kevésbé érzékenyek a gazdagépnév-eltérések által okozott problémákra, ezért előfordulhat, hogy ez a konfiguráció nem olyan fontos.

Ha alkalmazásait más platformokon, például a Kubernetesen vagy közvetlenül a virtuális gépeken üzemelteti, nincs beépített funkció, amely a bejövő gazdagép nevétől függ. Ön a felelős azért, hogy a gazdagép nevét maga az alkalmazáskiszolgáló hogyan használja. A gazdagép nevének megőrzésére vonatkozó javaslat általában továbbra is érvényes az alkalmazás minden olyan összetevőjére, amely attól függ, kivéve, ha kifejezetten tudatja az alkalmazással a fordított proxykat, és tiszteletben tartja például a fejléceket vagy X-Forwarded-Host a forwarded fejléceket.

Fordított proxykonfiguráció

Ha a fordított proxyn belül definiálja a háttérvégeket, továbbra is használhatja a háttérszolgáltatás alapértelmezett tartományát, például https://contoso.azurewebsites.net/. Ezt az URL-címet használja a fordított proxy a háttérszolgáltatás megfelelő IP-címének feloldásához. Ha a platform alapértelmezett tartományát használja, az IP-cím mindig garantáltan helyes lesz. Általában nem használhatja a nyilvános elérésű tartományt, például contoso.comazért, mert annak magának a fordított proxynak az IP-címére kell feloldódnia. (Hacsak nem használ fejlettebb DNS-feloldási technikákat, például Osztott horizontú DNS).

A legtöbb fordított proxy lehetővé teszi annak konfigurálását, hogy melyik gazdagépnevet adja át a háttérszolgáltatásnak. Az alábbi információk azt ismertetik, hogyan biztosítható, hogy a leggyakoribb Azure-szolgáltatások esetében a bejövő kérés eredeti állomásneve legyen használatban.

Application Gateway

Ha az Application Gatewayt használja fordított proxyként, a háttérBELI HTTP-beállítás felülbírálásának letiltásával gondoskodhat arról, hogy az eredeti gazdagép neve megmaradjon. Ezzel letiltja a gazdagép nevének kiválasztását a háttércímből és a felülbírálást adott tartománynévvel. (Mindkét beállítás felülírja a gazdagép nevét.) Az Application Gateway Azure Resource Manager-tulajdonságaiban ez a konfiguráció megfelel a hostName tulajdonság null beállításának és pickHostNameFromBackendAddress beállításának false.

Mivel az állapotmintákat a rendszer egy bejövő kérés környezetén kívül küldi el, nem tudják dinamikusan meghatározni a megfelelő gazdagépnevet. Ehelyett létre kell hoznia egy egyéni állapotmintát, le kell tiltania a gazdagép nevének kiválasztását a háttérBELI HTTP-beállításokból, és explicit módon meg kell adnia a gazdagép nevét. Ehhez a gazdagépnévhez egy megfelelő egyéni tartományt is használnia kell a konzisztencia érdekében. (Itt azonban használhatja az üzemeltetési platform alapértelmezett tartományát, mert az állapottesztek figyelmen kívül hagyják a helytelen cookie-kat vagy átirányítják a válasz URL-címeit.)

Azure Front Door

Ha az Azure Front Doort használja, elkerülheti a gazdagép nevének felülírását, ha üresen hagyja a háttér gazdagép fejlécét a háttérkészlet definíciójában. A háttérkészlet Resource Manager-definíciójában ez a konfiguráció a következő beállításnak backendHostHeader felel megnull: .

Ha az Azure Front Door Standard vagy a Premium verziót használja, a forrás gazdagép fejlécének üresen hagyásával megőrizheti a gazdagép nevét a forrásdefinícióban. A forrás Resource Manager-definíciójában ez a konfiguráció a következő beállításnak originHostHeader felel megnull: .

API Management

Az API Management alapértelmezés szerint felülbírálja a háttérbe küldött gazdagépnevet az API webszolgáltatás URL-címének gazdagép összetevőjével (amely megfelel az serviceUrl API Resource Manager-definíciójának értékének).

Az API Managementet kényszerítheti arra, hogy ehelyett használja a bejövő kérés állomásnevét egy inbound HTTP-fejlécházirend hozzáadásával, az alábbiak szerint:

<inbound>
  <base />
  <set-header name="Host" exists-action="override">
    <value>@(context.Request.OriginalUrl.Host)</value>
  </set-header>
</inbound>

Ahogy korábban már említettük, az API-k kevésbé érzékenyek a gazdagépnév-eltérések által okozott problémákra, ezért előfordulhat, hogy ez a konfiguráció nem olyan fontos.

Következő lépések

• App Service
• Spring Apps
• Application Gateway
• Azure Front Door
• API Management

Kapcsolódó erőforrások

• Zéró megbízhatóságú hálózat webalkalmazásokhoz az Azure Firewall és az Application Gateway használatával
• API-k védelme az Application Gateway és az API Management használatával
• Vállalati üzembe helyezés az App Services-környezettel