HAProxy 302 na ’n private app: wie open die tweede sprong?

Iemand wys ’n openbare HAProxy-gasheer na ’n plaaslike toepassing en vra waarom die blaaier nie kan volg nie. Die proxy bereik die app deur sy VPN, die herleiding stuur ’n Location-kop terug, en die blaaier probeer dan ’n adres wat net binne die tonnel bestaan. Van buite hang die bladsy bloot. Die besluit gaan oor watter party die tweede verbinding oopmaak, en dit is wat ’n herleiding van ’n backend skei.

Twee roetes wat in die konfigurasie dieselfde lyk

’n Herleiding beëindig die uitruiling met ’n antwoord. Die kliënt lees Location en begin ’n nuwe versoek van waar die kliënt ook al sit, dit is die netwerk wat jy nooit beheer het nie. Die proxy is nie meer betrokke nie. Alles wat volg hang van die kliënt se eie DNS, roete en vertroue af, so die uitkoms wissel na gelang van waar die gebruiker die blaaier oopgemaak het:

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

’n Proxy-backend hou die tweede been aan die bedienerkant. Die proxy open dit oor die pad wat hy reeds het, en die kliënt praat steeds met een openbare naam. As die tonnel val, kry die kliënt ’n fout in plaas van ’n URL wat hy nie kan volg nie. Daardie verskil is ook wat die fout diagnoseerbaar maak, want die fout verskyn waar die logboeke is:

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

Die dokumentasie oor herleidings van HAProxy trek presies hierdie lyn: om die kliënt met ’n herleiding te antwoord is ’n ander aksie as om die versoek na ’n backend aan te stuur. Die twee riglyne staan ’n paar reëls uitmekaar in ’n konfigurasielêer en gedra hulle niks dieselfde nie. Die een beëindig die versoek, die ander begin ’n tweede een wat aan die proxy behoort.

Wat die blaaier nodig het en die bediener se VPN hom nie gee nie

Die blaaier se eie versoek het vier dinge nodig wat hy miskien nie het nie: ’n DNS-antwoord vir die private naam, ’n roete na daardie adres, toestemming om die luisterende diens te bereik, en vertroue in die sertifikaat wat daardie diens voorlê. Die proxy-gasheer het al vier deur sy tonnel. Nie een daarvan dra oor na ’n kliënt wat nooit in daardie tonnel was nie, want die tonnel is ’n eienskap van die gasheer, nie van die URL nie.

Daardie gaping verduidelik die byna-werk-simptoom. Die eerste versoek slaag, die adresbalk verander, en die verbinding hang dan of misluk terwyl die proxy die hele tyd gesond is. Niks is stukkend in die proxy-konfigurasie nie, en om dit aan te pas help nie ’n kliënt wat geen pad na 10.40.0.20 het nie. Óf die kliënt kry ’n roete, óf die proxy moet die verbinding namens hom maak.

Wanneer net die proxy by die app kan uitkom

Verwyder die herleidingsaksie en stuur daardie versoeke na ’n backend wat na die private adres wys. Die frontend hou sy openbare naam terwyl die backend besluit waar die versoek werklik heen gaan. Niks aan die kliënt se pad verander nie, want die proxy hou op om ’n bestemming te beskryf en begin een wees. Vir ’n toepassing wat doelbewus op die interne poort 8080 luister, is die bedienerblok kort:

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

Lees daardie blok as ’n stelling oor die proxy se roetetabel: 10.40.0.20 moet van die proxy-gasheer self bereikbaar wees, wat hier deur die VPN-koppelvlak beteken eerder as deur die verstekroete. Die sleutelwoord check rapporteer net wat daardie roete doen, en die gesondheidspad moet op die toepassing bestaan, anders merk elke peiling die bediener as af. ’n Slaagte kontrole bewys niks oor die kliënt nie en vervang nie die beleid wat besluit wie die backend mag gebruik nie.

Die fragment is nie ’n volledige frontend nie. Hou die luisteraar, die verifikasie, die toegelate gasheer- en padkeuse, en die reël wat besluit wie die toepassing hoegenaamd mag bereik. Pas ook die backend-protokol aan, want ’n HTTPS-backend het sertifikaatverifikasie en ’n bedieneridentiteit-konfigurasie nodig, en om daardie kontrole oor te slaan maak van ’n private verbinding ’n ongeverifieerde een.

Bevestig die terugpad in beide rigtings voordat jy die oorwinning verklaar. Die toepassing sien nou ’n verbinding van die proxy, dus beskryf sy logboeke en enige kliëntadres-metadata die proxy, tensy jy anders reël. Besluit hoe identiteit en aangestuurde adresse hanteer word, en toets die besluit eerder as om dit te aanvaar.

Die app se eie herleidings wys steeds na binne

Om die eerste versoek aan te stuur is net die helfte van die integrasie. Die toepassing kan absolute herleidings, hardgekodeerde bate-URLs of koekies uitstuur wat aan die naam beperk is wat hy intern ken, en elkeen stuur die blaaier terug na ’n adres wat hy nie kan bereik nie. ’n Location-kop wat na die interne naam wys, lyk identies aan die oorspronklike probleem, en daarom word dit verkeerd gediagnoseer as ’n proxy-fout.

Stel die toepassing se gedokumenteerde eksterne URL en sy proxy-opsies, en laat die Host-kop dan ooreenstem met die virtuele gasheer en die sertifikaatverwagtinge. ’n Koekie wat aan die interne naam beperk is, sal nie deur die openbare naam terugkom nie, en die aanmeldingslus wat volg lees soos ’n verifikasiefout. Verander eers die eksterne URL, toets weer uit ’n skoon blaaierprofiel, en verwag dat half-gemigreerde instellings ’n aanmelding lewer wat slaag en ’n sessie wat onmiddellik sterf.

Vertrou aangestuurde metadata net van die aangewese proxy. ’n Kop wat enige kliënt kan stel, mag nooit ’n magtigingswaarde word nie, anders word die proxy ’n manier vir ’n oproeper om iemand anders se identiteit op te eis. Daardie reël is onafhanklik van die herleidingsvraag en oorleef elke latere herontwerp.

Besluit watter ontwerp jy werklik het

As elke gebruiker reeds gemagtigde VPN-toegang het, kan ’n herleiding na ’n private URL ’n doelbewuste ontwerp wees. Bevestig daardie vereiste uitdruklik eerder as om dit te aanvaar, want die twee ontwerpe dien heeltemal verskillende bevolkings. Een van hulle werk glad nie uit ’n hotelnetwerk nie, en die ander stel die toepassing bloot aan elkeen wat die openbare URL kan laai. Daardie onderskeid hoort in die ontwerpnota.

Voer die kontrole uit vanaf ’n masjien op die gebruikers se netwerk en volg elke sprong wat die blaaier maak, nie net die eerste antwoord nie. Hou die adresbalk en elke volgende versoek dop, want ’n enkele absolute URL in ’n bate-etiket is genoeg om ’n vloei te breek wat die eerste sprong geslaag het. Aanmelding moet deur die openbare naam werk, en hulpbronne wat geweier moet word, moet geweier bly.

Om ’n omgekeerde proxy te publiseer is ’n aparte toegangsbesluit, nie ’n deursigtige uitbreiding van die proxy se eie VPN na elkeen wat sy openbare URL kan laai nie. Die twee lyk dieselfde op ’n diagram, en hulle verskil in wie toegelaat word. Om daardie vraag ná die ontplooiing te besluit, is hoe ’n interne toepassing per ongeluk ’n openbare een word.

Skryf neer watter een jy gebou het en waarom. Die volgende persoon wat die konfigurasie aanraak, sal die ander een aanneem. ’n Enkele herleiding wat vir gerief bygevoeg is, is genoeg om die oorspronklike fout te herskep, en die simptoom sal presies soos die een lyk wat jy pas reggemaak het.