HAProxy 302 drejt një aplikacioni privat: kush hap kërcimin e dytë?

Dikush drejton një host publik HAProxy drejt një aplikacioni lokal dhe pyet pse shfletuesi nuk mund ta ndjekë. Proxy arrin te aplikacioni përmes VPN-së së vet, ridrejtimi kthen një header Location dhe shfletuesi pastaj provon një adresë që ekziston vetëm brenda tunelit. Nga jashtë faqja thjesht ngec. Vendimi ka të bëjë me atë se cila palë hap lidhjen e dytë, dhe pikërisht kjo e dallon një ridrejtim nga një backend.

Dy rrugë që duken njësoj në konfigurim

Një ridrejtim e përfundon shkëmbimin me një përgjigje. Klienti lexon Location dhe nis një kërkesë të re nga vendi ku ndodhet, domethënë nga rrjeti që nuk e keni kontrolluar kurrë. Proxy nuk është më i përfshirë. Gjithçka që vijon varet nga DNS, rruga dhe besimi i vetë klientit, kështu që rezultati ndryshon sipas vendit ku përdoruesi hapi shfletuesin:

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

Një backend i proxy-t e mban këmbën e dytë në anën e serverit. Proxy e hap atë përgjatë rrugës që tashmë ka, dhe klienti vazhdon të flasë me një emër publik të vetëm. Nëse tuneli bie, klienti merr një gabim në vend të një URL-je që nuk mund ta ndjekë. Ky dallim është gjithashtu ai që e bën dështimin të diagnostikueshëm, sepse gabimi shfaqet aty ku janë regjistrat:

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

Dokumentacioni i HAProxy për ridrejtimet e tërheq pikërisht këtë vijë: t'i përgjigjesh klientit me një ridrejtim është një veprim ndryshe nga përcjellja e kërkesës te një backend. Dy direktivat qëndrojnë disa rreshta larg njëra-tjetrës në një skedar konfigurimi dhe sillen krejt ndryshe. Njëra e përfundon kërkesën, dhe tjetra nis një të dytë që proxy e zotëron.

Çfarë i duhet shfletuesit që VPN-ja e serverit nuk ia jep

Kërkesa e vetë shfletuesit ka nevojë për katër gjëra që mund të mos i ketë: një përgjigje DNS për emrin privat, një rrugë drejt asaj adrese, leje për të arritur shërbimin që dëgjon dhe besim për çdo certifikatë që ai shërbim paraqet. Host-i i proxy-t i zotëron të katërta përmes tunelit të vet. Asnjëra prej tyre nuk kalon te një klient që nuk ishte kurrë në atë tunel, sepse tuneli është veti e host-it, jo e URL-së.

Ky hendek shpjegon simptomën «thuajse funksionon». Kërkesa e parë kalon, shiriti i adresës ndryshon dhe lidhja pastaj ngec ose dështon, ndërkohë që proxy është i shëndetshëm gjatë gjithë kohës. Asgjë nuk është prishur në konfigurimin e proxy-t, dhe rregullimi i tij nuk mund të ndihmojë një klient që nuk ka rrugë drejt 10.40.0.20. Ose klienti merr një rrugë, ose proxy duhet ta bëjë lidhjen në emër të tij.

Kur vetëm proxy mund ta arrijë aplikacionin

Hiqni veprimin e ridrejtimit dhe dërgoni ato kërkesa te një backend që tregon adresën private. Frontend-i mban emrin e vet publik, ndërsa backend-i vendos ku shkon në të vërtetë kërkesa. Asgjë në rrugën e klientit nuk ndryshon, sepse proxy ndalon së përshkruari një destinacion dhe bëhet vetë destinacioni. Për një aplikacion që dëgjon me qëllim në portën e brendshme 8080, blloku i serverit është i shkurtër:

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

Lexojeni atë bllok si një pohim për tabelën e rrugëzimit të proxy-t: adresa 10.40.0.20 duhet të jetë e arritshme nga vetë host-i i proxy-t, që këtu do të thotë përmes ndërfaqes VPN dhe jo përmes rrugës së parazgjedhur. Fjala kyçe check raporton vetëm çfarë bën ajo rrugë, dhe shtegu i kontrollit të shëndetit duhet të ekzistojë në aplikacion, përndryshe çdo provë e shënon serverin si jashtë funksionit. Një kontroll që kalon nuk provon asgjë për klientin dhe nuk zëvendëson politikën që vendos kush mund ta përdorë backend-in.

Ky fragment nuk është një frontend i plotë. Mbani dëgjuesin, autentikimin, zgjedhjen e host-it dhe shtegut të lejuar, si dhe rregullin që vendos kush mund ta arrijë fare aplikacionin. Përputhni edhe protokollin e backend-it, sepse një backend HTTPS kërkon verifikim certifikate dhe një konfigurim identiteti serveri, dhe anashkalimi i atij kontrolli e kthen një lidhje private në një lidhje të paverifikuar.

Konfirmoni rrugën e kthimit në të dyja drejtimet përpara se të shpallni fitore. Aplikacioni tani sheh një lidhje nga proxy, kështu që regjistrat e tij dhe çdo metadata për adresën e klientit përshkruajnë proxy, përveçse nëse organizoni ndryshe. Vendosni si trajtohen identiteti dhe adresat e përcjella, dhe provojeni atë vendim në vend që ta supozoni.

Ridrejtimet e vetë aplikacionit ende tregojnë nga brenda

Përcjellja e kërkesës së parë është vetëm gjysma e integrimit. Aplikacioni mund të lëshojë ridrejtime absolute, URL burimesh të koduara fort ose cookie të kufizuara në emrin që njeh nga brenda, dhe secili prej tyre e kthen shfletuesin te një adresë që nuk mund ta arrijë. Një header Location që tregon emrin e brendshëm duket njësoj si problemi fillestar, prandaj diagnostikohet gabimisht si dështim i proxy-t.

Vendosni URL-në e jashtme të dokumentuar të aplikacionit dhe opsionet e tij të proxy-t, pastaj bëni që header-i Host të përputhet me host-in virtual dhe pritshmëritë e certifikatës. Një cookie i kufizuar në emrin e brendshëm nuk do të kthehet përmes emrit publik, dhe cikli i hyrjes që vijon lexohet si një gabim autentikimi. Ndryshoni së pari URL-në e jashtme, riprovoni nga një profil i pastër shfletuesi dhe prisni që cilësimet gjysmë të transferuara të prodhojnë një hyrje që kalon dhe një sesion që vdes menjëherë.

Besojini metadatave të përcjella vetëm nga proxy i caktuar. Një header që çdo klient mund ta vendosë nuk duhet të bëhet kurrë vlerë autorizimi, përndryshe proxy kthehet në një mënyrë për një thirrës të përvetësojë identitetin e dikujt tjetër. Ky rregull është i pavarur nga çështja e ridrejtimit dhe mbijeton çdo ridizajnim të mëvonshëm.

Vendosni cilin dizajn keni në të vërtetë

Nëse të gjithë përdoruesit kanë tashmë akses të autorizuar përmes VPN-së, një ridrejtim drejt një URL-je private mund të jetë një dizajn i qëllimshëm. Konfirmojeni atë kërkesë shprehimisht në vend që ta supozoni, sepse dy dizajnet u shërbejnë popullsive krejt të ndryshme. Njëri prej tyre nuk funksionon fare nga një rrjet hoteli, dhe tjetri e ekspozon aplikacionin ndaj kujtdo që mund të ngarkojë URL-në publike. Ai dallim i përket shënimit të projektimit.

Kryeni kontrollin nga një makinë në rrjetin e përdoruesve dhe ndiqni çdo kërcim që bën shfletuesi, jo vetëm përgjigjen e parë. Mbajini sytë te shiriti i adresës dhe te çdo kërkesë pasuese, sepse mjafton një URL absolute në një etiketë burimi për të prishur një rrjedhë që kërcimi i parë e kaloi. Hyrja duhet të funksionojë përmes emrit publik, dhe burimet që duhet të refuzohen duhet të mbeten të refuzuara.

Publikimi i një proxy të kundërt është një vendim i veçantë aksesi, jo një zgjatim transparent i VPN-së së vetë proxy-t për këdo që mund të ngarkojë URL-në e tij publike. Të dyja duken njësoj në një diagram, dhe ndryshojnë në atë se kush lejohet të hyjë. Vendosja e kësaj çështje pas vendosjes në punë është mënyra se si një aplikacion i brendshëm bëhet aksidentalisht publik.

Shkruani cilin prej tyre ndërtuat dhe pse. Personi i radhës që prek konfigurimin do të supozojë tjetrin. Një ridrejtim i vetëm i shtuar për lehtësi mjafton për të rikrijuar dështimin fillestar, dhe simptoma do të duket saktësisht si ajo që sapo rregulluat.