HAProxy 302 til en privat app: hvem åpner det andre hoppet?

Noen peker en offentlig HAProxy-vert mot en intern applikasjon og spør hvorfor nettleseren ikke kan følge etter. Proxyen når appen gjennom VPN-en sin, omdirigeringen returnerer en Location-header, og nettleseren prøver deretter en adresse som bare finnes inne i tunnelen. Utenfra henger siden rett og slett. Beslutningen handler om hvilken part som åpner den andre forbindelsen, og det er nettopp det som skiller en omdirigering fra et backend.

To veier som ser like ut i konfigurasjonen

En omdirigering avslutter utvekslingen med et svar. Klienten leser Location og starter en ny forespørsel fra der den befinner seg, altså nettverket du aldri kontrollerte. Proxyen er ikke lenger involvert. Alt som følger avhenger av klientens egen DNS, rute og tillit, så resultatet varierer etter hvor brukeren åpnet nettleseren:

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

Et proxy-backend holder det andre benet på serversiden. Proxyen åpner det over veien den allerede har, og klienten fortsetter å snakke med ett offentlig navn. Faller tunnelen, får klienten en feil i stedet for en URL den ikke kan følge. Den forskjellen er også det som gjør feilen diagnostiserbar, fordi feilen dukker opp der loggene er:

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

HAProxy sin dokumentasjon om omdirigeringer trekker nettopp denne grensen: å svare klienten med en omdirigering er en annen handling enn å videresende forespørselen til et backend. De to direktivene står noen linjer fra hverandre i en konfigurasjonsfil og oppfører seg helt ulikt. Den ene avslutter forespørselen, den andre begynner en til som proxyen eier.

Hva nettleseren trenger og serverens VPN ikke gir den

Nettleserens egen forespørsel trenger fire ting den kanskje ikke har: et DNS-svar for det private navnet, en rute til adressen, tillatelse til å nå tjenesten som lytter, og tillit til sertifikatet den tjenesten presenterer. Proxyverten har alle fire gjennom tunnelen sin. Ingen av dem overføres til en klient som aldri var i den tunnelen, fordi tunnelen er en egenskap ved verten, ikke ved URL-en.

Dette gapet forklarer nesten-virker-symptomet. Den første forespørselen lykkes, adresselinjen endres, og deretter henger eller feiler forbindelsen mens proxyen er sunn hele tiden. Ingenting er ødelagt i proxykonfigurasjonen, og å justere den hjelper ikke en klient uten rute til 10.40.0.20. Enten får klienten en rute, eller proxyen må gjøre forbindelsen på dens vegne.

Når bare proxyen kan nå appen

Fjern omdirigeringshandlingen og send de forespørslene til et backend som peker på den private adressen. Frontend beholder sitt offentlige navn mens backend bestemmer hvor forespørselen faktisk går. Ingenting endres i klientens vei, fordi proxyen slutter å beskrive en destinasjon og begynner å være en. For en applikasjon som med vilje lytter på den interne porten 8080, er serverblokken kort:

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

Les den blokken som en påstand om proxyens rutetabell: 10.40.0.20 må være tilgjengelig fra selve proxyverten, som her betyr gjennom VPN-grensesnittet og ikke gjennom standardruten. Nøkkelordet check rapporterer bare hva den ruten gjør, og helsestien må finnes på applikasjonen, ellers markerer hver sjekk serveren som nede. En bestått sjekk beviser ingenting om klienten og erstatter ikke policyen som avgjør hvem som får bruke backend.

Fragmentet er ikke et komplett frontend. Behold lytteren, autentiseringen, valget av tillatt vert og sti, og regelen som avgjør hvem som i det hele tatt får nå applikasjonen. Tilpass også backend-protokollen, fordi et HTTPS-backend krever sertifikatverifisering og en serveridentitetskonfigurasjon, og å hoppe over den sjekken gjør en privat forbindelse til en uverifisert.

Bekreft returveien i begge retninger før du erklærer seier. Applikasjonen ser nå en forbindelse fra proxyen, så loggene og alle metadata om klientadressen beskriver proxyen med mindre du ordner det annerledes. Bestem hvordan identitet og videresendte adresser håndteres, og test beslutningen i stedet for å anta den.

Appens egne omdirigeringer peker fortsatt innover

Å videresende den første forespørselen er bare halvparten av integrasjonen. Applikasjonen kan sende absolutte omdirigeringer, hardkodede asset-URL-er eller informasjonskapsler begrenset til navnet den kjenner internt, og hver av dem sender nettleseren tilbake til en adresse den ikke kan nå. En Location-header som peker på det interne navnet ser identisk ut med det opprinnelige problemet, og derfor feildiagnostiseres det som en proxyfeil.

Sett applikasjonens dokumenterte eksterne URL og proxyvalgene, og få deretter Host-headeren til å stemme med den virtuelle verten og sertifikatets forventninger. En informasjonskapsel begrenset til det interne navnet kommer ikke tilbake gjennom det offentlige navnet, og innloggingsløkken som følger leses som en autentiseringsfeil. Endre den eksterne URL-en først, test på nytt fra en ren nettleserprofil, og forvent at halvmigrerte innstillinger gir en innlogging som lykkes og en økt som dør umiddelbart.

Stol på videresendte metadata bare fra den utpekte proxyen. En header som enhver klient kan sette, må aldri bli en autorisasjonsverdi, ellers blir proxyen en måte for en som kaller å påberope seg en annens identitet. Den regelen er uavhengig av omdirigeringsspørsmålet og overlever enhver senere redesign.

Bestem hvilket design du faktisk har

Hvis hver bruker allerede har autorisert VPN-tilgang, kan en omdirigering til en privat URL være et bevisst design. Bekreft det kravet eksplisitt i stedet for å anta det, fordi de to designene betjener helt forskjellige grupper. Det ene virker ikke i det hele tatt fra et hotellnettverk, og det andre eksponerer applikasjonen for alle som kan laste den offentlige URL-en. Den forskjellen hører hjemme i designnotatet.

Kjør sjekken fra en maskin på brukernes nettverk og følg hvert hopp nettleseren gjør, ikke bare det første svaret. Hold øye med adresselinjen og hver påfølgende forespørsel, fordi én absolutt URL i en asset-tag er nok til å bryte en flyt som det første hoppet besto. Innlogging må virke gjennom det offentlige navnet, og ressurser som skal avvises må forbli avvist.

Å publisere en omvendt proxy er en egen tilgangsbeslutning, ikke en gjennomsiktig utvidelse av proxyens egen VPN til alle som kan laste dens offentlige URL. De to ser like ut på et diagram, og de skiller seg i hvem som slippes inn. Å avgjøre det spørsmålet etter utrullingen er måten en intern applikasjon ved et uhell blir offentlig.

Skriv ned hvilken av de to du bygde og hvorfor. Den neste personen som rører konfigurasjonen vil anta den andre. Én enkelt omdirigering lagt til for bekvemmelighet er nok til å gjenopprette den opprinnelige feilen, og symptomet vil se nøyaktig ut som det du nettopp rettet.