HAProxy 302 zu enger privater App: wien öffnet den zweiten Sprong?

Een richtet en ëffentlechen HAProxy-Host op eng intern Applikatioun a freet, firwat de Browser net ka follegen. De Proxy erreecht d'App duerch säin VPN, d'Ëmleitung gëtt e Location-Header zréck, an de Browser probéiert dann eng Adress, déi et just am Tunnel gëtt. Vun dobaussen hänkt d'Säit just. D'Entscheedung ass, wéi eng Säit déi zweet Verbindung opmécht, an dat ass wat eng Ëmleitung vun engem Backend trennt.

Zwee Weeër, déi an der Konfiguratioun ähnlech ausgesinn

Eng Ëmleitung beendet den Austausch mat enger Äntwert. De Client liest Location a fänkt eng nei Ufro un, vun do wou hien ass, also aus dem Netz, dat Dir ni kontrolléiert hutt. De Proxy ass net méi bedeelegt. Alles wat duerno kënnt, hänkt vum Client sengem eigenen DNS, senger Route a sengem Vertrauen of, dofir variéiert d'Resultat je nodeem wou de Benotzer de Browser opgemaach huet:

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

En Proxy-Backend hält déi zweet Etapp op der Serversäit. De Proxy mécht se iwwer de Wee op, deen en schonn huet, an de Client schwätzt weider mat engem ëffentlechen Numm. Fält den Tunnel aus, kritt de Client e Feeler amplaz enger URL, där en net ka follegen. Dee Ënnerscheed mécht de Feeler och diagnostizéierbar, well de Feeler do erschéngt wou d'Logbicher sinn:

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

HAProxy seng Dokumentatioun iwwer Ëmleitungen zitt genee déi Linn: dem Client mat enger Ëmleitung äntweren ass eng aner Aktioun wéi d'Ufro un e Backend weiderzeleeden. Déi zwou Direktiven stinn an enger Konfiguratiounsdatei e puer Zeilen auseneen a behuelen sech komplett anescht. Déi eng beendet d'Ufro, déi aner fänkt eng zweet un, déi dem Proxy gehéiert.

Wat de Browser brauch an de VPN vum Server him net gëtt

D'Ufro vum Browser selwer brauch véier Saachen, déi en vläicht net huet: eng DNS-Äntwert fir den privaten Numm, eng Route zu där Adress, d'Erlaabnes dee lauschende Service z'erreechen, an d'Vertraue fir de Certificat, deen dee Service presentéiert. De Proxy-Host huet all véier duerch säin Tunnel. Keng dovun geet un e Client, dee ni an deem Tunnel war, well den Tunnel eng Eegenschaft vum Host ass, net vun der URL.

Dee Spalt erkläert de Symptom bal-funktionnéiert. Déi éischt Ufro geléngt, d'Adressleescht ännert sech, an duerno hänkt oder feelt d'Verbindung, während de Proxy déi ganz Zäit gesond ass. An der Proxy-Konfiguratioun ass näischt futti, an se upassen hëlleft engem Client net, deen keen Wee op 10.40.0.20 huet. Entweder de Client kritt eng Route, oder de Proxy muss d'Verbindung fir hien opbauen.

Wann nëmmen de Proxy d'App erreeche kann

Huelt d'Ëmleitungsaktioun ewech a schéckt déi Ufroe un e Backend, deen op déi privat Adress weist. De Frontend behält säin ëffentlechen Numm, während de Backend decidéiert wou d'Ufro wierklech hi geet. Um Wee vum Client ännert sech näischt, well de Proxy ophält en Zil ze beschreiwen a fänkt un et ze sinn. Fir eng Applikatioun, déi bewosst op der interner Port 8080 lauscht, ass de Serverblock kuerz:

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

Liest dee Block als Ausso iwwer d'Routingtabell vum Proxy: 10.40.0.20 muss vum Proxy-Host selwer erreechbar sinn, wat hei duerch d'VPN-Interface bedeit an net duerch déi standardméisseg Route. D'Schlësselwuert check mellt just wat déi Route mécht, an de Gesondheetswee muss op der Applikatioun existéieren, soss markéiert all Prüfung de Server als erof. Eng bestanen Prüfung beweist näischt iwwer de Client an ersetzt net d'Politik, déi decidéiert wien de Backend benotze kann.

De Fragment ass keen vollstännege Frontend. Behält de Lauschterer, d'Authentifikatioun, d'Auswiel vun erlaabtem Host a Wee, an d'Reegel déi decidéiert wien iwwerhaapt d'Applikatioun erreeche kann. Passt och de Backend-Protokoll un, well en HTTPS-Backend Certificatsprüfung an eng Server-Identitéitskonfiguratioun brauch, an dës Prüfung iwwersprangen mécht aus enger privater Verbindung eng onverifizéiert.

Bestätegt de Wee zréck a béide Richtungen, ier Dir de Sieg ausrufft. D'Applikatioun gesäit elo eng Verbindung vum Proxy, also beschreiwen hir Logbicher an all Clientadress-Metadaten de Proxy, ausser Dir arrangéiert anescht. Entscheet wéi Identitéit a weidergereede Adressen behandelt ginn, an test d'Entscheedung amplaz se unzehuelen.

D'App hir eege Ëmleitungen weisen nach ëmmer no bannen

Déi éischt Ufro weiderzeleeden ass just d'Halschent vun der Integratioun. D'Applikatioun kann absolut Ëmleitungen, haart kodéiert Asset-URLen oder Cookien ausginn, déi op den Numm limitéiert sinn, deen se intern kennt, an all dat schéckt de Browser zréck op eng Adress, déi en net erreeche kann. En Location-Header, deen op den internen Numm weist, gesäit identesch aus wéi dat ursprénglecht Problem, dofir gëtt et falsch als Proxy-Feeler diagnostizéiert.

Setzt déi dokumentéiert extern URL vun der Applikatioun an hir Proxy-Optiounen, an da bréngt den Host-Header mat dem virtuelle Host an den Erwaardunge vum Certificat an Einklang. E Cookie, deen op den internen Numm limitéiert ass, kënnt net iwwer den ëffentlechen Numm zréck, an d'Umeldungsschleef déi duerno kënnt liest sech wéi en Authentifikatiounsfeeler. Ännert als éischt déi extern URL, test nach eng Kéier aus engem proppere Browserprofil, a rechent domat datt hallef migréiert Astellungen eng Umeldung produzéieren déi geléngt an eng Sessioun déi direkt stierft.

Vertraut weidergereede Metadaten nëmmen vum designéierte Proxy. En Header, deen all Client setze kann, däerf ni en Autorisatiounswäert ginn, soss gëtt de Proxy e Wee fir en Uruffer fir d'Identitéit vun engem aneren ze behaapten. Dës Reegel ass onofhängeg vun der Ëmleitungsfro an iwwerlieft all spéider Redesign.

Entscheet wéi en Design Dir tatsächlech hutt

Wann all Benotzer schonn autoriséierten VPN-Zougang huet, kann eng Ëmleitung op eng privat URL en bewussten Design sinn. Bestätegt déi Fuerderung ausdrécklech amplaz se unzehuelen, well déi zwee Designen komplett ënnerschiddlech Populatiounen déngen. Eent dovun funktionéiert iwwerhaapt net aus engem Hotelnetz, an dat anert setzt d'Applikatioun fir jiddereen aus, deen déi ëffentlech URL luede kann. Dee Grond ënnerscheet gehéiert an d'Designnotiz.

Féiert d'Prüfung vun enger Maschinn am Benotzernetz aus a verfollegt all Sprong dee de Browser mécht, net just déi éischt Äntwert. Haalt d'Adressleescht an all weider Ufro am A, well eng eenzeg absolut URL an engem Asset-Tag duergeet fir e Floss ze briechen, deen den éischte Sprong bestanen huet. D'Umeldung muss iwwer den ëffentlechen Numm funktionéieren, an d'Ressourcen déi refuséiert solle ginn, mussen refuséiert bleiwen.

E Reverse-Proxy publizéieren ass eng getrennt Zougangsentscheedung, keng transparent Erweiderung vum Proxy sengem eigenen VPN op jiddereen, deen seng ëffentlech URL luede kann. Déi zwee gesinn op engem Diagramm ähnlech aus, a si ënnerscheede sech doranner wien erageholl gëtt. Dës Fro no der Deployement ze entscheeden ass de Wee wéi eng intern Applikatioun zoufälleg ëffentlech gëtt.

Schreift op wéi eng vun den zwee Dir gebaut hutt a firwat. Déi nächst Persoun, déi d'Konfiguratioun ufässt, wäert déi aner unhuelen. Eng eenzeg Ëmleitung, déi aus Bequemlechkeet bäigefüügt gouf, duergeet fir de urspréngleche Feeler ëmmer erëm ze schafen, an de Symptom wäert genee wéi deen ausgesinn, deen Dir just fléckt hutt.