HAProxy 302 al privata aplikaĵo: kiu malfermas la duan salton?

Alidirektilo redonas la duan konekton al la retumilo. Sendu la peton al backend anstataŭe, poste riparu la proprajn absolutajn alidirektilojn kaj kuketojn de la aplikaĵo.

Iu direktas publikan HAProxy-gastiganton al ena aplikaĵo kaj demandas, kial la retumilo ne povas sekvi. La prokurilo atingas la aplikaĵon per sia VPN, la alidirektilo redonas Location-kapon, kaj la retumilo tiam provas adreson kiu ekzistas nur ene de la tunelo. De ekstere la paĝo simple blokiĝas. La decido temas pri tio, kiu flanko malfermas la duan konekton, kaj ĝuste tio distingas alidirektilon de backend.

Du vojoj kiuj aspektas similaj en la agordo

Alidirektilo finas la interŝanĝon per respondo. La kliento legas Location kaj komencas novan peton de kie ajn ĝi troviĝas, do de la reto kiun vi neniam kontrolis. La prokurilo jam ne partoprenas. Ĉio sekva dependas de la propra DNS, vojo kaj fido de la kliento, do la rezulto varias laŭ tio, kie la uzanto malfermis la retumilon:

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 de la prokurilo tenas la duan etapon ĉe la servila flanko. La prokurilo malfermas ĝin laŭ la vojo kiun ĝi jam havas, kaj la kliento daŭre parolas al unu publika nomo. Se la tunelo falas, la kliento ricevas eraron anstataŭ URL-on kiun ĝi ne povas sekvi. Tiu diferenco ankaŭ estas kio faras la fiaskon diagnozebla, ĉar la eraro aperas tie, kie estas la protokoloj:

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

La dokumentaro pri alidirektado de HAProxy desegnas ĝuste tiun linion: respondi al la kliento per alidirektilo estas alia ago ol plusendi la peton al backend. La du direktivoj staras kelkajn liniojn dise en agorda dosiero kaj kondutas tute malsame. Unu finas la peton, la alia komencas duan, kiun posedas la prokurilo.

Kion la retumilo bezonas kaj kion la VPN de la servilo ne donas al ĝi

La propra peto de la retumilo bezonas kvar aferojn, kiujn ĝi eble ne havas: DNS-respondon por la privata nomo, vojon al tiu adreso, permeson atingi la aŭskultantan servon, kaj fidon al la atestilo kiun tiu servo prezentas. La gastiganto de la prokurilo posedas ĉiujn kvar per sia tunelo. Neniu el ili transdoniĝas al kliento kiu neniam estis en tiu tunelo, ĉar la tunelo estas eco de la gastiganto, ne de la URL.

Tiu breĉo klarigas la simptomon preskaŭ-funkcias. La unua peto sukcesas, la adresa breto ŝanĝiĝas, kaj poste la konekto blokiĝas aŭ fiaskas dum la prokurilo estas sana la tutan tempon. Nenio rompiĝis en la agordo de la prokurilo, kaj ĝin ĝustigi ne helpas klienton kiu havas neniun vojon al 10.40.0.20. Aŭ la kliento ricevas vojon, aŭ la prokurilo devas fari la konekton anstataŭ ĝi.

Kiam nur la prokurilo povas atingi la aplikaĵon

Forigu la alidirektan agon kaj sendu tiujn petojn al backend kiu montras al la privata adreso. La frontend retenas sian publikan nomon dum la backend decidas kien la peto vere iras. Nenio ŝanĝiĝas en la vojo de la kliento, ĉar la prokurilo ĉesas priskribi celon kaj komencas esti ĝi. Por aplikaĵo kiu intence aŭskultas sur la ena pordo 8080, la servila bloko estas mallonga:

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

Legu tiun blokon kiel aserton pri la enkursiga tabelo de la prokurilo: 10.40.0.20 devas esti atingebla de la gastiganto de la prokurilo mem, kio ĉi tie signifas per la VPN-interfaco anstataŭ per la implicita vojo. La ŝlosilvorto check nur raportas kion tiu vojo faras, kaj la san-vojo devas ekzisti en la aplikaĵo, alie ĉiu provo markas la servilon kiel nefunkcianta. Sukcesa kontrolo pruvas nenion pri la kliento kaj ne anstataŭas la politikon kiu decidas kiu rajtas uzi la backend.

La fragmento ne estas kompleta frontend. Konservu la aŭskultanton, la aŭtentigon, la elekton de permesata gastiganto kaj vojo, kaj la regulon kiu decidas kiu entute rajtas atingi la aplikaĵon. Kongruigu ankaŭ la backend-protokolon, ĉar HTTPS-backend bezonas atestilan kontrolon kaj servilan identec-agordon, kaj preterlasi tiun kontrolon igas privatan konekton nekontrolita.

Konfirmu la revenan vojon en ambaŭ direktoj antaŭ ol deklari venkon. La aplikaĵo nun vidas konekton de la prokurilo, do ĝiaj protokoloj kaj ajna klientadresa metadateno priskribas la prokurilon, krom se vi aranĝos alie. Decidu kiel identeco kaj plusenditaj adresoj estas traktataj, kaj testu la decidon anstataŭ supozi ĝin.

La propraj alidirektiloj de la aplikaĵo ankoraŭ montras internen

Plusendi la unuan peton estas nur duono de la integriĝo. La aplikaĵo povas elsendi absolutajn alidirektilojn, malmole koditajn risursajn URL-ojn aŭ kuketojn limigitajn al la nomo kiun ĝi konas interne, kaj ĉiu el tiuj resendas la retumilon al adreso kiun ĝi ne povas atingi. Location-kapo montranta al la ena nomo aspektas idente al la origina problemo, kaj tial ĝi estas misdiagnozita kiel prokurila fiasko.

Agordu la dokumentitan eksteran URL-on de la aplikaĵo kaj ĝiajn prokurajn opciojn, poste kongruigu la Host-kapon kun la virtuala gastiganto kaj la atestilaj atendoj. Kuketo limigita al la ena nomo ne revenos tra la publika nomo, kaj la anonca buklo kiu sekvas legiĝas kiel aŭtentiga cimo. Ŝanĝu unue la eksteran URL-on, retestu el pura retumila profilo, kaj atendu ke duonmigritaj agordoj produktos ensaluton kiu sukcesas kaj sesion kiu mortas tuj.

Fidu plusenditajn metadatenojn nur de la elektita prokurilo. Kapo kiun ajna kliento povas agordi neniam rajtas fariĝi aŭtoriga valoro, alie la prokurilo fariĝas maniero por alvokanto postuli alies identecon. Tiu regulo estas sendependa de la alidirekta demando kaj postvivas ĉiun postan redistajnon.

Decidu kiun dezajnon vi vere havas

Se ĉiu uzanto jam havas rajtigitan VPN-aliron, alidirektilo al privata URL povas esti intenca dezajno. Konfirmu tiun postulon eksplicite anstataŭ supozi ĝin, ĉar la du dezajnoj servas tute malsamajn populaciojn. Unu el ili tute ne funkcias el hotela reto, kaj la alia elmetas la aplikaĵon al ĉiu kiu povas ŝargi la publikan URL-on. Tiu distingo apartenas al la dezajna noto.

Rulu la kontrolon el maŝino en la reto de la uzantoj kaj sekvu ĉiun salton kiun la retumilo faras, ne nur la unuan respondon. Observu la adresan breton kaj ĉiun sekvan peton, ĉar unu absoluta URL en risursigno sufiĉas por rompi fluon kiun la unua salto trapasis. Ensaluto devas funkcii tra la publika nomo, kaj rimedoj kiuj devas esti rifuzitaj devas resti rifuzitaj.

Publiki inversan prokurilon estas aparta alira decido, ne travidebla etendo de la propra VPN de la prokurilo al ĉiu kiu povas ŝargi ĝian publikan URL-on. La du aspektas same sur diagramo, kaj ili diferencas en kiu rajtas eniri. Decidi tiun demandon post la deplojo estas kiel ena aplikaĵo hazarde fariĝas publika.

Skribu kiun el la du vi konstruis kaj kial. La sekva persono kiu tuŝos la agordon supozos la alian. Unu sola alidirektilo aldonita por oportuneco sufiĉas por rekrei la originan fiaskon, kaj la simptomo aspektos ĝuste kiel tiu kiun vi ĵus riparis.

Rilataj artikoloj