Hindi ikinokonekta ng proxy_redirect ang NGINX sa iyong VPN host

May salitang redirect ang pangalan, kaya idinidikit ito sa isang location block kapag hindi maabot ang backend sa likod ng VPN. Walang nagbabago, at ang halatang konklusyon ay sira ang direktiba o nangangailangan ito ng ibang sintaksis. Ang talagang nangyari ay mas simple at hindi gaanong nakakapuri: gumagana ang proxy_redirect sa isang tugon na nakabalik na, at sa deployment na ito walang kahilingan ang nakarating nang ganoon kalayo.

Dalawang direktiba, dalawang sandali sa isang kahilingan

Ang kahilingang HTTP sa pamamagitan ng reverse proxy ay dumadaan sa ilang desisyon nang sunud-sunod, at ang dalawang direktiba ay nasa magkabilang dulo ng sekwensyang iyon. Pinipili ng isa kung saan pupunta ang kahilingan. Binabago ng isa pa ang ilang header sa tugon na bumabalik.

Ang pagkakasunod-sunod na iyon ang buong sagot. Kung hindi kailanman tumakbo ang ikalawang linya dahil nabigo ang una, hindi mali ang pagkaka-configure ng ikalawang direktiba, hindi lamang ito maabot. Gaano man kalimitang isulat muli ang ikalawang linya, hindi mabubuo ang tugon na dapat nitong i-edit. Magsuri mula sa unang linya pakanluran, at ang nakakalitong pag-uugali ay nauuwi sa nawawalang ruta o tinanggihang koneksyon.

Ang pagpili ng upstream ay trabaho ng proxy_pass

Ipagpalagay na tumatakbo ang NGINX sa isang pampublikong entry host at naaabot ang isang aplikasyon sa 10.40.0.20:8080 sa pamamagitan ng VPN nito. Ang piraso na pumipili sa aplikasyong iyon ay ganito ang hitsura, sa loob ng umiiral na server block:

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

Gamitin ang totoong scheme, address at port, at ituring ito bilang piraso at hindi deployment. Kailangan ding hawakan ng entry host ang ruta ng VPN, pinapayagang forwarding path at gumaganang return traffic patungo sa serbisyong iyon, dahil ang proxy na umaabot sa isang address sa papel ay kailangan pa rin ng pahintulot ng kernel.

Ang sanggunian ng proxy module ay naghihiwalay ng pagpili ng upstream mula sa muling pagsulat ng mga header ng tugon, at binabanggit na ang isang halagang proxy_pass na may URI ay nagbabago kung paano pinapalitan ang tugmang location prefix. Ang pagdaragdag o pag-alis ng mga bahagi ng path nang hindi sinusuri ang URL na inaasahan ng aplikasyon ay isang maaasahang paraan upang makabuo ng 404 na mukhang pagkabigo sa routing.

Inaayos ng proxy_redirect ang mga tugon na naglalabas ng pribadong address

Kapag dumaloy na ang trapiko, maaaring sumagot ang backend gamit ang header na Location na nagbabanggit ng pribadong address nito. Ang browser na sumusunod sa header na iyon ay lumalabas sa pampublikong entry point at sinusubukang maabot ang isang bagay na hindi nito maresolba. Ang sadyang naka-configure na muling pagsulat ng tugon ay nagmamapa ng pribadong URL sa pampubliko:

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

Palitan ang magkabilang panig ng totoong halaga. Unawain din ang makitid na saklaw: ang tumutugmang teksto ng mga header na Location at Refresh ay muling isinusulat, ngunit ang mga URL na naka-embed sa HTML, JavaScript o mga na-download na file ay hindi.

Kung ang isang aplikasyon ay gumagawa ng mga absolute na link saanman, ang matibay na solusyon ay ang sarili nitong configuration ng panlabas na URL, hindi ang lumalaking listahan ng mga tuntunin sa muling pagsulat sa proxy. Ang pagdaragdag ng mga tuntunin hanggang sa magmukhang tama ang output ay gumagawa ng configuration na nabibigo sa unang pahinang walang sinumang sumubok. Isang tamang setting ng aplikasyon ang pumapalit sa buong koleksyon.

Ano ang hindi kayang ayusin ng muling pagsulat ng header

Ilang kalapit na problema ay mukhang problema sa redirect ngunit hindi. Ang header ng Host na ipinapadala sa upstream ay maaaring kailangang tumugma sa virtual host ng backend. Ang TLS upstream ay maaaring mangailangan ng partikular na pangalan ng server at pagpapatunay ng sertipiko, at walang natutulungan ang muling pagsulat ng header ng tugon sa alinman.

Ang saklaw ng cookie at mga katangian ng domain ay pag-aari ng aplikasyon at ng configuration nito. Maaaring magtapon o magsulat muli ng mga header ang proxy buong araw at makabuo pa rin ng sesyon na nabibigo sa ikalawang kahilingan, dahil ang cookie ay inisyu para sa host na hindi kailanman binisita ng browser. Ang kabiguan na iyon ay mukhang pabagu-bago, kaya tumatagal ito nang matagal sa pila ng tiket. Ang pagbasa ng domain ng cookie ay karaniwang nagtatapos ng pagsisiyasat sa isang minuto.

Panatilihing nakatali rin ang authentication at pagpili ng backend sa nilalayong aplikasyon. Ang pampublikong reverse proxy ay dapat maglantad ng isang aplikasyon sa pamamagitan ng VPN ng server sa halip na maging pangkalahatang gateway sa bawat pribadong address na naaabot ng host na iyon. Ang isang pangkalahatang location na nagpapasa ng lahat ng hinihiling ng tumatawag ay ginagawang mapa ng iyong pribadong network ang isang nakalantad na serbisyo. Pangalanan ang upstream nang tahasan at panatilihin ito roon.

Subukan sa pagkakasunod-sunod na binabyahe ng kahilingan

Kumpirmahin ang tatlong bagay nang sunud-sunod: pinili ng NGINX ang nilalayong location, natapos ang kahilingan sa backend, at sinundan ng browser ang anumang susunod na redirect at na-load ang mga sub-resource. Bawat hakbang ay may sariling mga log line, at ang pagbasa sa mga ito nang sunud-sunod ay ginagawang tiyak na natuklasan ang malabong 502.

Ang pagkakaibang kailangan mo ay sa pagitan ng bigong koneksyon sa upstream at browser na ipinadala sa hindi maabot na pribadong pangalan. Ang una ay lumilitaw sa error log ng proxy; ang pangalawa ay lumilitaw bilang kahilingang hindi kailanman dumarating, habang nagrereklamo ang browser tungkol sa host na hindi nito maresolba. Dalawang magkaibang problema, dalawang magkaibang file, at isa lamang sa mga ito ang may kinalaman sa proxy_redirect.