HAProxy 302 aplikazio pribatu batera: nork irekitzen du bigarren jauzia?

Norbaitek HAProxy ostalari publiko bat barneko aplikazio batera zuzentzen du eta galdetzen du zergatik ezin duen nabigatzaileak jarraitu. Proxyak VPN bidez iristen da aplikaziora, birbideratzeak Location goiburua itzultzen du, eta nabigatzaileak tunelean soilik existitzen den helbide bat saiatzen du orduan. Kanpotik orrialdea besterik gabe zintzilik geratzen da. Erabakia bigarren konexioa zein alde irekitzen duen da, eta hori da birbideratze bat backend batetik bereizten duena.

Konfigurazioan antzekoak diruditen bi bide

Birbideratze batek erantzun batekin amaitzen du trukea. Bezeroak Location irakurtzen du eta eskaera berri bat hasten du dagoen tokietik, hau da, sekula kontrolatu ez zenuten sarean. Proxyak ez du parte hartzen. Ondorengo guztia bezeroaren DNS, bide eta konfiantzaren araberakoa da, beraz emaitza aldatzen da erabiltzaileak nabigatzailea non ireki zuen arabera:

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

Proxyaren backend batek bigarren etapa zerbitzariaren aldean mantentzen du. Proxyak jada duen bidearen bidez irekitzen du, eta bezeroak izen publiko bakarrarekin hitz egiten jarraitzen du. Tunelak huts egiten badu, bezeroak errore bat jasotzen du jarraitu ezin duen URL baten ordez. Alde horrek egiten du akatsa diagnostikagarri, errorea erregistroak dauden tokian agertzen delako:

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

HAProxyren birbideratze dokumentazioak hain zuzen lerro hori marrazten du: bezeroari birbideratze batekin erantzutea eskaera backend batera bidaltzearen ekintza desberdina da. Bi direktibak konfigurazio fitxategi batean lerro gutxi batzuk bananduta daude eta guztiz desberdin jokatzen dute. Batek eskaera amaitzen du, besteak proxyaena den bigarren bat hasten du.

Nabigatzaileak behar duena eta zerbitzariaren VPNak ematen ez diona

Nabigatzailearen beraren eskaerak agian ez dituen lau gauza behar ditu: izen pribatuarentzako DNS erantzun bat, helbide horretarako bide bat, entzuten ari den zerbitzura iristeko baimena, eta zerbitzu horrek aurkezten duen ziurtagirian konfiantza. Proxyaren ostalariak laurak ditu bere tunelaren bidez. Horietako bat ere ez da inoiz tunel horretan egon ez den bezero batera pasatzen, tunela ostalariaren propietatea delako, ez URLarena.

Hutsune horrek ia-funtzionatzen duen sintoma azaltzen du. Lehen eskaerak arrakasta du, helbide-barra aldatzen da, eta gero konexioa zintzilik geratzen edo huts egiten du proxyak denbora osoan osasuntsu jarraitzen duen bitartean. Ez dago ezer hautsita proxyaren konfigurazioan, eta hura doitzeak ez dio laguntzen 10.40.0.20-ra biderik ez duen bezero bati. Edo bezeroak bide bat lortzen du, edo proxyak beraren ordez egin behar du konexioa.

Proxyak bakarrik irits daitekeenean aplikaziora

Kendu birbideratze ekintza eta bidali eskaera horiek helbide pribatura seinalatzen duen backend batera. Frontendak bere izen publikoa mantentzen du, backendak eskaera benetan nora doan erabakitzen duen bitartean. Bezeroaren bidean ezer ez da aldatzen, proxyak helmuga bat deskribatzeari uzten diolako eta hura izaten hasten delako. Barneko 8080 portuan nahita entzuten duen aplikazio batentzat, zerbitzari blokea laburra da:

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

Irakurri bloke hori proxyaren bideratze taulari buruzko baieztapen gisa: 10.40.0.20 proxyaren ostalaritik bertatik irisgarria izan behar da, eta horrek hemen VPN interfazearen bidez esan nahi du, ez bide lehenetsiaren bidez. check gako-hitzak bide horrek egiten duena baino ez du jakinarazten, eta osasun-bideak aplikazioan egon behar du, bestela proba bakoitzak zerbitzaria behera markatuko du. Gainditutako egiaztapen batek ezer ez du frogatzen bezeroari buruz eta ez du backend-a nork erabil dezakeen erabakitzen duen politika ordezkatzen.

Zatia ez da frontend oso bat. Mantendu entzulea, autentifikazioa, baimendutako ostalari eta bideen hautaketa, eta aplikaziora nork irits daitekeen erabakitzen duen araua. Egokitu backend protokoloa ere, HTTPS backend batek ziurtagiri egiaztapena eta zerbitzariaren identitate konfigurazioa behar dituelako, eta egiaztapen hori saltatzeak konexio pribatu bat egiaztatu gabeko bihurtzen du.

Baieztatu itzulera-bidea bi noranzkoetan garaipena aldarrikatu aurretik. Aplikazioak proxyaren konexio bat ikusten du orain, beraz bere erregistroek eta bezeroaren helbidearen metadatuek proxya deskribatzen dute, beste modu batera antolatzen ez baduzu. Erabaki nola kudeatzen diren identitatea eta birbidalitako helbideak, eta probatu erabakia, suposatu beharrean.

Aplikazioaren beraren birbideratzeek barrura seinalatzen dute oraindik

Lehen eskaera birbidaltzea integrazioaren erdia baino ez da. Aplikazioak birbideratze absolutoak, eskuz kodetutako aktibo URLak edo barruan ezagutzen duen izenera mugatutako cookieak igor ditzake, eta horietako bakoitzak nabigatzailea irits ezin duen helbide batera bidaltzen du. Barne izenera seinalatzen duen Location goiburuak jatorrizko problemaren itxura bera du, eta horregatik oker diagnostikatzen da proxyaren akats gisa.

Ezarri aplikazioaren dokumentatutako kanpoko URLa eta bere proxy aukerak, gero egin Host goiburua ostalari birtualarekin eta ziurtagiriaren itxaropenekin bat. Barne izenera mugatutako cookie bat ez da izen publikoaren bidez itzuliko, eta jarraian datorren saio-hasiera begizta autentifikazio akats gisa irakurtzen da. Aldatu kanpoko URLa lehenengo, probatu berriro nabigatzaile profil garbi batetik, eta espero ezazu erdi-migratutako ezarpenek lortzen duen saio-hasiera eta berehala hiltzen den saio bat sortzea.

Konfiantza birbidalitako metadatuetan soilik izendatutako proxyarengan. Edozein bezerok ezar dezakeen goiburu bat ez da inoiz autorizazio balio bihurtu behar, bestela proxya deitzaile batek beste norbaiten identitatea aldarrikatzeko bide bihurtzen da. Arau hori birbideratze galderatik independentea da eta geroagoko berregituraketa oro gainditzen du.

Erabaki zein diseinu duzun benetan

Erabiltzaile bakoitzak jada baimendutako VPN sarbidea badu, URL pribatu baterako birbideratzea diseinu nahita izan daiteke. Baieztatu baldintza hori espresuki, suposatu beharrean, bi diseinuek erabat desberdinak diren populazioei zerbitzatzen dietelako. Horietako batek ez du batere funtzionatzen hoteleko sare batetik, eta besteak aplikazioa URL publikoak kargatu dezakeen edonorentzat uzten du. Bereizketa hori diseinu oharrean dagokio.

Exekutatu egiaztapena erabiltzaileen sareko makina batetik eta jarraitu nabigatzaileak egiten duen jauzi bakoitza, ez lehen erantzuna soilik. Begiratu helbide-barra eta ondorengo eskaera bakoitza, aktibo etiketa bateko URL absolutu bakar bat nahikoa delako lehen jauziak gainditu zuen fluxua hausteko. Saio-hasierak izen publikoaren bidez funtzionatu behar du, eta ukatu behar diren baliabideek ukatuta jarraitu behar dute.

Proxy alderantzizko bat argitaratzea sarbide-erabaki bereizia da, ez proxyaren beraren VPNaren hedapen gardena bere URL publikoa kargatu dezakeen edonorentzat. Biak berdinak dirudite diagrama batean, eta desberdinak dira nor sartzen den. Galdera hori hedapenaren ondoren erabakitzea da barneko aplikazio bat istripuz publiko bihurtzeko modua.

Idatzi zein bi egin zenituen eta zergatik. Konfigurazioa ukituko duen hurrengo pertsonak bestea suposatuko du. Erosotasunerako gehitutako birbideratze bakar bat nahikoa da jatorrizko akatsa birsortzeko, eta sintomak oraintxe konpondu duzunaren berdin-berdina emango du.