HAProxy 302 nei in privee-app: wa iepenet de twadde sprong?

Immen rjochtet in iepenbiere HAProxy-host op in lokale applikaasje en freget wêrom't de browser net folgje kin. De proxy berikt de app fia syn VPN, de trochferwizing jout in Location-header werom, en de browser besiket dan in adres dat allinnich binnen de tunnel bestiet. Fan bûten hinget de pagina gewoan. De beslissing giet oer hokker partij de twadde ferbining iepenet, en dat is wat in trochferwizing fan in backend skiedt.

Twa paden dy't yn 'e konfiguraasje op inoar lykje

In trochferwizing einiget de útwikseling mei in antwurd. De klient lêst Location en begjint in nij fersyk fan wêr't de klient ek sit, dat is it netwurk dat jo nea kontrolearre hawwe. De proxy is net mear belutsen. Alles wat folget hinget ôf fan 'e eigen DNS, rûte en fertrouwen fan 'e klient, dus de útkomst ferskilt nei wêr't de brûker de browser iepene hat:

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

In proxy-backend hâldt de twadde etappe oan 'e serverkant. De proxy iepenet dy oer it paad dat er al hat, en de klient bliuwt mei ien iepenbiere namme prate. As de tunnel falt, kriget de klient in flater ynstee fan in URL dy't er net folgje kin. Dat ferskil is ek wat de flater diagnoazeber makket, om't de flater ferskynt wêr't de logboeken binne:

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

HAProxy syn dokumintaasje oer trochferwizings lûkt krekt dy line: de klient mei in trochferwizing antwurdzje is in oare aksje as it fersyk nei in backend trochstjoere. De twa rjochtlinen steane in pear rigels fan inoar yn in konfiguraasjebestân en gedrage har hiel oars. De iene einiget it fersyk, de oare begjint in twadde dat fan 'e proxy is.

Wat de browser nedich hat en de VPN fan 'e server him net jout

It eigen fersyk fan 'e browser hat fjouwer dingen nedich dy't it miskien net hat: in DNS-antwurd foar de priveenamme, in rûte nei dat adres, tastimming om de tsjinjende tsjinst te berikken, en fertrouwen yn it sertifikaat dat dy tsjinst presintearret. De proxy-host hat alle fjouwer fia syn tunnel. Net ien dêrfan jout oer nei in klient dy't nea yn dy tunnel wie, om't de tunnel in eigenskip fan 'e host is, net fan 'e URL.

Dat gat ferklearret it suver-wurket-symptoom. It earste fersyk slagget, de adresbalke feroaret, en dan hinget de ferbining of mislearret wylst de proxy de hiele tiid sûn is. Der is neat stikken yn 'e proxy-konfiguraasje, en dy oanpasse helpt in klient net dy't gjin paad nei 10.40.0.20 hat. Of de klient krijt in rûte, of de proxy moat de ferbining foar him meitsje.

As allinnich de proxy de app berikke kin

Helje de trochferwizingsaksje fuort en stjoer dy fersiken nei in backend dat nei it privee-adres wiist. De frontend hâldt syn iepenbiere namme wylst de backend beslút wêr't it fersyk echt hinne giet. Oan it paad fan 'e klient feroaret neat, om't de proxy ophâldt mei it beskriuwen fan in bestimming en der ien begjint te wêzen. Foar in applikaasje dy't mei opsetsin op 'e ynterne poarte 8080 harket, is it serverblok koart:

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

Lês dat blok as in útspraak oer de routingstabel fan 'e proxy: 10.40.0.20 moat berikber wêze fan 'e proxy-host sels, wat hjir troch de VPN-interface betsjut en net troch de standertrûte. It kaaiwurd check rapportearret allinnich wat dy rûte docht, en it sûnenspaad moat op 'e applikaasje bestean, oars markearret elke probe de server as del. In slagge kontrôle bewissiget neat oer de klient en ferfangt net it belied dat beslút wa't de backend brûke mei.

It fragmint is gjin folsleine frontend. Hâld de listener, de autentikaasje, de seleksje fan tastiene host en paad, en de regel dy't beslút wa't de applikaasje hielendal berikke mei. Lês ek it backend-protokol oan, om't in HTTPS-backend sertifikaatferifikaasje en in serveridentiteit-konfiguraasje nedich hat, en dat kontrôle oerslaan makket fan in priveeferbining in net-ferifiearre ien.

Befêstigje it werompaad yn beide rjochtingen foardat jo de oerwinning útroppe. De applikaasje sjocht no in ferbining fan 'e proxy, dus syn logboeken en alle klientadres-metadata beskriuwe de proxy, útsein as jo it oars regelje. Beslút hoe't identiteit en trochstjoerde adressen behannele wurde, en test it beslút ynstee fan it oan te nimmen.

De eigen trochferwizings fan 'e app wize noch nei binnen

It trochstjoeren fan it earste fersyk is mar de helte fan 'e yntegraasje. De applikaasje kin absolute trochferwizings, hurdkoade asset-URL's of cookies útstjoere dy't beheind binne ta de namme dy't er yntern ken, en elk dêrfan stjoert de browser werom nei in adres dat er net berikke kin. In Location-header dy't nei de ynterne namme wiist, sjocht der identyk út as it oarspronklike probleem, en dêrom wurdt it ferkeard diagnostisearre as in proxy-flater.

Set de dokumintearre eksterne URL fan 'e applikaasje en syn proxy-opsjes, en lit de Host-header dan oerienkomme mei de firtuele host en de sertifikaatferwachtingen. In cookie dy't beheind is ta de ynterne namme komt net werom fia de iepenbiere namme, en de oanmeldingslus dy't folget wurdt lêzen as in autentikaasjeflater. Feroarje earst de eksterne URL, test op 'e nij fan in skjin browserprofyl, en ferwachtsje dat heal-migrearre ynstellings in oanmelding jouwe dy't slagget en in sesje dy't daliks stjert.

Fertrou trochstjoerde metadata allinnich fan 'e oanwiisde proxy. In header dy't elke klient sette kin, mei nea in autorisaasjewearde wurde, oars wurdt de proxy in manier foar in opropper om de identiteit fan in oar op te easkjen. Dy regel is ûnôfhinklik fan 'e trochferwizingsfraach en oerlibbet elke lettere weromûntwerp.

Beslút hokker ûntwerp jo echt hawwe

As elke brûker al autorisearre VPN-tagong hat, kin in trochferwizing nei in privee-URL in bewust ûntwerp wêze. Befêstigje dy eask eksplisyt ynstee fan it oan te nimmen, om't de twa ûntwerpen hiel ferskillende populaasjes tsjinje. Ien fan harren wurket hielendal net fan in hotelnetwurk, en de oare stelt de applikaasje bleat oan elkenien dy't de iepenbiere URL lade kin. Dat ûnderskie heart yn 'e ûntwerpnotysje.

Fier de kontrôle út fan in masine op it netwurk fan 'e brûkers en folgje elke sprong dy't de browser makket, net allinnich it earste antwurd. Hâld de adresbalke en elk folgjend fersyk yn 'e gaten, om't ien absolute URL yn in asset-tag genôch is om in stream te brekken dy't de earste sprong trochstie. Oanmelding moat fia de iepenbiere namme wurkje, en boarnen dy't wegere wurde moatte, moatte wegere bliuwe.

It publisearjen fan in omkearde proxy is in aparte tagongsbeslissing, net in transparante útwreiding fan 'e eigen VPN fan 'e proxy nei elkenien dy't syn iepenbiere URL lade kin. De twa lykje op in diagram, en se ferskille yn wa't talitten wurdt. Dat beslút nei de útrôl nimme is hoe't in ynterne applikaasje by ûngelok in iepenbiere wurdt.

Skriuw op hokker fan 'e twa jo boud hawwe en wêrom. De folgjende persoan dy't de konfiguraasje oanrekket, sil de oare oannimme. Ien inkele trochferwizing dy't foar gemak tafoege is, is genôch om de oarspronklike flater wer te meitsjen, en it symptoom sil der krekt sa útsjen as dat jo krekt reparearre hawwe.