proxy_redirect NGINX ستاسو د VPN هوسټ سره نه نښلوي
proxy_redirect په مخکې رسېدلي ځواب کې سرلیکونه بیا لیکي؛ دا هېڅکله upstream نه غوره کوي۔ proxy_pass، backend ته لار، بیا سرلیکونه وګورئ۔
نوم د redirect کلمه لري، نو کله چې د VPN شاته backend د لاسرسي وړ نه وي، په location بلاک کې نښلول کیږي۔ هېڅ نه بدلیږي، او ښکاره پایله دا ده چې لارښوونه خرابه ده یا بل نحو ته اړتیا لري۔ په حقیقت کې چې څه وشول، ساده او لږ ستاینه یې ده: proxy_redirect پر هغه ځواب کار کوي چې مخکې راستن شوی وي، او په دې ځای پرځای کولو کې هېڅ غوښتنه هومره لرې ونه رسېده۔
دوه لارښوونې، په یوه غوښتنه کې دوه شیبې
د ریورس پروکسي له لارې تېرېدونکې HTTP غوښتنه په ترتیب سره له څو پرېکړو تېریږي، او دوه لارښوونې د هغه ترتیب په دوو مخالفو سرونو کې دي۔ یوه ټاکي چې غوښتنه چېرې ځي۔ بله په راستنېدونکي ځواب کې ځینې سرلیکونه سمونې کوي۔
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
همدا ترتیب ټول ځواب دی۔ که لومړۍ کرښه ناکامه شوې وی چې دوهمه کرښه هېڅکله ونه چلیږي، نو دوهمه لارښوونه غلطه نه ده تنظیم شوې، یوازې د لاسرسي وړ نه ده۔ هر څومره چې دوهمه کرښه بیا ولیکل شي، هغه ځواب چې باید سمونې یې کړی وی نه جوړیږي۔ له لومړۍ کرښې بهر ته تشخیص وکړئ، او ګډوډ چلند په ورک پاتې لار یا رد شوې اړیکه کې حل کیږي۔
د upstream غوره کول د proxy_pass کار دی
فرض کړئ NGINX په یوه عامه ننوتلو هوسټ کې چلیږي او د خپل VPN له لارې 10.40.0.20:8080 کې یو اپلیکیشن ته رسیدلی شي۔ هغه اپلیکیشن غوره کوونکی ټوټه په موجود server بلاک کې داسې ښکاري:
location / {
proxy_pass http://10.40.0.20:8080;
}اصلي سکیم، پته او پورټ وکاروئ، او دا د ځای پرځای کولو نه بلکې د ټوټې په توګه وګڼئ۔ د ننوتلو هوسټ باید د VPN لار، اجازه ورکړل شوې لېږدونکې لار او د هغې خدمت ته د کار کوونکې راستنېدونکې ترافیک هم وساتي، ځکه چې په کاغذ پته ته رسیدونکي پروکسي بیا هم د کرنل رضایت ته اړتیا لري۔
د proxy ماډل حواله د upstream غوره کول د ځواب سرلیکونو له بیا لیکلو جلا ساتي، او یادونه کوي چې URI لرونکې proxy_pass ارزښت بدلوي چې مطابق location مختاړی څنګه بدلیږي۔ د لارې برخې پرته له دې چې د اپلیکیشن هغه URL وګوري چې تمه یې لري زیاتول یا لرې کول 404 پیدا کولو باوري لاره ده چې د لارښوونې ناکامي په څېر ښکاري۔
proxy_redirect هغه ځوابونه سمونې کوي چې خصوصي پته افشا کوي
کله چې ترافیک روان شي، backend کیدلی شي د خپلې خصوصي پتې یادونه کوونکې Location سرلیک سره ځواب ووایي۔ هغه سرلیک تعقیبوونکی براوزر عمومی ننوتلو نقطه پرېږدي او هغه څه ته د رسیدو هڅه کوي چې حل یې نه شي کولی۔ په قصد جوړه شوې د ځواب بیا لیکنه خصوصي URL په عمومي باندې نقشه کوي:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;دواړه خواوې په اصلي ارزښتونو بدلې کړئ۔ تنګه حوزه هم وپېژنئ: مطابق Location او Refresh سرلیکونو متن بیا لیکل کیږي، خو په HTML، JavaScript یا ډاونلوډ شوو فایلونو کې نښلول شوې URL نه۔
که یو اپلیکیشن هر چېرې مطلق لینکونه جوړوي، تلپاتې حل د هغه خپله بهرنۍ-URL ترتیبات دي، په پروکسي باندې د زیاتیدونکو بیا لیکلو قاعدو لیست نه۔ تر هغې چې پایله سمه ښکاره شي قاعدې زیاتول داسې ترتیبات جوړوي چې په لومړي هغه پاڼه کې ناکامیږي چې چا ازموینه نه ده کړې۔ د اپلیکیشن یو سم تنظیم ټول ټولګه بدلوي۔
سرلیک بیا لیکنه څه سمولای نه شي
څو نږدې ستونزې د بیا لارښوونې ستونزو په څېر ښکاري خو نه دي۔ upstream ته لېږل شوې Host سرلیک کیدلی شي د backend مجازي هوسټ سره سمون ولري۔ TLS upstream کیدلی شي ځانګړی سرور نوم او د سند تایید ته اړتیا ولري، او د ځواب سرلیک بیا لیکنه د دواړو لپاره هېڅ نه کوي۔
د کوکیز حوزه او د ډومین ځانګړنې اپلیکیشن او د هغه ترتیباتو پورې اړه لري۔ پروکسي ټول ورځ سرلیکونه غورځولای یا بیا لیکلای شي او بیا هم داسې غونډه جوړوي چې په دوهمه غوښتنه کې ناکامیږي، ځکه چې کوکی د هغه هوسټ لپاره صادر شوې وه چې براوزر هېڅکله نه دی لیدلی۔ هغه ناکامي وخت په وخت ښکاري، نو ځکه په ټیکټ قطار کې دومره اوږده پاتې کیږي۔ د کوکي ډومین لوستل عموماً په یوه دقیقه کې پلټنه پای ته رسوي۔
تصدیق او د backend غوره کول هم په هدف اپلیکیشن پورې محدود وساتئ۔ عامه ریورس پروکسي باید د سرور VPN له لارې یوازې یو اپلیکیشن ښکاره کړي، د هغه هوسټ د لاسرسي وړ هرې خصوصي پتې لپاره عمومي دروازه کیدو پرځای۔ یو عمومي location چې هر څه کوم چې غوښتونکی غواړي لېږدوي، یوه افشا شوې خدمت ستاسو د خصوصي شبکې نقشې ته اړوي۔ upstream په څرګند ډول ونوموئ او هماغلته یې وساتئ۔
هغه ترتیب چې غوښتنه پکې سفر کوي هماغه ترتیب کې ازموینه وکړئ
په ترتیب سره درې شیان تایید کړئ: NGINX هدف location غوره کړ، backend ته غوښتنه بشپړه کړه، او براوزر هر وروستي بیا لارښوونه تعقیب کړه او فرعي سرچینې یې بار کړې۔ هر پړاو خپل لاګ کرښې لري، او هغه په ترتیب لوستل ناڅرګند 502 په یوه مشخص موندنه اړوي۔
هغه توپیر چې تاسو ته اړین دی د ناکامې upstream اړیکې او د لاسرسي وړ نه وي خصوصي نوم ته لېږل شوي براوزر ترمنځ دی۔ لومړی د پروکسي تېروتنې لاګ کې ښکاري؛ دوهم داسې غوښتنې په څېر ښکاري چې هېڅکله نه رسیږي، او براوزر د هغه هوسټ شکایت کوي چې حل یې نه شي کولی۔ دوه بېلې ستونزې، دوه بېلې فایلونه، او یوازې یو یې له proxy_redirect سره اړه لري۔