proxy_redirect haiunganishi NGINX na host yako ya VPN

Jina lina neno redirect, kwa hivyo huwekwa ndani ya block ya location wakati backend iliyo nyuma ya VPN haiwezi kufikiwa. Hakuna kinachobadilika, na hitimisho la wazi ni kwamba agizo hilo limevunjika au linahitaji sintaksia nyingine. Kilichotokea kwa kweli ni rahisi zaidi na hakuna sifa: proxy_redirect hufanya kazi kwenye jibu ambalo tayari limerudi, na katika usambazaji huu hakuna ombi lolote lililofika mbali hivyo.

Maagizo mawili, nyakati mbili katika ombi moja

Ombi la HTTP kupitia proksi ya kinyume hupitia maamuzi kadhaa kwa mpangilio, na maagizo hayo mawili yako kwenye ncha pinzani za mfuatano huo. Moja huchagua ombi linaenda wapi. Lingine huhariri vichwa vya habari fulani katika jibu linalorudi.

Mpangilio huo ndio jibu lote. Ikiwa mstari wa pili hautatekelezwa kamwe kwa sababu wa kwanza umeshindwa, agizo la pili halijasanidiwa vibaya, haliwezi kufikiwa tu. Hata mstari wa pili uandikwe upya mara ngapi, jibu ambalo liliundwa kuhariri halitatokea. Fanya uchunguzi kuanzia mstari wa kwanza kuelekea nje, na tabia ya kutatanisha hujikita katika njia inayokosekana au muunganisho uliokataliwa.

Kuchagua upstream ni kazi ya proxy_pass

Tuseme NGINX inaendesha kwenye host ya kuingia ya umma na inaweza kufikia programu kwenye 10.40.0.20:8080 kupitia VPN yake. Kipande kinachochagua programu hiyo kinaonekana hivi, ndani ya block ya server iliyopo:

location / {
    proxy_pass http://10.40.0.20:8080;
}

Tumia mpango, anwani na bandari halisi, na chukulia hii kama kipande na si usambazaji. Host ya kuingia pia lazima ihifadhi njia ya VPN, njia ya upelekaji inayoruhusiwa na trafiki ya kurudi inayofanya kazi kwa huduma hiyo, kwa sababu proksi inayofikia anwani kwenye karatasi bado inahitaji ridhaa ya kernel.

Rejea ya moduli ya proxy huweka uchaguzi wa upstream mbali na uandikaji upya wa vichwa vya jibu, na inabainisha kwamba thamani ya proxy_pass iliyo na URI hubadilisha jinsi kiambishi cha location kinacholingana hubadilishwa. Kuongeza au kuondoa sehemu za njia bila kukagua URL ambayo programu inatarajia ni njia ya kuaminika ya kutokeza 404 inayofanana na kushindwa kwa uelekezaji.

proxy_redirect hurekebisha majibu yanayovujisha anwani ya faragha

Trafiki ianzapo kutiririka, backend inaweza kujibu kwa kichwa cha Location kinachotaja anwani yake ya faragha. Kivinjari kinachofuata kichwa hicho huondoka kwenye sehemu ya kuingia ya umma na kujaribu kufikia kitu ambacho hakiwezi kutatua. Uandikaji upya wa jibu uliosanidiwa kwa makusudi huweka URL ya faragha juu ya ile ya umma:

proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;

Badilisha pande zote mbili kwa thamani halisi. Elewa pia wigo mwembamba: maandishi ya vichwa vya Location na Refresh yanayolingana huandikwa upya, lakini URL zilizopachikwa katika HTML, JavaScript au faili zilizopakuliwa hazifanyi hivyo.

Ikiwa programu hujenga viungo kamili kila mahali, suluhisho la kudumu ni usanidi wake wa URL ya nje, si orodha inayokua ya kanuni za uandikaji upya kwenye proksi. Kuongeza kanuni hadi matokeo yaonekane sawa hutoa usanidi unaoshindwa kwenye ukurasa wa kwanza ambao hakuna aliyelijaribu. Mpangilio mmoja sahihi wa programu hubadilisha mkusanyiko wote.

Kile uandikaji upya wa kichwa hawezi kurekebisha

Matatizo kadhaa ya jirani yanaonekana kama matatizo ya uelekezaji upya lakini sivyo. Kichwa cha Host kinachotumwa kwa upstream kinaweza kuhitaji kuendana na host pepe ya backend. Upstream ya TLS inaweza kuhitaji jina maalum la seva pamoja na uthibitishaji wa cheti, na uandikaji upya wa kichwa cha jibu hausaidii kwa yote mawili.

Wigo wa vidakuzi na sifa za kikoa ni mali ya programu na usanidi wake. Proksi inaweza kutupa au kuandika upya vichwa vya jibu mchana kutwa na bado itatoa kipindi kinachoshindwa kwenye ombi la pili, kwa sababu kidakuzi kilitolewa kwa host ambayo kivinjari hakikuwahi kuitembelea. Kushindwa huko kunaonekana kwa vipindi, ndiyo sababu hudumu muda mrefu katika foleni ya tiketi. Kusoma kikoa cha kidakuzi kwa kawaida humaliza uchunguzi kwa dakika moja.

Weka pia uthibitishaji na uchaguzi wa backend ukiwa umezuiwa kwa programu iliyokusudiwa. Proksi ya kinyume ya umma inapaswa kudhihirisha programu moja kupitia VPN ya seva badala ya kuwa lango la jumla kwa kila anwani ya faragha ambayo host hiyo inaweza kufikia. location moja ya jumla inayopeleka kila kitu anachoomba mwita hubadilisha huduma moja iliyodhihirishwa kuwa ramani ya mtandao wako wa faragha. Taja upstream kwa uwazi na uihifadhi hapo.

Jaribu kwa mpangilio ambao ombi husafiri

Thibitisha mambo matatu kwa mfuatano: NGINX ilichagua location iliyokusudiwa, ilikamilisha ombi kwa backend, na kivinjari kilifuata uelekezaji upya wowote wa baadaye na kupakia rasilimali ndogo. Kila hatua ina mistari yake ya kumbukumbu, na kuisoma kwa mpangilio hugeuza 502 isiyoeleweka kuwa ugunduzi mahususi.

Tofauti unayohitaji ni kati ya muunganisho wa upstream ulioshindwa na kivinjari kilichotumwa kwa jina la faragha lisilofikika. La kwanza linaonekana katika kumbukumbu ya makosa ya proksi; la pili linaonekana kama ombi ambalo halifiki kamwe, huku kivinjari kikilalamika kuhusu host ambayo hakiwezi kuitatua. Matatizo mawili tofauti, faili mbili tofauti, na moja tu kati yao linahusisha proxy_redirect.