HAProxy 302 na súkromnú aplikáciu: kto otvára druhý skok?

Niekto nasmeruje verejný hostiteľ HAProxy na lokálnu aplikáciu a pýta sa, prečo prehliadač nevie pokračovať. Proxy sa k aplikácii dostane cez svoje VPN, presmerovanie vráti hlavičku Location a prehliadač potom skúsi adresu, ktorá existuje len vnútri tunela. Zvonku stránka jednoducho visí. Rozhodnutie je o tom, ktorá strana otvorí druhé spojenie, a práve to odlišuje presmerovanie od backendu.

Dve cesty, ktoré v konfigurácii vyzerajú podobne

Presmerovanie ukončí výmenu odpoveďou. Klient prečíta Location a začne novú požiadavku odtiaľ, kde práve sedí, teda zo siete, ktorú ste nikdy nekontrolovali. Proxy už nie je súčasťou. Všetko nasledujúce závisí od klientovho DNS, trasy a dôvery, takže výsledok sa líši podľa toho, kde používateľ otvoril prehliadač:

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

Backend proxy ponecháva druhý úsek na strane servera. Proxy ho otvorí po ceste, ktorú už má, a klient naďalej komunikuje s jedným verejným menom. Ak tunel spadne, klient dostane chybu namiesto URL, ktorú nevie nasledovať. Tento rozdiel je aj to, čo robí zlyhanie diagnostikovateľným, pretože chyba sa objaví tam, kde sú logy:

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

Dokumentácia HAProxy k presmerovaniam presne vytyčuje túto hranicu: odpovedať klientovi presmerovaním je iná akcia než preposlať požiadavku do backendu. Obe direktívy stoja v konfiguračnom súbore niekoľko riadkov od seba a správajú sa úplne odlišne. Jedna ukončí požiadavku a druhá začne druhú, ktorú vlastní proxy.

Čo prehliadač potrebuje a čo mu VPN servera nedá

Vlastná požiadavka prehliadača potrebuje štyri veci, ktoré mať nemusí: odpoveď DNS pre súkromné meno, trasu k tejto adrese, povolenie dostať sa k načúvajúcej službe a dôveru v certifikát, ktorý táto služba predloží. Hostiteľ proxy má všetky štyri vďaka svojmu tunelu. Žiadna z nich sa neprenáša na klienta, ktorý nikdy v tomto tuneli nebol, pretože tunel je vlastnosťou hostiteľa, nie URL.

Táto medzera vysvetľuje symptóm „takmer to funguje“. Prvá požiadavka prejde, adresný riadok sa zmení a spojenie potom visí alebo zlyhá, hoci proxy je celý čas zdravé. V konfigurácii proxy nie je nič pokazené a jej úprava nepomôže klientovi, ktorý nemá cestu k 10.40.0.20. Buď klient dostane trasu, alebo musí proxy vytvoriť spojenie za neho.

Keď sa k aplikácii dostane len proxy

Odstráňte akciu presmerovania a pošlite tie požiadavky do backendu, ktorý ukazuje na súkromnú adresu. Frontend si ponechá verejné meno, zatiaľ čo backend rozhodne, kam požiadavka skutočne ide. Na klientovej ceste sa nič nemení, pretože proxy prestane opisovať cieľ a samo sa ním stane. Pre aplikáciu, ktorá zámerne načúva na internom porte 8080, je blok servera krátky:

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

Čítajte ten blok ako tvrdenie o smerovacej tabuľke proxy: adresa 10.40.0.20 musí byť dostupná priamo z hostiteľa proxy, čo tu znamená cez rozhranie VPN, a nie cez predvolenú trasu. Kľúčové slovo check len hlási, čo táto trasa robí, a cesta kontroly zdravia musí v aplikácii existovať, inak každá sonda označí server ako nedostupný. Úspešná kontrola nič nedokazuje o klientovi a nenahrádza politiku, ktorá rozhoduje, kto smie backend používať.

Tento fragment nie je kompletný frontend. Zachovajte počúvajúci proces, autentifikáciu, výber povoleného hostiteľa a cesty aj pravidlo, ktoré rozhoduje, kto sa k aplikácii vôbec dostane. Zlaďte aj protokol backendu, pretože HTTPS backend potrebuje overenie certifikátu a konfiguráciu identity servera, a vynechanie tejto kontroly mení súkromné spojenie na neoverené.

Predtým než vyhlásite víťazstvo, potvrďte spätnú cestu v oboch smeroch. Aplikácia teraz vidí spojenie od proxy, takže jej logy a akékoľvek metadáta o adrese klienta opisujú proxy, ak to nezariadite inak. Rozhodnite, ako sa spracúva identita a preposielané adresy, a toto rozhodnutie otestujte, namiesto toho, aby ste ho predpokladali.

Vlastné presmerovania aplikácie stále mieria dovnútra

Preposlanie prvej požiadavky je len polovica integrácie. Aplikácia môže vydávať absolútne presmerovania, natvrdo zadané URL zdrojov alebo cookies viazané na meno, ktoré pozná zvnútra, a každé z toho pošle prehliadač späť na adresu, ku ktorej sa nedostane. Hlavička Location ukazujúca na interné meno vyzerá rovnako ako pôvodný problém, a preto sa chybne diagnostikuje ako zlyhanie proxy.

Nastavte dokumentovanú externú URL aplikácie a jej možnosti proxy, potom zlaďte hlavičku Host s virtuálnym hostiteľom a očakávaniami certifikátu. Cookie viazaná na interné meno sa cez verejné meno nevráti a cyklus prihlásenia, ktorý nasleduje, sa číta ako chyba autentifikácie. Najprv zmeňte externú URL, otestujte to z čistého profilu prehliadača a očakávajte, že napoly presunuté nastavenia prinesú prihlásenie, ktoré uspeje, a reláciu, ktorá hneď zomrie.

Dôverujte preposielaným metadátam len od určeného proxy. Hlavička, ktorú môže nastaviť ktorýkoľvek klient, sa nikdy nesmie stať hodnotou autorizácie, inak sa proxy zmení na spôsob, ako si volajúci prisvoji identitu niekoho iného. Toto pravidlo nezávisí od otázky presmerovania a prežije každý ďalší redizajn.

Rozhodnite, ktorý dizajn skutočne máte

Ak všetci používatelia už majú autorizovaný prístup cez VPN, presmerovanie na súkromnú URL môže byť zámerný dizajn. Potvrďte túto požiadavku výslovne, namiesto toho, aby ste ju predpokladali, pretože tieto dva dizajny obsluhujú úplne odlišné skupiny. Jeden z nich cez hotelovú sieť nefunguje vôbec a druhý vystavuje aplikáciu každému, kto si môže načítať verejnú URL. Tento rozdiel patrí do projektovej poznámky.

Spustite kontrolu zo stroja v používateľskej sieti a sledujte každý skok, ktorý prehliadač urobí, nielen prvú odpoveď. Sledujte adresný riadok a každú nasledujúcu požiadavku, pretože jediná absolútna URL v značke zdroja stačí na to, aby pokazila tok, ktorý prvý skok prešiel. Prihlásenie musí fungovať cez verejné meno a zdroje, ktoré majú byť zamietnuté, musia zostať zamietnuté.

Zverejnenie reverzného proxy je samostatné rozhodnutie o prístupe, nie transparentné rozšírenie vlastného VPN proxy na každého, kto si môže načítať jeho verejnú URL. Na diagrame vyzerajú obe rovnako a líšia sa v tom, kto smie dnu. Rozhodovať o tejto otázke až po nasadení je spôsob, ako sa z internej aplikácie stane omylom verejná.

Napíšte, ktorý z nich ste postavili a prečo. Ďalší človek, ktorý sa dotkne konfigurácie, bude predpokladať ten druhý. Jediné presmerovanie pridané pre pohodlie stačí na obnovenie pôvodného zlyhania a symptóm bude vyzerať presne ako ten, ktorý ste práve opravili.