HAProxy 302 na privátní aplikaci: kdo otevírá druhý skok?

Přesměrování vrací druhé spojení zpět do prohlížeče. Pošlete požadavek raději na backend a potom opravte vlastní absolutní přesměrování a cookies aplikace.

Někdo nasměruje veřejný host HAProxy na interní aplikaci a ptá se, proč jej prohlížeč nemůže následovat. Proxy se k aplikaci dostane přes svůj VPN, přesměrování vrátí hlavičku Location a prohlížeč pak zkusí adresu, která existuje jen uvnitř tunelu. Zvenku stránka prostě zamrzne. Rozhodnutí je o tom, která strana otevírá druhé spojení, a právě to odlišuje přesměrování od backendu.

Dvě cesty, které v konfiguraci vypadají podobně

Přesměrování ukončí výměnu odpovědí. Klient přečte Location a zahájí nový požadavek od místa, kde se nachází, tedy ze sítě, kterou jste nikdy nekontrolovali. Proxy už není zapojena. Vše další závisí na DNS, trase a důvěře samotného klienta, takže výsledek se liší podle toho, kde uživatel prohlížeč otevřel:

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 drží druhou etapu na straně serveru. Proxy ji otevře po cestě, kterou už má, a klient dál mluví s jedním veřejným jménem. Pokud tunel spadne, klient dostane chybu místo URL, kterou nemůže následovat. Právě tento rozdíl dělá poruchu diagnostikovatelnou, protože chyba se objeví tam, kde jsou logy:

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

Dokumentace přesměrování od HAProxy kreslí přesně tuto hranici: odpovědět klientovi přesměrováním je jiná akce než předat požadavek backendu. Obě direktivy stojí v konfiguračním souboru několik řádků od sebe a chovají se naprosto odlišně. Jedna požadavek ukončí, druhá začne druhý, který patří proxy.

Co prohlížeč potřebuje a co mu VPN serveru nedává

Požadavek samotného prohlížeče potřebuje čtyři věci, které mít nemusí: odpověď DNS pro privátní jméno, trasu k této adrese, oprávnění dosáhnout naslouchající služby a důvěru v certifikát, který tato služba předloží. Host proxy má všechny čtyři díky svému tunelu. Nic z toho se nepřenáší na klienta, který v tomto tunelu nikdy nebyl, protože tunel je vlastnost hostu, ne URL.

Tato mezera vysvětluje symptom skoro to funguje. První požadavek uspěje, adresní řádek se změní a spojení se pak zablokuje nebo selže, zatímco proxy je celou dobu zdravá. V konfiguraci proxy není nic rozbité a její úprava nepomůže klientovi, který nemá cestu k 10.40.0.20. Buď klient dostane trasu, nebo proxy musí spojení vytvořit za něj.

Když se k aplikaci dostane jen proxy

Odstraňte akci přesměrování a pošlete tyto požadavky na backend, který ukazuje na privátní adresu. Frontend si zachová své veřejné jméno, zatímco backend rozhoduje, kam požadavek skutečně jde. Na cestě klienta se nic nemění, protože proxy přestává popisovat cíl a začíná jím být. Pro aplikaci, která záměrně naslouchá na interním portu 8080, je blok serveru krátký:

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

Čtěte tento blok jako tvrzení o směrovací tabulce proxy: 10.40.0.20 musí být dosažitelná z hostu proxy samotného, což zde znamená přes rozhraní VPN, nikoli přes výchozí trasu. Klíčové slovo check pouze hlásí, co tato trasa dělá, a zdravotní cesta musí v aplikaci existovat, jinak každá sonda označí server jako nedostupný. Úspěšná kontrola nic nedokazuje o klientovi a nenahrazuje politiku, která rozhoduje, kdo smí backend používat.

Fragment není úplný frontend. Zachovejte listener, autentizaci, výběr povoleného hostu a cesty a pravidlo, které rozhoduje, kdo se vůbec smí k aplikaci dostat. Sladěte i protokol backendu, protože HTTPS backend vyžaduje ověření certifikátu a konfiguraci identity serveru, a vynechání této kontroly mění privátní spojení na neověřené.

Potvrďte zpáteční cestu v obou směrech, než vyhlásíte vítězství. Aplikace nyní vidí spojení z proxy, takže její logy a jakákoli metadata adresy klienta popisují proxy, pokud nezařídíte jinak. Rozhodněte, jak se zachází s identitou a předávanými adresami, a rozhodnutí otestujte, místo abyste je předpokládali.

Vlastní přesměrování aplikace stále míří dovnitř

Předání prvního požadavku je jen polovina integrace. Aplikace může vydávat absolutní přesměrování, natvrdo zapsané URL aktiv nebo cookies vázané na jméno, které zná interně, a každé z toho vrací prohlížeč na adresu, kterou nemůže dosáhnout. Hlavička Location ukazující na interní jméno vypadá stejně jako původní problém, a proto bývá chybně diagnostikována jako porucha proxy.

Nastavte dokumentovanou externí URL aplikace a její možnosti proxy, potom sladěte hlavičku Host s virtuálním hostem a očekáváním certifikátu. Cookie vázaná na interní jméno se veřejným jménem nevrátí a přihlašovací smyčka, která následuje, se čte jako chyba autentizace. Nejprve změňte externí URL, otestujte znovu z čistého profilu prohlížeče a očekávejte, že napůl migrovaná nastavení vytvoří přihlášení, které uspěje, a session, která okamžitě umře.

Věřte předávaným metadatům jen od určené proxy. Hlavička, kterou může nastavit každý klient, se nikdy nesmí stát autorizační hodnotou, jinak se proxy změní na způsob, jak si volající nárokuje cizí identitu. Toto pravidlo je nezávislé na otázce přesměrování a přežije každý pozdější redesign.

Rozhodněte, který návrh skutečně máte

Pokud už každý uživatel má autorizovaný přístup k VPN, přesměrování na privátní URL může být záměrný návrh. Potvrďte tento požadavek výslovně, místo abyste ho předpokládali, protože oba návrhy slouží zcela odlišným skupinám. Jeden z nich z hotelové sítě vůbec nefunguje a druhý vystavuje aplikaci každému, kdo může načíst veřejnou URL. Toto rozlišení patří do poznámky k návrhu.

Spusťte kontrolu ze stroje v síti uživatelů a sledujte každý skok prohlížeče, ne jen první odpověď. Sledujte adresní řádek a každý další požadavek, protože jediná absolutní URL ve značce aktiva stačí k rozbití toku, který první skok prošel. Přihlášení musí fungovat přes veřejné jméno a zdroje, které mají být odmítnuty, musí zůstat odmítnuté.

Zveřejnění reverzní proxy je samostatné rozhodnutí o přístupu, nikoli průhledné rozšíření vlastní VPN proxy na každého, kdo může načíst její veřejnou URL. Obojí vypadá na diagramu stejně a liší se v tom, kdo smí dovnitř. Rozhodnout tuto otázku až po nasazení je způsob, jak se z interní aplikace nedopatřením stane veřejná.

Zapište, kterou ze dvou variant jste postavili a proč. Další člověk, který se konfigurace dotkne, bude předpokládat tu druhou. Jediné přesměrování přidané pro pohodlí stačí k obnovení původní poruchy a symptom bude vypadat přesně jako ten, který jste právě opravili.

Související články