HAProxy 302 til ein privat app: kven opnar det andre hoppet?

Nokon peikar ein offentleg HAProxy-vert mot ein intern applikasjon og spør kvifor nettlesaren ikkje kan følgje etter. Proxyen når appen gjennom VPN-en sin, omdirigeringa returnerer ein Location-header, og nettlesaren prøver deretter ei adresse som berre finst inne i tunnelen. Utanfrå heng sida rett og slett. Avgjerda handlar om kva part som opnar den andre tilkoplinga, og det er nettopp det som skil ei omdirigering frå ein backend.

To vegar som ser like ut i konfigurasjonen

Ei omdirigering avsluttar utvekslinga med eit svar. Klienten les Location og startar ein ny førespurnad frå der han er, altså nettverket du aldri kontrollerte. Proxyen er ikkje lenger involvert. Alt som følgjer avheng av klienten sin eigen DNS, rute og tillit, så resultatet varierer etter kvar brukaren opna nettlesaren:

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

Ein proxy-backend held det andre beinet på serversida. Proxyen opnar det over vegen han allereie har, og klienten held fram med å snakke med eitt offentleg namn. Fell tunnelen, får klienten ein feil i staden for ein URL han ikkje kan følgje. Den skilnaden er også det som gjer feilen diagnostiserbar, fordi feilen dukkar opp der loggane er:

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

HAProxy sin dokumentasjon om omdirigeringar dreg nettopp denne grensa: å svare klienten med ei omdirigering er ei anna handling enn å videresende førespurnaden til ein backend. Dei to direktiva står nokre linjer frå kvarandre i ein konfigurasjonsfil og oppfører seg heilt ulikt. Den eine avsluttar førespurnaden, den andre byrjar ein til som proxyen eig.

Kva nettlesaren treng og serveren sin VPN ikkje gir han

Førespurnaden til nettlesaren sjølv treng fire ting han kanskje ikkje har: eit DNS-svar for det private namnet, ei rute til adressa, løyve til å nå tenesta som lyttar, og tillit til sertifikatet den tenesta legg fram. Proxyverten har alle fire gjennom tunnelen sin. Ingen av dei blir overførte til ein klient som aldri var i den tunnelen, fordi tunnelen er ein eigenskap ved verten, ikkje ved URL-en.

Dette gapet forklarer nesten-fungerer-symtomet. Den første førespurnaden lukkast, adresselinja endrar seg, og deretter heng eller feilar tilkoplinga medan proxyen er sunn heile tida. Ingenting er øydelagt i proxykonfigurasjonen, og å justere han hjelper ikkje ein klient utan rute til 10.40.0.20. Anten får klienten ei rute, eller proxyen må gjere tilkoplinga på hans vegner.

Når berre proxyen kan nå appen

Fjern omdirigeringshandlinga og send dei førespurnadene til ein backend som peikar på den private adressa. Frontend held på det offentlege namnet sitt medan backend avgjer kvar førespurnaden faktisk går. Ingenting endrar seg i vegen til klienten, fordi proxyen sluttar å skildre ein destinasjon og byrjar å vere ein. For ein applikasjon som med vilje lyttar på den interne porten 8080, er serverblokka kort:

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

Les den blokka som eit påstand om rutetabellen til proxyen: 10.40.0.20 må vere tilgjengeleg frå sjølve proxyverten, som her tyder gjennom VPN-grensesnittet og ikkje gjennom standardruta. Nøkkelordet check rapporterer berre kva den ruta gjer, og helsevegen må finnast på applikasjonen, elles merkjer kvar sjekk serveren som nede. Ein bestått sjekk beviser ingenting om klienten og erstattar ikkje policyen som avgjer kven som får bruke backend.

Fragmentet er ikkje ein komplett frontend. Hald på lyttaren, autentiseringa, valet av tillaten vert og sti, og regelen som avgjer kven som i det heile får nå applikasjonen. Tilpass også backend-protokollen, fordi ein HTTPS-backend krev sertifikatverifisering og ein serveridentitetskonfigurasjon, og å hoppe over den sjekken gjer ei privat tilkopling til ei uverifisert.

Stadfest returvegen i begge retningar før du erklærer siger. Applikasjonen ser no ei tilkopling frå proxyen, så loggane og alle metadata om klientadressa skildrar proxyen med mindre du ordnar det annleis. Avgjer korleis identitet og videresende adresser blir handsama, og test avgjerda i staden for å anta henne.

Appen sine eigne omdirigeringar peikar framleis innover

Å videresende den første førespurnaden er berre halvparten av integrasjonen. Applikasjonen kan sende absolutte omdirigeringar, hardkoda asset-URL-ar eller informasjonskapslar avgrensa til namnet han kjenner internt, og kvar av dei sender nettlesaren tilbake til ei adresse han ikkje kan nå. Ein Location-header som peikar på det interne namnet ser identisk ut med det opphavlege problemet, og difor blir det feildiagnostisert som ein proxyfeil.

Set den dokumenterte eksterne URL-en til applikasjonen og proxyvala hans, og få deretter Host-headeren til å stemme med den virtuelle verten og forventningane til sertifikatet. Ein informasjonskapsel avgrensa til det interne namnet kjem ikkje tilbake gjennom det offentlege namnet, og innloggingsløkka som følgjer blir lesen som ein autentiseringsfeil. Endre den eksterne URL-en først, test på nytt frå ein rein nettlesarprofil, og forvent at halvmigrerte innstillingar gir ei innlogging som lukkast og ei økt som døyr med ein gong.

Stol på videresende metadata berre frå den utpeikte proxyen. Ein header som kvar klient kan setje, må aldri bli ein autorisasjonsverdi, elles blir proxyen ein måte for ein som kallar å påberope seg identiteten til ein annan. Den regelen er uavhengig av omdirigeringsspørsmålet og overlever kvar seinare redesign.

Avgjer kva design du faktisk har

Viss kvar brukar allereie har autorisert VPN-tilgang, kan ei omdirigering til ein privat URL vere eit medvite design. Stadfest det kravet eksplisitt i staden for å anta det, fordi dei to designa tener heilt ulike grupper. Det eine verkar ikkje i det heile frå eit hotellnettverk, og det andre eksponerer applikasjonen for alle som kan laste den offentlege URL-en. Den skilnaden høyrer heime i designnotatet.

Køyr sjekken frå ein maskin på nettverket til brukarane og følg kvar hopp nettlesaren gjer, ikkje berre det første svaret. Hald auge med adresselinja og kvar påfølgjande førespurnad, fordi éin absolutt URL i ein asset-tag er nok til å bryte ein flyt som det første hoppet klarte. Innlogging må verke gjennom det offentlege namnet, og ressursar som skal avvisast må halde fram med å vere avviste.

Å publisere ein omvend proxy er ei eiga tilgangsavgjerd, ikkje ei gjennomsiktig utviding av proxyen sin eigen VPN til alle som kan laste den offentlege URL-en hans. Dei to ser like ut på eit diagram, og dei skil seg i kven som slepp inn. Å avgjere det spørsmålet etter utrullinga er måten ein intern applikasjon ved eit uhell blir offentleg.

Skriv ned kva av dei to du bygde og kvifor. Den neste personen som rører konfigurasjonen vil anta den andre. Éi einsleg omdirigering lagd til for enkelheit skuld er nok til å gjenopprette den opphavlege feilen, og symtomet vil sjå nøyaktig ut som det du nettopp retta.