HAProxy 302 egy privát alkalmazáshoz: ki nyitja a második ugrást?

Valaki egy nyilvános HAProxy-gazdagépet egy belső alkalmazásra irányít, és azt kérdezi, miért nem tud a böngésző követni. A proxy a VPN-jén keresztül éri el az alkalmazást, az átirányítás visszaad egy Location fejlécet, a böngésző pedig olyan címre próbál menni, amely csak az alagúton belül létezik. Kívülről az oldal egyszerűen megakad. A döntés arról szól, melyik fél nyitja a második kapcsolatot, és pont ez választja el az átirányítást a backendtől.

Két útvonal, amely a konfigurációban hasonlónak látszik

Az átirányítás válasszal zárja a cserét. A kliens elolvassa a Locationt, és új kérést indít onnan, ahol éppen van, vagyis abból a hálózatból, amelyet soha nem irányított. A proxy már nem vesz részt benne. Minden további a kliens saját DNS-étől, útvonalától és bizalmától függ, ezért az eredmény attól függ, hol nyitotta meg a felhasználó a böngészőt:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

A proxy backend a második szakaszt a kiszolgáló oldalán tartja. A proxy a már meglévő útvonalán nyitja meg, és a kliens továbbra is egyetlen nyilvános névvel beszél. Ha az alagút megszakad, a kliens hibát kap olyan URL helyett, amelyet nem tud követni. Ez a különbség teszi a hibát diagnosztizálhatóvá is, mert a hiba ott jelenik meg, ahol a naplók vannak:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

A HAProxy átirányítási dokumentációja pontosan ezt a határvonalat húzza meg: átirányítással válaszolni a kliensnek más művelet, mint a kérést egy backendnek továbbítani. A két direktíva néhány sorra van egymástól egy konfigurációs fájlban, és teljesen másképp viselkedik. Az egyik lezárja a kérést, a másik elkezd egy másodikat, amely a proxyé.

Amire a böngészőnek szüksége van, és amit a kiszolgáló VPN-je nem ad meg neki

A böngésző saját kérésének négy dologra van szüksége, ami esetleg nincs meg: DNS-válaszra a privát névhez, útvonalra ahhoz a címhez, engedélyre a figyelő szolgáltatás eléréséhez, és bizalomra abban a tanúsítványban, amelyet az a szolgáltatás bemutat. A proxy gazdagépe mind a négyet az alagútján keresztül birtokolja. Egyik sem terjed át olyan kliensre, amely soha nem járt abban az alagútban, mert az alagút a gazdagép tulajdonsága, nem az URL-é.

Ez a szakadék magyarázza a majdnem-működik tünetet. Az első kérés sikerül, a címsor megváltozik, majd a kapcsolat megakad vagy meghiúsul, miközben a proxy végig egészséges. A proxy konfigurációjában semmi sem tört el, és annak hangolása nem segít olyan kliensen, amelynek nincs útvonala a 10.40.0.20-hoz. Vagy a kliens kap útvonalat, vagy a proxynek kell helyette létrehoznia a kapcsolatot.

Amikor csak a proxy érheti el az alkalmazást

Távolítsa el az átirányítási műveletet, és küldje ezeket a kéréseket egy backendnek, amely a privát címre mutat. A frontend megtartja nyilvános nevét, miközben a backend eldönti, hová megy valójában a kérés. A kliens útvonalában semmi sem változik, mert a proxy felhagy a cél leírásával, és maga lesz a cél. Egy olyan alkalmazás esetében, amely szándékosan a belső 8080-as porton figyel, a kiszolgálóblokk rövid:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

Olvassa ezt a blokkot a proxy útválasztási táblájáról szóló állításként: a 10.40.0.20-nak magából a proxy gazdagépből elérhetőnek kell lennie, ami itt a VPN-interfészen keresztül értendő, nem az alapértelmezett útvonalon. A check kulcsszó csak azt jelenti, hogy mit tesz ez az útvonal, és az egészségügyi útvonalnak léteznie kell az alkalmazáson, különben minden próba leállítottnak jelöli a kiszolgálót. Egy sikeres ellenőrzés semmit sem bizonyít a kliensről, és nem pótolja azt a szabályzatot, amely eldönti, ki használhatja a backendet.

A töredék nem teljes frontend. Tartsa meg a figyelőt, a hitelesítést, az engedélyezett gazdagép és útvonal kiválasztását, és azt a szabályt, amely eldönti, ki egyáltalán elérheti az alkalmazást. Igazítsa a backend protokolljához is, mert egy HTTPS backend tanúsítvány-ellenőrzést és kiszolgálóidentitás-konfigurációt igényel, és ennek az ellenőrzésnek a kihagyása privát kapcsolatot tesz ellenőrizetlenné.

Erősítse meg a visszautat mindkét irányban, mielőtt győzelmet hirdet. Az alkalmazás most a proxytól érkező kapcsolatot lát, ezért naplói és minden klienscím-metaadat a proxyt írja le, hacsak másképp nem rendezi. Döntse el, hogyan kezelik az identitást és a továbbított címeket, és tesztelje a döntést ahelyett, hogy feltételezné.

Az alkalmazás saját átirányításai még mindig befelé mutatnak

Az első kérés továbbítása csak az integráció fele. Az alkalmazás abszolút átirányításokat, keményen kódolt eszköz-URL-eket vagy a belsőleg ismert névre korlátozott sütiket bocsáthat ki, és ezek mindegyike visszaküldi a böngészőt egy címre, amelyet nem tud elérni. A belső névre mutató Location fejléc pontosan úgy néz ki, mint az eredeti probléma, ezért tévesen proxyhibának diagnosztizálják.

Állítsa be az alkalmazás dokumentált külső URL-jét és proxybeállításait, majd igazítsa a Host fejlécet a virtuális gazdagéphez és a tanúsítvány elvárásaihoz. A belső névre korlátozott süti nem jön vissza a nyilvános néven, és az ezt követő bejelentkezési hurok hitelesítési hibaként olvasható. Először a külső URL-t változtassa meg, teszteljen újra tiszta böngészőprofilból, és számítson rá, hogy a félig áttelepített beállítások sikeres bejelentkezést és azonnal meghaló munkamenetet eredményeznek.

Csak a kijelölt proxytól érkező továbbított metaadatokban bízzon. Az a fejléc, amelyet bármely kliens beállíthat, soha nem válhat engedélyezési értékké, különben a proxy eszközzé válik arra, hogy a hívó másvalaki identitását követelje. Ez a szabály független az átirányítás kérdésétől, és minden későbbi újratervezést túlél.

Döntse el, melyik tervvel rendelkezik valójában

Ha minden felhasználónak már van engedélyezett VPN-hozzáférése, a privát URL-re mutató átirányítás szándékos terv is lehet. Erősítse meg ezt a követelményt kifejezetten ahelyett, hogy feltételezné, mert a két terv teljesen különböző csoportokat szolgál ki. Az egyik egyáltalán nem működik szállodai hálózatról, a másik pedig mindenkinek feltárja az alkalmazást, aki be tudja tölteni a nyilvános URL-t. Ez a megkülönböztetés a tervezési feljegyzésbe tartozik.

Futtassa az ellenőrzést a felhasználók hálózatán lévő gépről, és kövessen minden ugrást, amelyet a böngésző tesz, ne csak az első választ. Figyelje a címsort és minden további kérést, mert egyetlen abszolút URL egy eszközcímkében elég ahhoz, hogy megtörjön egy folyamatot, amelyet az első ugrás átlépett. A bejelentkezésnek a nyilvános néven keresztül kell működnie, és az elutasítandó erőforrásoknak elutasítottnak kell maradniuk.

Egy fordított proxy közzététele külön hozzáférési döntés, nem a proxy saját VPN-jének átlátszó kiterjesztése mindenkire, aki be tudja tölteni a nyilvános URL-jét. A kettő hasonlónak látszik egy diagramon, és abban különböznek, kit engednek be. Ha ezt a kérdést a telepítés után dönti el, abból lesz a belső alkalmazásból véletlenül nyilvános.

Írja le, melyiket építette a kettő közül, és miért. A következő ember, aki a konfigurációhoz nyúl, a másikat fogja feltételezni. Egyetlen kényelemből hozzáadott átirányítás elég az eredeti hiba újra létrehozásához, és a tünet pontosan úgy fog kinézni, mint amit éppen most javított.