HAProxy 302 na zasebno aplikacijo: kdo odpre drugi skok?

Nekdo usmeri javni gostitelj HAProxy na lokalno aplikacijo in vpraša, zakaj brskalnik ne more slediti. Posrednik doseže aplikacijo prek svojega VPN, preusmeritev vrne glavo Location, brskalnik pa nato poskusi naslov, ki obstaja samo znotraj tunela. Od zunaj se stran preprosto ustavi. Odločitev je o tem, katera stran odpre drugo povezavo, in prav to loči preusmeritev od zaledja.

Dve poti, ki sta si v konfiguraciji podobni

Preusmeritev konča izmenjavo z odgovorom. Odjemalec prebere Location in začne novo zahtevo od tam, kjer sedi, torej iz omrežja, ki ga nikoli niste nadzorovali. Posrednik ni več vključen. Vse nadaljnje je odvisno od odjemalčevih DNS, poti in zaupanja, zato se izid razlikuje glede na to, kje je uporabnik odprl brskalnik:

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

Zaledje posrednika obdrži drugi krak na strežniški strani. Posrednik ga odpre po poti, ki jo že ima, odjemalec pa se pogovarja z enim javnim imenom. Če tunel pade, odjemalec prejme napako namesto URL-ja, ki mu ne more slediti. Ta razlika je tudi tisto, kar naredi okvaro diagnostično, ker se napaka pojavi tam, kjer so dnevniki:

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

Dokumentacija HAProxy o preusmeritvah potegne natanko to mejo: odgovoriti odjemalcu s preusmeritvijo je drugačno dejanje kot posredovati zahtevo v zaledje. Obe direktivi stojita v konfiguracijski datoteki nekaj vrstic narazen in se obnašata povsem različno. Ena konča zahtevo, druga pa začne drugo, ki jo ima v lasti posrednik.

Kaj brskalnik potrebuje in česar mu VPN strežnika ne da

Lastna zahteva brskalnika potrebuje štiri stvari, ki jih morda nima: odgovor DNS za zasebno ime, pot do tega naslova, dovoljenje za dostop do službe, ki posluša, in zaupanje v potrdilo, ki ga ta služba predstavi. Gostitelj posrednika ima vse štiri po zaslugi svojega tunela. Nobena od njih se ne prenese na odjemalca, ki ni bil nikoli v tem tunelu, ker je tunel lastnost gostitelja, ne URL-ja.

Ta vrzel pojasnjuje simptom »skoraj deluje«. Prva zahteva uspe, naslovna vrstica se spremeni, povezava pa nato obvisi ali odpove, čeprav je posrednik ves čas zdrav. V konfiguraciji posrednika ni nič pokvarjeno in njeno prilagajanje ne more pomagati odjemalcu, ki nima poti do 10.40.0.20. Odjemalec bodisi dobi pot bodisi mora posrednik vzpostaviti povezavo namesto njega.

Ko lahko do aplikacije pride le posrednik

Odstranite dejanje preusmeritve in te zahteve pošljite v zaledje, ki kaže na zasebni naslov. Sprednji del obdrži javno ime, medtem ko zaledje odloči, kam zahteva zares gre. Na odjemalčevi poti se nič ne spremeni, ker posrednik preneha opisovati cilj in sam postane cilj. Za aplikacijo, ki namenoma posluša na notranjih vratih 8080, je blok strežnika kratek:

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

Ta blok berite kot trditev o usmerjevalni tabeli posrednika: naslov 10.40.0.20 mora biti dosegljiv s samega gostitelja posrednika, kar tu pomeni prek vmesnika VPN in ne prek privzete poti. Ključna beseda check le poroča, kaj ta pot počne, pot za preverjanje zdravja pa mora obstajati v aplikaciji, sicer vsaka sonda označi strežnik kot nedosegljiv. Uspešno preverjanje ne dokaže ničesar o odjemalcu in ne nadomesti pravilnika, ki odloča, kdo sme uporabljati zaledje.

Ta odlomek ni popoln sprednji del. Obdržite sprejemnik zahtev, avtentikacijo, izbiro dovoljenega gostitelja in poti ter pravilo, ki odloča, kdo se sploh lahko dotakne aplikacije. Uskladite tudi protokol zaledja, ker zaledje HTTPS potrebuje preverjanje potrdila in nastavitev identitete strežnika, izpuščanje tega preverjanja pa spremeni zasebno povezavo v nepreverjeno.

Preden razglasite zmago, potrdite povratno pot v obeh smereh. Aplikacija zdaj vidi povezavo od posrednika, zato njeni dnevniki in morebitni metapodatki o naslovu odjemalca opisujejo posrednika, razen če poskrbite drugače. Odločite se, kako se obravnavata identiteta in posredovani naslovi, in to odločitev preizkusite, namesto da bi jo predpostavljali.

Lastne preusmeritve aplikacije še vedno kažejo navznoter

Posredovanje prve zahteve je le polovica integracije. Aplikacija lahko oddaja absolutne preusmeritve, trdo zakodirane URL-je virov ali piškotke, vezane na ime, ki ga pozna od znotraj, in vsak od teh pošlje brskalnik nazaj na naslov, do katerega ne more priti. Glava Location, ki kaže na notranje ime, je videti enako kot prvotna težava, zato se napačno diagnosticira kot okvara posrednika.

Nastavite dokumentirani zunanji URL aplikacije in njene možnosti posrednika, nato uskladite glavo Host z navideznim gostiteljem in pričakovanji potrdila. Piškotek, vezan na notranje ime, se ne bo vrnil prek javnega imena, cikel prijave, ki sledi, pa se bere kot napaka avtentikacije. Najprej spremenite zunanji URL, znova preizkusite iz čistega profila brskalnika in pričakujte, da bodo napol preseljene nastavitve dale prijavo, ki uspe, in sejo, ki takoj umre.

Posredovanim metapodatkom zaupajte le od določenega posrednika. Glava, ki jo lahko nastavi vsak odjemalec, nikoli ne sme postati vrednost avtorizacije, sicer se posrednik spremeni v način, da si klicatelj prilasti identiteto nekoga drugega. To pravilo ni odvisno od vprašanja preusmeritve in preživi vsako poznejšo prenovo.

Odločite, katero zasnovo pravzaprav imate

Če imajo vsi uporabniki že pooblaščen dostop prek VPN, je preusmeritev na zasebni URL lahko namerna zasnova. To zahtevo potrdite izrecno, namesto da bi jo predpostavljali, ker ti dve zasnovi služita povsem različnima skupinama. Ena od njiju iz hotelskega omrežja sploh ne deluje, druga pa izpostavi aplikacijo vsakomur, ki lahko naloži javni URL. Ta razlika spada v projektno opombo.

Preverjanje zaženite s stroja v uporabniškem omrežju in sledite vsakemu skoku, ki ga brskalnik naredi, ne le prvemu odgovoru. Bodite pozorni na naslovno vrstico in na vsako naslednjo zahtevo, ker en sam absolutni URL v oznaki vira zadošča, da zlomi tok, ki je prvi skok prestal. Prijava mora delovati prek javnega imena, viri, ki bi morali biti zavrnjeni, pa morajo ostati zavrnjeni.

Objavljanje obratnega posrednika je ločena odločitev o dostopu, ne pa pregledna razširitev lastnega VPN posrednika na vsakogar, ki lahko naloži njegov javni URL. Na diagramu sta si enaka, razlikujeta pa se po tem, komu je dovoljen vstop. Odločati o tem vprašanju po uvedbi je način, da notranja aplikacija po nesreči postane javna.

Zapišite, katero od obeh ste zgradili in zakaj. Naslednji človek, ki se bo dotaknil konfiguracije, bo predpostavljal drugo. Ena sama preusmeritev, dodana za udobje, zadošča, da poustvari prvotno okvaro, simptom pa bo videti natanko tak kot tisti, ki ste ga pravkar popravili.