HAProxy 302 i app breifat: pwy sy’n agor yr ail naid?

Mae rhywun yn pwyntio gwesteiwr HAProxy cyhoeddus at ap lleol ac yn gofyn pam na all y porwr ddilyn. Mae’r proxy yn cyrraedd yr app drwy ei VPN, mae’r ailgyfeiriad yn dychwelyd pennawd Location, ac yna mae’r porwr yn ceisio cyfeiriad sydd ond yn bodoli y tu mewn i’r tiwnel. O’r tu allan mae’r dudalen yn hongian yn syml. Y penderfyniad yw pa barti sy’n agor yr ail gysylltiad, a dyna sy’n gwahanu ailgyfeiriad oddi wrth backend.

Dau lwybr sy’n edrych yn debyg yn y ffurfweddiad

Mae ailgyfeiriad yn gorffen y cyfnewid ag ymateb. Mae’r cleient yn darllen Location ac yn dechrau cais newydd o ble bynnag y mae, sef y rhwydwaith na wnaethoch chi erioed ei reoli. Nid yw’r proxy yn rhan ohono mwyach. Mae popeth sy’n dilyn yn dibynnu ar DNS, llwybr ac ymddiriedaeth y cleient ei hun, felly mae’r canlyniad yn amrywio yn ôl ble y gwnaeth y defnyddiwr agor y porwr:

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

Mae backend y proxy yn cadw’r ail goes ar ochr y gweinydd. Mae’r proxy yn ei agor ar hyd y llwybr sydd ganddo’n barod, ac mae’r cleient yn parhau i siarad ag un enw cyhoeddus. Os yw’r tiwnel yn cwympo, mae’r cleient yn derbyn gwall yn lle URL na all ei ddilyn. Y gwahaniaeth hwnnw hefyd sy’n gwneud y methiant yn ddiagnostigadwy, oherwydd mae’r gwall yn ymddangos lle mae’r logiau:

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

Mae dogfennaeth ailgyfeirio HAProxy yn tynnu’r union linell hon: ateb y cleient ag ailgyfeiriad yw gweithred wahanol i anfon y cais ymlaen i backend. Mae’r ddau gyfarwyddeb ychydig linellau oddi wrth ei gilydd mewn ffeil ffurfweddu ac yn ymddwyn yn hollol wahanol. Mae un yn gorffen y cais, a’r llall yn dechrau ail un sy’n eiddo i’r proxy.

Yr hyn sydd ei angen ar y porwr ac nad yw VPN y gweinydd yn ei roi iddo

Mae angen pedwar peth ar gais y porwr ei hun na fydd ganddo efallai: ateb DNS i’r enw preifat, llwybr i’r cyfeiriad hwnnw, caniatâd i gyrraedd y gwasanaeth sy’n gwrando, ac ymddiriedaeth yn y dystysgrif y mae’r gwasanaeth hwnnw’n ei chyflwyno. Mae gwesteiwr y proxy yn berchen ar y pedwar drwy ei diwnel. Nid oes yr un ohonynt yn trosglwyddo i gleient nad oedd erioed ar y tiwnel hwnnw, oherwydd mae’r tiwnel yn briodwedd o’r gwesteiwr, nid o’r URL.

Mae’r bwlch hwnnw’n esbonio’r symptom bron-yn-gweithio. Mae’r cais cyntaf yn llwyddo, mae’r bar cyfeiriad yn newid, ac yna mae’r cysylltiad yn hongian neu’n methu tra bo’r proxy’n iach drwy’r amser. Nid oes dim wedi torri yng nghyfluniad y proxy, ac ni all ei addasu helpu cleient heb lwybr i 10.40.0.20. Naill ai mae’r cleient yn cael llwybr, neu mae’n rhaid i’r proxy wneud y cysylltiad ar ei ran.

Pan mai dim ond y proxy all gyrraedd yr app

Tynnwch y weithred ailgyfeirio ac anfonwch y ceisiadau hynny i backend sy’n pwyntio at y cyfeiriad preifat. Mae’r frontend yn cadw ei enw cyhoeddus tra bo’r backend yn penderfynu i ble mae’r cais yn mynd mewn gwirionedd. Nid oes dim yn newid yn llwybr y cleient, oherwydd mae’r proxy’n rhoi’r gorau i ddisgrifio cyrchfan ac yn dechrau bod yn un. Ar gyfer ap sy’n gwrando’n fwriadol ar borth mewnol 8080, mae’r bloc gweinydd yn fyr:

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

Darllenwch y bloc hwnnw fel datganiad am dabl llwybro’r proxy: rhaid i 10.40.0.20 fod yn gyrraeddadwy o westeiwr y proxy ei hun, sy’n golygu yma drwy’r rhyngwyneb VPN yn hytrach na’r llwybr diofyn. Nid yw’r allweddair check ond yn adrodd beth mae’r llwybr hwnnw’n ei wneud, a rhaid i’r llwybr iechyd fodoli ar yr app neu bydd pob prawf yn marcio’r gweinydd fel un i lawr. Nid yw prawf sy’n llwyddo’n profi dim am y cleient ac nid yw’n disodli’r polisi sy’n penderfynu pwy gaiff ddefnyddio’r backend.

Nid yw’r darn yn frontend cyflawn. Cadwch y gwrandawr, y dilysu, y dewis o westeiwr a llwybr a ganiateir, a’r rheol sy’n penderfynu pwy gaiff gyrraedd yr app o gwbl. Cydweddwch brotocol y backend hefyd, oherwydd mae backend HTTPS angen dilysu tystysgrif a chyfluniad hunaniaeth gweinydd, ac mae hepgor y prawf hwnnw’n troi cysylltiad preifat yn un heb ei ddilysu.

Cadarnhewch y llwybr dychwelyd i’r ddau gyfeiriad cyn datgan buddugoliaeth. Mae’r app bellach yn gweld cysylltiad o’r proxy, felly mae ei logiau a unrhyw fetadata cyfeiriad cleient yn disgrifio’r proxy oni bai eich bod yn trefnu fel arall. Penderfynwch sut mae hunaniaeth a chyfeiriadau a anfonwyd ymlaen yn cael eu trin, a phrofwch y penderfyniad yn hytrach na’i dybio.

Mae ailgyfeiriadau’r app ei hun yn dal i bwyntio tuag i mewn

Nid yw anfon y cais cyntaf ymlaen ond hanner y gwaith integreiddio. Gall yr app allyrru ailgyfeiriadau absoliwt, URL asedau wedi’u codio’n galed, neu gwcis wedi’u cwmpasu i’r enw y mae’n ei wybod yn fewnol, ac mae pob un ohonynt yn anfon y porwr yn ôl i gyfeiriad na all ei gyrraedd. Mae pennawd Location sy’n pwyntio at yr enw mewnol yn edrych yn union yr un fath â’r broblem wreiddiol, a dyna pam mae’n cael ei gamddiagnosio fel methiant proxy.

Gosodwch URL allanol dogfennedig yr app a’i opsiynau proxy, yna gwnaethpwyd pennawd Host gytuno â’r gwesteiwr rhithwir a disgwyliadau’r dystysgrif. Ni fydd cwci wedi’i gwmpasu i’r enw mewnol yn dod yn ôl drwy’r enw cyhoeddus, ac mae’r ddolen fewngofnodi sy’n dilyn yn darllen fel nam dilysu. Newidiwch yr URL allanol yn gyntaf, ailbrofwch o broffil porwr glân, a disgwyliwch i osodiadau hanner-migredig gynhyrchu mewngofnod sy’n llwyddo a sesiwn sy’n marw ar unwaith.

Ymddiriedwch fetadata a anfonwyd ymlaen dim ond o’r proxy a ddynodwyd. Rhaid i bennawd y gall unrhyw gleient ei osod byth ddod yn werth awdurdodi, neu bydd y proxy’n troi’n ffordd i alwr hawlio hunaniaeth rhywun arall. Mae’r rheol hon yn annibynnol o gwestiwn yr ailgyfeiriad ac yn goroesi pob ailddyluniad diweddarach.

Penderfynwch pa ddyluniad sydd gennych mewn gwirionedd

Os oes gan bob defnyddiwr fynediad VPN awdurdodedig yn barod, gall ailgyfeiriad i URL preifat fod yn ddyluniad bwriadol. Cadarnhewch y gofyniad hwnnw’n benodol yn hytrach na’i dybio, oherwydd mae’r ddau ddyluniad yn gwasanaethu poblogaethau hollol wahanol. Nid yw un ohonynt yn gweithio o gwbl o rwydwaith gwesty, ac mae’r llall yn datgelu’r app i unrhyw un sy’n gallu llwytho’r URL cyhoeddus. Mae’r gwahaniaeth hwnnw’n perthyn i’r nodyn dylunio.

Rhedwch y prawf o beiriant ar rwydwaith y defnyddwyr a dilynwch bob naid y mae’r porwr yn ei wneud, nid yn unig yr ymateb cyntaf. Cadwch lygad ar y bar cyfeiriad ac ar bob cais dilynol, oherwydd mae un URL absoliwt mewn tag ased yn ddigon i dorri llif y llwyddodd y naid gyntaf drwyddo. Rhaid i fewngofnodi weithio drwy’r enw cyhoeddus, a rhaid i adnoddau y dylid eu gwrthod aros wedi’u gwrthod.

Mae cyhoeddi proxy gwrthdro yn benderfyniad mynediad ar wahân, nid yn estyniad tryloyw o VPN y proxy ei hun i unrhyw un sy’n gallu llwytho ei URL cyhoeddus. Mae’r ddau’n edrych yn debyg ar ddiagram, ac maent yn wahanol yn y pwy a ganiateir i mewn. Penderfynu’r cwestiwn hwnnw ar ôl y defnydd yw sut mae app fewnol yn dod yn un gyhoeddus ar ddamwain.

Ysgrifennwch pa un o’r ddau a adeiladwyd gennych a pham. Bydd y person nesaf i gyffwrdd â’r ffurfweddiad yn tybio’r llall. Mae un ailgyfeiriad a ychwanegwyd er hwylustod yn ddigon i ailgreu’r methiant gwreiddiol, a bydd y symptom yn edrych yn union fel yr un yr ydych newydd ei drwsio.