HAProxy 302 til einkaaðgerðar: hver opnar seinni stökkið?

Einhver beinir opinberu HAProxy hýsingunni að innra forriti og spyr hvers vegna vafrinn geti ekki fylgt. Proxy-ið nær í forritið gegnum VPN-ið sitt, endurbeiningin skilar Location haus, og vafrinn reynir þá að slóð sem er aðeins til inni í göngunum. Að utan hangir síðan bara. Ákvörðunin snýst um hvort aðilinn opnar seinni tenginguna, og það er það sem greinir endurbeiningu frá backend.

Tvær leiðir sem líta svipað út í stillingunni

Endurbeining endar skiptin með svarinu. Biðlarinn les Location og byrjar nýja beiðni þaðan sem hann er, það er netinu sem þú stýrðir aldrei. Proxy-ið kemur ekki lengur við sögu. Allt sem fylgir fer eftir DNS, leið og trausti biðlarans sjálfs, þannig að niðurstaðan er breytileg eftir því hvar notandinn opnaði vafrann:

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

Backend proxy-sins heldur seinni þættinum á þjónshliðinni. Proxy-ið opnar hann um leiðina sem það hefur nú þegar, og biðlarinn heldur áfram að tala við eitt opinbert nafn. Ef göngin detta fær biðlarinn villu í stað vefslóðar sem hann getur ekki fylgt. Þessi munur er líka það sem gerir bilunina greinanlega, því villan birtist þar sem annálarnir eru:

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

Skjöl endurbeininga HAProxy draga nákvæmlega þessa línu: að svara biðlaranum með endurbeiningu er önnur aðgerð en að senda beiðnina til backend. Fyrirmælin tvö eru nokkrar línur í sundur í stillingaskrá og hegða sér algjörlega ólíkt. Annað endar beiðnina, hitt byrjar aðra sem proxy-ið á.

Hvað vafrinn þarf og VPN þjónsins gefur honum ekki

Beiðni vafrans sjálfs þarf fjóra hluti sem hann á kannski ekki: DNS svar fyrir einkanafnið, leið að þeirri slóð, leyfi til að ná í þjónustuna sem hlustar, og traust á skírteininu sem sú þjónusta leggur fram. Hýsing proxy-sins hefur öll fjögur gegnum göngin sín. Ekkert þeirra flyst til biðlara sem var aldrei í þeim göngum, því göngin eru eiginleiki hýsingarinnar, ekki vefslóðarinnar.

Þetta bil útskýrir einkennið næstum-virkar. Fyrsta beiðnin heppnast, slóðarstikan breytist, og svo hangir eða bregst tengingin meðan proxy-ið er heilbrigt allan tímann. Ekkert er brotið í stillingu proxy-sins, og að stilla hana hjálpar ekki biðlara sem hefur enga leið að 10.40.0.20. Annaðhvort fær biðlarinn leið, eða proxy-ið verður að gera tenginguna fyrir hann.

Þegar aðeins proxy-ið nær í forritið

Fjarlægðu endurbeiningaraðgerðina og sendu þessar beiðnir til backend sem bendir á einkaslóðina. Frontend heldur opinberu nafni sínu á meðan backend ræður því hvert beiðnin fer í raun. Ekkert breytist á leið biðlarans, því proxy-ið hættir að lýsa áfangastað og byrjar að vera hann. Fyrir forrit sem hlustar viljandi á innri gátt 8080 er þjónshlutinn stuttur:

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

Lestu þennan hlut sem fullyrðingu um leiðatöflu proxy-sins: 10.40.0.20 verður að vera aðgengileg frá hýsingu proxy-sins sjálfrar, sem hér þýðir gegnum VPN viðmótið en ekki sjálfgefnu leiðina. Lykilorðið check greinir aðeins frá því sem sú leið gerir, og heilsuslóðin verður að vera til í forritinu annars merkir hver prófun þjóninn sem niðri. Staðin prófun sannar ekkert um biðlarann og kemur ekki í stað stefnunnar sem ræður því hver má nota backend.

Brotinn er ekki heill frontend. Haltu hlustaranum, sannvottuninni, vali á leyfðri hýsingu og slóð, og reglunni sem ræður því hver má yfirhöfuð ná í forritið. Lagaðu líka backend samskiptareglur, því HTTPS backend krefst skírteinisstaðfestingar og stillingar á auðkenni þjóns, og að sleppa þeirri prófun gerir einkatengingu að óstaðfestri.

Staðfestu afturleiðina í báðar áttir áður en þú lýsir yfir sigri. Forritið sér nú tengingu frá proxy-inu, þannig að annálar þess og hvers kyns lýsigögn biðlaraslóðar lýsa proxy-inu nema þú haggir öðruvísi. Ákveddu hvernig auðkenni og framsendum slóðum er stýrt, og prófaðu ákvörðunina í stað þess að gera ráð fyrir henni.

Endurbeiningar forritsins sjálfs benda enn inn

Að senda fyrstu beiðnina áfram er aðeins helmingur samþættingarinnar. Forritið getur gefið út algjörar endurbeiningar, harðkóðaðar slóðir auðlinda eða vafrakökur sem takmarkast við nafnið sem það þekkir innanhúss, og hvert þeirra sendir vafrann aftur á slóð sem hann nær ekki. Location haus sem bendir á innra nafnið lítur nákvæmlega eins út og upphaflega vandamálið, og þess vegna er það ranggreint sem bilun í proxy-inu.

Stilltu skjalfesta ytri vefslóð forritsins og proxy valkosti þess, og láttu síðan Host hausinn passa við sýndarhýsinguna og væntingar skírteinisins. Vafrakaka sem takmarkast við innra nafnið kemur ekki til baka gegnum opinbera nafnið, og innskráningarhringurinn sem fylgir er lesinn sem sannvottunarvilla. Breyttu ytri vefslóðinni fyrst, prófaðu aftur úr hreinu vafraprófíli, og búðu þig við að hálffluttar stillingar framleiði innskráningu sem heppnast og setu sem deyr samstundis.

Treystu framsendum lýsigögnum aðeins frá tilnefndu proxy-inu. Haus sem hver biðlari getur stillt má aldrei verða heimildargildi, annars verður proxy-ið leið fyrir símtalandi að gera tilkall til auðkennis annars. Þessi regla er óháð endurbeiningarspurningunni og lifir af hverja síðari endurhönnun.

Ákveddu hvaða hönnun þú hefur í raun

Ef hver notandi hefur þegar heimilaðan VPN aðgang getur endurbeining á einkaslóð verið viljandi hönnun. Staðfestu þá kröfu skýrt í stað þess að gera ráð fyrir henni, því hönnunarnar tvær þjóna algjörlega ólíkum hópum. Önnur virkar alls ekki úr hótelneti, og hin afhjúpar forritið fyrir hverjum sem getur hlaðið opinberu slóðinni. Sá greinarmunur á heima í hönnunarnótunni.

Keyrðu prófunina frá vél á neti notendanna og fylgdu hverju stökki sem vafrinn tekur, ekki aðeins fyrsta svarinu. Fylgstu með slóðarstikunni og hverri beiðni á eftir, því ein algjör vefslóð í auðlindamerki er nóg til að brjóta flæði sem fyrsta stökkið komst í gegnum. Innskráning verður að virka gegnum opinbera nafnið, og auðlindir sem á að neita verða að vera áfram neitaðar.

Að birta öfugt proxy er sérstök aðgangsákvörðun, ekki gagnsæ framlenging á VPN proxy-sins sjálfs til hvers sem getur hlaðið opinberu slóð þess. Þau tvö líta eins út á skýringarmynd, og þau greinast í því hverjum er hleypt inn. Að ákveða þá spurningu eftir uppsetninguna er hvernig innra forrit verður opinbert fyrir slysni.

Skrifaðu niður hvorri hönnuninni þú byggðir og hvers vegna. Næsta manneskja sem snertir stillinguna mun gera ráð fyrir hinni. Ein endurbeining sem bætt er við af hagkvæmni er nóg til að endurskapa upphaflegu bilunina, og einkennið mun líta nákvæmlega út eins og það sem þú lagaðir rétt í þessu.