HAProxy 302 į privatų sprendimą: kas atidaro antrą šuolį?

Kažkas nukreipia viešą HAProxy host'ą į vidinę programą ir klausia, kodėl naršyklė negali sekti. Tarpinis serveris pasiekia programą per savo VPN, peradresavimas grąžina Location antraštę, o naršyklė tada bando adresą, kuris egzistuoja tik tunelio viduje. Iš išorės puslapis tiesiog užstringa. Sprendimas yra apie tai, kuri pusė atidaro antrą ryšį, ir būtent tai skiria peradresavimą nuo backendo.

Du keliai, kurie konfigūracijoje atrodo panašiai

Peradresavimas baigia mainus atsakymu. Klientas perskaito Location ir pradeda naują užklausą iš ten, kur yra, tai yra iš tinklo, kurio niekada nekontroliavote. Tarpinis serveris nebedalyvauja. Viskas, kas toliau, priklauso nuo paties kliento DNS, maršruto ir pasitikėjimo, todėl rezultatas skiriasi priklausomai nuo to, kur vartotojas atidarė naršyklę:

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

Tarpinio serverio backendas laiko antrą etapą serverio pusėje. Tarpinis serveris atidaro jį keliu, kurį jau turi, o klientas toliau kalba su vienu viešu vardu. Jei tunelis krinta, klientas gauna klaidą vietoj URL, kurio negali sekti. Būtent šis skirtumas daro gedimą diagnozuojamą, nes klaida pasirodo ten, kur yra žurnalai:

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

HAProxy peradresavimų dokumentacija brėžia būtent šią liniją: atsakyti klientui peradresavimu yra kitas veiksmas nei perduoti užklausą backendui. Dvi direktyvos konfigūracijos faile yra kelių eilučių atstumu ir elgiasi visiškai skirtingai. Viena baigia užklausą, kita pradeda antrą, kuri priklauso tarpiniam serveriui.

Ko naršyklei reikia ir ko serverio VPN jai neduoda

Pačios naršyklės užklausai reikia keturių dalykų, kurių ji gali neturėti: DNS atsakymo privačiam vardui, maršruto į tą adresą, leidimo pasiekti klausančią paslaugą ir pasitikėjimo sertifikatu, kurį ta paslauga pateikia. Tarpinio serverio host'as visus keturis turi per savo tunelį. Nė vienas jų neperduodamas klientui, kuris niekada nebuvo tame tune, nes tunelis yra host'o savybė, o ne URL.

Šis tarpas paaiškina simptomą beveik-veikia. Pirmoji užklausa pavyksta, adreso juosta pasikeičia, o tada ryšys užstringa arba nepavyksta, nors tarpinis serveris visą laiką sveikas. Tarpinio serverio konfigūracijoje niekas nesugedę, o jos derinimas nepadeda klientui, kuris neturi kelio į 10.40.0.20. Arba klientas gauna maršrutą, arba tarpinis serveris turi užmegzti ryšį jo vardu.

Kai tik tarpinis serveris pasiekia programą

Pašalinkite peradresavimo veiksmą ir siųskite tas užklausas backendui, kuris nukreiptas į privatų adresą. Frontend'as išlaiko savo viešą vardą, o backendas nusprendžia, kur užklausa iš tikrųjų eina. Kliento kelyje niekas nesikeičia, nes tarpinis serveris nustoja aprašyti tikslą ir pradeda juo būti. Programai, kuri sąmoningai klausosi vidinio 8080 prievado, serverio blokas trumpas:

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

Skaitykite šį bloką kaip teiginį apie tarpinio serverio maršrutų lentelę: 10.40.0.20 turi būti pasiekiamas iš paties tarpinio serverio host'o, o tai čia reiškia per VPN sąsają, o ne per numatytąjį maršrutą. Raktinis žodis check tik praneša, ką daro tas maršrutas, o sveikatos kelias turi egzistuoti programoje, kitaip kiekviena patikra pažymi serverį kaip išjungtą. Sėkminga patikra nieko neįrodo apie klientą ir nepakeičia politikos, kuri nusprendžia, kas gali naudotis backendu.

Fragmentas nėra visas frontend'as. Išsaugokite klausytoją, autentifikaciją, leidžiamo host'o ir kelio pasirinkimą bei taisyklę, kuri nusprendžia, kas apskritai gali pasiekti programą. Suderinkite ir backendo protokolą, nes HTTPS backendui reikia sertifikato patikros ir serverio tapatybės konfigūracijos, o tos patikros praleidimas privačią jungtį paverčia nepatikrinta.

Patvirtinkite grįžimo kelią abiem kryptimis prieš skelbdami pergalę. Programa dabar mato ryšį iš tarpinio serverio, todėl jos žurnalai ir bet kokie kliento adreso metaduomenys aprašo tarpinį serverį, nebent sutvarkysite kitaip. Nuspręskite, kaip tvarkoma tapatybė ir persiųsti adresai, ir išbandykite sprendimą, o ne darykite prielaidą.

Pačios programos peradresavimai vis dar nukreipti į vidų

Pirmosios užklausos persiuntimas tėra pusė integracijos. Programa gali siųsti absoliučius peradresavimus, kietai užkoduotus išteklių URL arba slapukus, apribotus viduje žinomu vardu, ir kiekvienas jų grąžina naršyklę į adresą, kurio ji negali pasiekti. Location antraštė, nukreipta į vidinį vardą, atrodo identiškai kaip pradinė problema, todėl ji klaidingai diagnozuojama kaip tarpinio serverio gedimas.

Nustatykite dokumentuotą išorinį programos URL ir jos tarpinio serverio parinktis, tada suderinkite Host antraštę su virtualiu host'u ir sertifikato lūkesčiais. Slapukas, apribotas vidiniu vardu, negrįš per viešą vardą, o po jo einantis prisijungimo ciklas skaitomas kaip autentifikacijos klaida. Pirmiausia pakeiskite išorinį URL, išbandykite iš švaraus naršyklės profilio ir tikėkitės, kad pusiau perkelti nustatymai duos sėkmingą prisijungimą ir iš karto mirštančią sesiją.

Pasitikėkite persiųstais metaduomenimis tik iš paskirto tarpinio serverio. Antraštė, kurią gali nustatyti bet kuris klientas, niekada neturi tapti autorizacijos reikšme, kitaip tarpinis serveris tampa būdu skambinančiajam pasisavinti kito tapatybę. Ši taisyklė nepriklauso nuo peradresavimo klausimo ir išgyvena bet kokį vėlesnį pertvarkymą.

Nuspręskite, kokį dizainą iš tikrųjų turite

Jei kiekvienas vartotojas jau turi autorizuotą VPN prieigą, peradresavimas į privatų URL gali būti sąmoningas dizainas. Patvirtinkite šį reikalavimą aiškiai, o ne darykite prielaidą, nes du dizainai aptarnauja visiškai skirtingas grupes. Vienas jų iš viešbučio tinklo visai neveikia, o kitas atveria programą visiems, kurie gali įkelti viešą URL. Šis skirtumas priklauso dizaino pastabai.

Vykdykite patikrą iš mašinos vartotojų tinkle ir sekite kiekvieną naršyklės šuolį, ne tik pirmą atsakymą. Stebėkite adreso juostą ir kiekvieną tolesnę užklausą, nes vienas absoliutus URL ištekliaus žymoje pakanka sugadinti srautą, kurį pirmasis šuolis praėjo. Prisijungimas turi veikti per viešą vardą, o ištekliai, kuriuos reikia atmesti, turi likti atmesti.

Atvirkštinio tarpinio serverio publikavimas yra atskiras prieigos sprendimas, o ne skaidrus tarpinio serverio VPN išplėtimas visiems, kurie gali įkelti jo viešą URL. Abu diagramoje atrodo panašiai ir skiriasi tuo, kam leidžiama įeiti. To klausimo sprendimas po diegimo yra kelias, kuriuo vidinė programa atsitiktinai tampa vieša.

Užrašykite, kurį iš dviejų sukūrėte ir kodėl. Kitas žmogus, kuris palies konfigūraciją, darys prielaidą apie kitą. Vieno peradresavimo, pridėto dėl patogumo, pakanka atkurti pradinį gedimą, o simptomas atrodys lygiai taip pat, kaip ką tik ištaisytas.