HAProxy 302 patungo sa pribadong app: sino ang nagbubukas ng ikalawang hakbang?

May nagtutok ng pampublikong host ng HAProxy sa isang on-premises na application at nagtatanong kung bakit hindi ito masundan ng browser. Naabot ng proxy ang app sa pamamagitan ng VPN nito, nagbabalik ang redirect ng Location header, at pagkatapos ay sinusubukan ng browser ang isang address na umiiral lamang sa loob ng tunnel. Mula sa labas, nakabitin lang ang pahina. Ang desisyon ay tungkol sa kung aling panig ang nagbubukas ng ikalawang koneksyon, at iyon ang naghihiwalay ng redirect sa backend.

Dalawang landas na magkamukha sa configuration

Tinatapos ng redirect ang palitan sa isang tugon. Binabasa ng kliyente ang Location at nagsisimula ng bagong kahilingan mula sa kung saan man ito naroroon, na siyang network na hindi mo kailanman kinontrol. Wala nang kinalaman ang proxy. Ang lahat ng sumusunod ay nakasalalay sa sariling DNS, ruta at tiwala ng kliyente, kaya nag-iiba ang resulta depende sa kung saan binuksan ng user ang browser:

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

Pinapanatili ng backend ng proxy ang ikalawang hakbang sa panig ng server. Binubuksan ito ng proxy sa landas na mayroon na ito, at patuloy na nakikipag-usap ang kliyente sa isang pampublikong pangalan. Kung bumagsak ang tunnel, nakakatanggap ang kliyente ng error sa halip na URL na hindi nito masundan. Ang pagkakaibang iyon din ang nagpapaging-diagnosable ng pagkasira, dahil lumilitaw ang error kung saan naroon ang mga log:

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

Ang dokumentasyon ng HAProxy sa redirect ay gumuhit ng eksaktong linyang ito: ang pagsagot sa kliyente ng redirect ay ibang aksyon kaysa sa pagpapasa ng kahilingan sa backend. Ang dalawang direktiba ay magkalayo ng ilang linya sa isang configuration file at kumikilos nang lubos na magkaiba. Tinatapos ng isa ang kahilingan, at nagsisimula ang isa ng ikalawa na pagmamay-ari ng proxy.

Ano ang kailangan ng browser na hindi ibinibigay ng VPN ng server

Ang sariling kahilingan ng browser ay nangangailangan ng apat na bagay na maaaring wala ito: sagot ng DNS para sa pribadong pangalan, ruta patungo sa address na iyon, pahintulot na maabot ang serbisyong nakikinig, at tiwala sa anumang certificate na inihaharap ng serbisyong iyon. Ang host ng proxy ay may taglay ng apat sa pamamagitan ng tunnel nito. Wala sa mga ito ang naipapasa sa kliyenteng hindi kailanman napunta sa tunnel na iyon, dahil ang tunnel ay katangian ng host, hindi ng URL.

Ipinapaliwanag ng agwat na iyon ang sintomas na halos gumagana. Nagtatagumpay ang unang kahilingan, nagbabago ang address bar, at pagkatapos ay nakabitin o nabigo ang koneksyon habang malusog ang proxy sa buong oras. Walang sira sa configuration ng proxy, at ang pagsasaayos nito ay hindi makakatulong sa kliyenteng walang ruta patungo sa 10.40.0.20. Alinman sa makakuha ng ruta ang kliyente, o kailangang gawin ng proxy ang koneksyon sa ngalan nito.

Kapag ang proxy lang ang makakaabot sa app

Alisin ang aksyon ng redirect at ipadala ang mga kahilingang iyon sa isang backend na nakatutok sa pribadong address. Pinapanatili ng frontend ang pampublikong pangalan nito habang nagpapasya ang backend kung saan talaga napupunta ang kahilingan. Wala nang nagbabago sa landas ng kliyente, dahil tumitigil nang ilarawan ng proxy ang isang destinasyon at nagiging destinasyon mismo. Para sa isang application na sadyang nakikinig sa panloob na port 8080, maikli ang block ng server:

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

Basahin ang block na iyon bilang pahayag tungkol sa routing table ng proxy: ang 10.40.0.20 ay dapat maabot mula sa host ng proxy mismo, na dito ay nangangahulugang sa pamamagitan ng interface ng VPN at hindi ng default na ruta. Ang keyword na check ay nag-uulat lamang kung ano ang ginagawa ng rutang iyon, at ang health path ay dapat umiral sa application, kung hindi ay minamarkahan ng bawat probe ang server bilang down. Ang isang pasadong check ay walang pinapatunayan tungkol sa kliyente at hindi pumapalit sa patakaran na nagtatakda kung sino ang maaaring gumamit ng backend.

Ang fragment na ito ay hindi kumpletong frontend. Panatilihin ang listener, ang authentication, ang pinapayagang host at pagpili ng path, at ang patakarang nagtatakda kung sino talaga ang makakaabot sa application. Itugma rin ang protocol ng backend, dahil ang backend na HTTPS ay nangangailangan ng verification ng certificate at configuration ng identity ng server, at ang paglaktaw sa check na iyon ay gumagawa ng pribadong koneksyon na hindi beripikado.

Kumpirmahin ang return path sa dalawang direksyon bago magpahayag ng tagumpay. Ngayon ay nakikita ng application ang koneksyon mula sa proxy, kaya ang mga log nito at anumang metadata ng address ng kliyente ay naglalarawan sa proxy maliban kung iba ang ayusin mo. Magpasya kung paano pinangangasiwaan ang identity at ang mga forwarded address, at subukan ang desisyong iyon sa halip na ipagpalagay ito.

Ang sariling redirect ng app ay nakatutok pa rin sa loob

Ang pagpapasa ng unang kahilingan ay kalahati lamang ng integrasyon. Maaaring maglabas ang application ng absolute redirect, hard-coded na asset URL, o cookie na naka-scope sa pangalang kilala nito sa loob, at bawat isa sa mga iyon ay nagpapabalik sa browser sa isang address na hindi nito maabot. Ang Location header na nakatutok sa panloob na pangalan ay mukhang kapareho ng orihinal na problema, kaya mali itong na-diagnose bilang pagkasira ng proxy.

Itakda ang dokumentadong external URL ng application at ang mga opsyon nito sa proxy, pagkatapos ay gawing tugma ang Host header sa virtual host at sa mga inaasahan ng certificate. Ang cookie na naka-scope sa panloob na pangalan ay hindi babalik sa pampublikong pangalan, at ang sign-in loop na sumusunod ay binabasa bilang bug sa authentication. Palitan muna ang external URL, muling subukan mula sa malinis na profile ng browser, at asahan na ang kalahating nailipat na setting ay magbubunga ng login na nagtatagumpay at session na agad namamatay.

Magtiwala sa forwarded metadata mula lamang sa itinalagang proxy. Ang header na maaaring itakda ng kahit anong kliyente ay hindi dapat kailanman maging halaga ng authorization, kung hindi ay nagiging paraan ang proxy para ang isang tumatawag ay mag-angkin ng pagkakakilanlan ng iba. Ang patakarang iyon ay independiyente sa tanong ng redirect at nananatili sa bawat susunod na redesign.

Magpasya kung aling disenyo talaga ang mayroon ka

Kung ang lahat ng user ay may awtorisadong VPN access na, ang redirect sa isang pribadong URL ay maaaring sinadyang disenyo. Kumpirmahin ang pangangailangang iyon nang tahasan sa halip na ipagpalagay ito, dahil ang dalawang disenyo ay naglilingkod sa lubos na magkaibang populasyon. Ang isa sa kanila ay hindi gumagana sa isang hotel network, at ang isa ay naglalantad sa application sa sinumang makakapag-load ng pampublikong URL. Ang pagkakaibang iyon ay dapat nasa design note.

Patakbuhin ang check mula sa isang makina sa network ng mga user at sundan ang bawat hakbang na ginagawa ng browser, hindi lamang ang unang tugon. Bantayan ang address bar at ang bawat kasunod na kahilingan, dahil ang isang absolute URL sa isang asset tag ay sapat na para masira ang isang flow na naipasa ng unang hakbang. Dapat gumana ang sign-in sa pamamagitan ng pampublikong pangalan, at ang mga resource na dapat tanggihan ay dapat manatiling tinanggihan.

Ang paglalathala ng reverse proxy ay hiwalay na desisyon sa access, hindi transparent na pagpapalawig ng sariling VPN ng proxy sa sinumang makakapag-load ng pampublikong URL nito. Magkamukha ang dalawa sa isang diagram, at nagkakaiba sila sa kung sino ang pinapayagang pumasok. Ang pagpapasya sa tanong na iyon pagkatapos ng deployment ay kung paano nagiging pampubliko ang isang panloob na application nang hindi sinasadya.

Isulat kung alin ang itinayo mo at bakit. Ipagpapalagay ng susunod na taong hahawak sa configuration ang isa pa. Ang isang redirect na idinagdag para sa kaginhawahan ay sapat na upang muling likhain ang orihinal na pagkasira, at ang sintomas ay magmumukhang eksaktong katulad ng kakalutas mo lang.