HAProxy 302 yksityiseen sovellukseen: kuka avaa toisen hypyn?

Joku osoittaa julkisen HAProxy-isännän paikalliseen sovellukseen ja kysyy, miksi selain ei voi seurata. Välityspalvelin saavuttaa sovelluksen VPN:nsä kautta, uudelleenohjaus palauttaa Location-otsakkeen, ja selain yrittää sitten osoitetta, joka on olemassa vain tunnelin sisällä. Ulkopuolelta sivu yksinkertaisesti jumittuu. Päätös on siitä, kumpi osapuoli avaa toisen yhteyden, ja juuri se erottaa uudelleenohjauksen backendistä.

Kaksi polkua, jotka näyttävät kokoonpanossa samalta

Uudelleenohjaus päättää vaihdon vastaukseen. Asiakas lukee Locationin ja aloittaa uuden pyynnön siitä, missä se sattuu olemaan, eli verkosta, jota et koskaan hallinnut. Välityspalvelin ei ole enää mukana. Kaikki seuraava riippuu asiakkaan omasta DNS:stä, reitistä ja luottamuksesta, joten tulos vaihtelee sen mukaan, missä käyttäjä avasi selaimen:

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

Välityspalvelimen backend pitää toisen osuuden palvelinpuolella. Välityspalvelin avaa sen reittiä, joka sillä jo on, ja asiakas jatkaa puhumista yhdelle julkiselle nimelle. Jos tunneli katkeaa, asiakas saa virheen sen sijaan, että saisi URL:n, jota se ei voi seurata. Juuri tämä ero tekee viasta diagnosoitavan, koska virhe ilmestyy sinne, missä lokit ovat:

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

HAProxyn uudelleenohjausdokumentaatio vetää juuri tämän rajan: asiakkaalle uudelleenohjauksella vastaaminen on eri toimenpide kuin pyynnön välittäminen backendille. Kaksi direktiiviä ovat kokoonpanotiedostossa muutaman rivin päässä toisistaan ja käyttäytyvät täysin eri tavoin. Toinen lopettaa pyynnön, toinen aloittaa toisen, joka kuuluu välityspalvelimelle.

Mitä selain tarvitsee ja mitä palvelimen VPN ei sille anna

Selaimen oma pyyntö tarvitsee neljä asiaa, joita sillä ei ehkä ole: DNS-vastauksen yksityiselle nimelle, reitin tuohon osoitteeseen, luvan päästä kuuntelevaan palveluun ja luottamuksen siihen sertifikaattiin, jonka palvelu esittää. Välityspalvelimen isännällä on kaikki neljä tunnelinsa kautta. Mikään niistä ei siirry asiakkaalle, joka ei ole koskaan ollut siinä tunnelissa, koska tunneli on isännän ominaisuus, ei URL:n.

Tämä aukko selittää melkein-toimii-oireen. Ensimmäinen pyyntö onnistuu, osoiterivi muuttuu, ja sitten yhteys jumittuu tai epäonnistuu, kun välityspalvelin on koko ajan kunnossa. Välityspalvelimen kokoonpanossa ei ole mitään rikki, eikä sen säätäminen auta asiakasta, jolla ei ole reittiä 10.40.0.20:een. Joko asiakas saa reitin tai välityspalvelimen on tehtävä yhteys sen puolesta.

Kun vain välityspalvelin pääsee sovellukseen

Poista uudelleenohjaustoimenpide ja lähetä ne pyynnöt backendille, joka osoittaa yksityiseen osoitteeseen. Frontend pitää julkisen nimensä, kun taas backend päättää, mihin pyyntö todella menee. Asiakkaan polussa mikään ei muutu, koska välityspalvelin lakkaa kuvaamasta kohdetta ja alkaa olla sellainen. Sovellukselle, joka kuuntelee tarkoituksella sisäistä porttia 8080, palvelinlohko on lyhyt:

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

Lue tämä lohko väitteenä välityspalvelimen reititystaulusta: 10.40.0.20:n on oltava tavoitettavissa välityspalvelimen isännästä itsestään, mikä tarkoittaa tässä VPN-rajapinnan kautta eikä oletusreittiä pitkin. Avainsana check vain raportoi, mitä tuo reitti tekee, ja terveyspolun on oltava sovelluksessa, muuten jokainen tarkistus merkitsee palvelimen alas. Läpäisty tarkistus ei todista mitään asiakkaasta eikä korvaa käytäntöä, joka päättää, kuka saa käyttää backendia.

Katkelma ei ole täydellinen frontend. Säilytä kuuntelija, todennus, sallitun isännän ja polun valinta sekä sääntö, joka päättää, kuka ylipäätään saa päästä sovellukseen. Sovita myös backendin protokolla, sillä HTTPS-backend tarvitsee sertifikaattivarmennuksen ja palvelimen identiteettikokoonpanon, ja tarkistuksen väliin jättäminen muuttaa yksityisen yhteyden vahvistamattomaksi.

Vahvista paluupolku molempiin suuntiin ennen kuin julistat voiton. Sovellus näkee nyt yhteyden välityspalvelimelta, joten sen lokit ja kaikki asiakasosoitteen metatiedot kuvaavat välityspalvelinta, ellet järjestä toisin. Päätä, miten identiteettiä ja välitettyjä osoitteita käsitellään, ja testaa päätös sen sijaan, että olettaisit sen.

Sovelluksen omat uudelleenohjaukset osoittavat yhä sisäänpäin

Ensimmäisen pyynnön välittäminen on vain puolet integraatiosta. Sovellus voi lähettää absoluuttisia uudelleenohjauksia, kovakoodattuja resurssien URL-osoitteita tai evästeitä, jotka on rajattu nimeen, jonka se tuntee sisäisesti, ja jokainen niistä lähettää selaimen takaisin osoitteeseen, johon se ei pääse. Sisäiseen nimeen osoittava Location-otsake näyttää identtiseltä alkuperäisen ongelman kanssa, minkä vuoksi se diagnosoidaan virheellisesti välityspalvelimen viaksi.

Aseta sovelluksen dokumentoitu ulkoinen URL ja sen välityspalvelinasetukset ja sovita sitten Host-otsake virtuaaliseen isäntään ja sertifikaatin odotuksiin. Sisäiseen nimeen rajattu eväste ei palaa julkisen nimen kautta, ja sitä seuraava kirjautumissilmukka luetaan todennusbugiksi. Vaihda ensin ulkoinen URL, testaa uudelleen puhtaasta selainprofiilista ja odota, että puoliksi siirretyt asetukset tuottavat kirjautumisen, joka onnistuu, ja istunnon, joka kuolee heti.

Luota välitettyihin metatietoihin vain nimetyltä välityspalvelimelta. Otsake, jonka kuka tahansa asiakas voi asettaa, ei saa koskaan tulla valtuutusarvoksi, muuten välityspalvelimesta tulee tapa, jolla kutsuja väittää olevansa joku muu. Tämä sääntö on riippumaton uudelleenohjauskysymyksestä ja kestää jokaisen myöhemmän uudelleensuunnittelun.

Päätä, mikä suunnittelu sinulla todella on

Jos jokaisella käyttäjällä on jo valtuutettu VPN-yhteys, uudelleenohjaus yksityiseen URL-osoitteeseen voi olla tarkoituksellinen suunnittelu. Vahvista tämä vaatimus nimenomaisesti sen sijaan, että olettaisit sen, koska kaksi suunnittelua palvelee täysin eri väestöjä. Toinen niistä ei toimi lainkaan hotelliverkosta, ja toinen altistaa sovelluksen kaikille, jotka voivat ladata julkisen URL:n. Tämä ero kuuluu suunnittelumuistioon.

Suorita tarkistus käyttäjien verkossa olevasta koneesta ja seuraa jokaista hyppyä, jonka selain tekee, älä vain ensimmäistä vastausta. Seuraa osoiteriviä ja jokaista myöhempää pyyntöä, koska yksi absoluuttinen URL resurssitunnisteessa riittää rikkomaan virran, jonka ensimmäinen hyppy läpäisi. Kirjautumisen on toimittava julkisen nimen kautta, ja resurssien, jotka pitäisi kieltää, on pysyttävä kiellettyinä.

Käänteisen välityspalvelimen julkaiseminen on erillinen käyttöpäätös, ei välityspalvelimen oman VPN:n läpinäkyvä laajennus kaikille, jotka voivat ladata sen julkisen URL:n. Ne kaksi näyttävät samalta kaaviossa, ja ne eroavat siinä, kuka päästetään sisään. Tämän kysymyksen päättäminen käyttöönoton jälkeen on tapa, jolla sisäisestä sovelluksesta tulee vahingossa julkinen.

Kirjoita muistiin, kumman kahdesta rakensit ja miksi. Seuraava henkilö, joka koskee kokoonpanoon, olettaa toisen. Yksi mukavuuden vuoksi lisätty uudelleenohjaus riittää alkuperäisen vian uudelleenluomiseen, ja oire näyttää täsmälleen siltä, jonka juuri korjasit.