HAProxy 302 privaatsesse rakendusse: kes avab teise hüppe?

Keegi suunab avaliku HAProxy-host'i kohalikule rakendusele ja küsib, miks brauser ei saa järgida. Puhverserver jõuab rakenduseni oma VPN-i kaudu, ümbersuunamine tagastab Location-päise ja brauser proovib seejärel aadressi, mis eksisteerib ainult tunnelis. Väljastpoolt lihtsalt hangub leht. Otsus on selles, milline pool avab teise ühenduse, ja just see eristab ümbersuunamist backendist.

Kaks teed, mis konfiguratsioonis sarnased välja näevad

Ümbersuunamine lõpetab vahetuse vastusega. Klient loeb Locationi ja alustab uue päringu sealt, kus ta asub, see tähendab võrgust, mida te kunagi ei kontrollinud. Puhverserver ei osale enam. Kõik järgnev sõltub kliendi enda DNS-ist, marsruudist ja usaldusest, seega tulemus varieerub selle järgi, kus kasutaja brauseri avas:

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

Puhverserveri backend hoiab teise etapi serveripoolsel küljel. Puhverserver avab selle mööda teed, mis tal juba on, ja klient jätkab suhtlemist ühe avaliku nimega. Kui tunnel katkeb, saab klient vea, mitte URL-i, mida ta ei saa järgida. Just see erinevus teeb rikke diagnoositavaks, sest viga ilmub seal, kus on logid:

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

HAProxy ümbersuunamise dokumentatsioon tõmbab täpselt selle piiri: kliendile ümbersuunamisega vastata on teine tegevus kui päringu backendile edastamine. Kaks direktiivi asuvad konfiguratsioonifailis mõne rea kaugusel ja käituvad täiesti erinevalt. Üks lõpetab päringu, teine alustab teise, mis kuulub puhverserverile.

Mida brauser vajab ja mida serveri VPN talle ei anna

Brauseri enda päring vajab nelja asja, mida tal võib olla: DNS-vastust privaatsele nimele, marsruuti sellele aadressile, luba kuulava teenuseni jõudmiseks ja usaldust sertifikaadi vastu, mille see teenus esitab. Puhverserveri hostil on kõik neli oma tunneli kaudu. Ükski neist ei kandu üle kliendile, kes ei ole kunagi selles tunnelis olnud, sest tunnel on hosti omadus, mitte URL-i oma.

See lünk seletab sümptomit peaaegu töötab. Esimene päring õnnestub, aadressiriba muutub ja seejärel ühendus hangub või ebaõnnestub, samal ajal kui puhverserver on kogu aeg terve. Puhverserveri konfiguratsioonis pole midagi katki ja selle kohandamine ei aita klienti, kellel pole teed 10.40.0.20-ni. Kas klient saab marsruudi või peab puhverserver ühenduse tema eest looma.

Kui ainult puhverserver pääseb rakendusele ligi

Eemalda ümbersuunamise tegevus ja saada need päringud backendile, mis osutab privaatsele aadressile. Frontend hoiab oma avalikku nime, samal ajal kui backend otsustab, kuhu päring tegelikult läheb. Kliendi teekonnas ei muutu midagi, sest puhverserver lõpetab sihtkoha kirjeldamise ja hakkab ise selleks olema. Rakenduse jaoks, mis kuulab teadlikult sisemisel pordil 8080, on serveriplokk lühike:

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

Lugege seda plokki väitena puhverserveri marsruutimistabeli kohta: 10.40.0.20 peab olema kättesaadav puhverserveri hostilt endalt, mis tähendab siin VPN-liidese kaudu, mitte vaikimisi marsruudi kaudu. Võtmesõna check teatab ainult seda, mida see marsruut teeb, ja tervise tee peab rakenduses olemas olema, muidu märgib iga kontroll serveri maas olevaks. Õnnestunud kontroll ei tõesta kliendi kohta midagi ega asenda poliitikat, mis otsustab, kes tohib backendi kasutada.

Fragment ei ole täielik frontend. Hoidke kuulaja, autentimine, lubatud hosti ja tee valik ning reegel, mis otsustab, kes üldse rakendusele ligi pääseb. Sobitage ka backendi protokoll, sest HTTPS-backend vajab sertifikaadi kontrolli ja serveri identiteedi konfiguratsiooni ning selle kontrolli vahelejätmine muudab privaatse ühenduse kontrollimata ühenduseks.

Kinnitage tagasitee mõlemas suunas enne võidu väljakuulutamist. Rakendus näeb nüüd ühendust puhverserverilt, seega kirjeldavad selle logid ja kliendi aadressi metaandmed puhverserverit, kui te ei korralda teisiti. Otsustage, kuidas identiteeti ja edastatud aadresse käsitletakse, ning testige otsust, selle asemel et seda eeldada.

Rakenduse enda ümbersuunamised osutavad endiselt sissepoole

Esimese päringu edastamine on ainult pool integratsiooni. Rakendus võib väljastada absoluutseid ümbersuunamisi, kõvakodeeritud ressursi-URL-e või küpsiseid, mis on piiratud nimega, mida ta sisemiselt teab, ja igaüks neist saadab brauseri tagasi aadressile, kuhu see ei pääse. Sisemisele nimele osutav Location-päis näeb välja täpselt nagu algne probleem, mistõttu diagnoositakse see ekslikult puhverserveri rikkeks.

Seadke rakenduse dokumenteeritud väline URL ja selle puhverserveri valikud, seejärel viige Host-päis kooskõlla virtuaalse hosti ja sertifikaadi ootustega. Sisemise nimega piiratud küpsis ei tule avaliku nime kaudu tagasi ja sellele järgnev sisselogimistsükkel loetakse autentimisveaks. Muutke kõigepealt välist URL-i, testige uuesti puhtast brauseriprofiilist ja oodake, et pooleldi migreeritud seaded annavad sisselogimise, mis õnnestub, ja sessiooni, mis sureb kohe.

Usaldage edastatud metaandmeid ainult selleks määratud puhverserverilt. Päist, mille iga klient saab seada, ei tohi kunagi saada autoriseerimisväärtust, muidu muutub puhverserver viisiks, kuidas kutsuja väidab end olevat keegi teine. See reegel on ümbersuunamise küsimusest sõltumatu ja elab üle iga hilisema ümberkujunduse.

Otsustage, milline disain teil tegelikult on

Kui igal kasutajal on juba autoriseeritud VPN-ligipääs, võib ümbersuunamine privaatsele URL-ile olla teadlik disain. Kinnitage seda nõuet selgesõnaliselt, selle asemel et seda eeldada, sest kaks disaini teenindavad täiesti erinevaid rühmi. Üks neist ei tööta hotellivõrgust üldse ja teine paljastab rakenduse kõigile, kes suudavad avaliku URL-i laadida. See eristus kuulub disainimärkmesse.

Käivitage kontroll masinast kasutajate võrgus ja jälgige iga hüpet, mille brauser teeb, mitte ainult esimest vastust. Jälgige aadressiriba ja iga järgnevat päringut, sest üks absoluutne URL ressursi sildis on piisav, et murda voog, mille esimene hüpe läbis. Sisselogimine peab toimima avaliku nime kaudu ja ressursid, mida tuleks keelata, peavad jääma keelatuks.

Pöördpuhverserveri avaldamine on eraldi juurdepääsuotsus, mitte puhverserveri enda VPN-i läbipaistev laiendus kõigile, kes suudavad selle avaliku URL-i laadida. Diagrammil näevad need kaks sarnased välja ja erinevad selle poolest, kes on lubatud sisse. Selle küsimuse otsustamine pärast juurutamist on viis, kuidas sisemisest rakendusest saab kogemata avalik.

Kirjutage üles, millise kahest te ehitasite ja miks. Järgmine inimene, kes konfiguratsiooni puudutab, eeldab teist. Üks mugavuse pärast lisatud ümbersuunamine on piisav algse rikke taasloomiseks ja sümptom näeb välja täpselt nagu see, mille te just parandasite.