proxy_redirect NGINX-কে আপনার VPN হোস্টের সঙ্গে যুক্ত করে না
proxy_redirect ইতিমধ্যে আসা উত্তরের হেডার পুনর্লিখন করে; এটি কখনও আপস্ট্রিম বেছে নেয় না। proxy_pass, ব্যাকএন্ডের রুট, তারপর হেডার যাচাই করুন।
নামের মধ্যে redirect শব্দটি আছে, তাই VPN-এর পিছনের কোনো ব্যাকএন্ডে পৌঁছানো না গেলে এটি 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 |
এই ক্রমটাই সম্পূর্ণ উত্তর। যদি প্রথম সারি ব্যর্থ হওয়ার কারণে দ্বিতীয় সারি কখনও চলে না, তবে দ্বিতীয় নির্দেশনাটি ভুলভাবে কনফিগার করা নয়, এটি কেবল পৌঁছানোর বাইরে। দ্বিতীয় লাইন যতবারই নতুন করে লেখা হোক, এটি যে উত্তরটি সম্পাদনার কথা ছিল তা তৈরি হবে না। প্রথম সারি থেকে বাইরের দিকে নির্ণয় করুন, আর বিভ্রান্তিকর আচরণটি একটি অনুপস্থিত রুট বা প্রত্যাখ্যাত সংযোগে মিটে যায়।
আপস্ট্রিম বেছে নেওয়া proxy_pass-এর কাজ
ধরা যাক NGINX একটি পাবলিক এন্ট্রি হোস্টে চলে এবং তার VPN দিয়ে 10.40.0.20:8080-এ একটি অ্যাপ্লিকেশনে পৌঁছাতে পারে। সেই অ্যাপ্লিকেশনটি বেছে নেওয়া অংশটি একটি বিদ্যমান server ব্লকের ভেতরে এমন দেখায়:
location / {
proxy_pass http://10.40.0.20:8080;
}প্রকৃত স্কিম, ঠিকানা ও পোর্ট ব্যবহার করুন এবং এটিকে স্থাপনা নয়, অংশ হিসেবে ধরুন। এন্ট্রি হোস্টকে VPN রুট, অনুমোদিত ফরওয়ার্ডিং পথ এবং সেই সেবায় কাজ করা ফেরত ট্রাফিকও ধরে রাখতে হবে, কারণ কাগজে ঠিকানায় পৌঁছাতে পারা প্রক্সির তবুও কার্নেলের সম্মতি দরকার।
proxy মডিউলের রেফারেন্স আপস্ট্রিম নির্বাচনকে উত্তরের হেডার পুনর্লিখন থেকে আলাদা রাখে এবং উল্লেখ করে যে URI-সহ একটি proxy_pass মান মিলে যাওয়া location প্রিফিক্স কীভাবে প্রতিস্থাপিত হয় তা বদলে দেয়। অ্যাপ্লিকেশন যে URL প্রত্যাশা করে তা না দেখে পাথের উপাদান যোগ বা বাদ দেওয়া 404 তৈরি করার একটি নির্ভরযোগ্য উপায়, যা রাউটিং ব্যর্থতার মতো দেখায়।
proxy_redirect ব্যক্তিগত ঠিকানা ফাঁস করা উত্তর ঠিক করে
ট্রাফিক চলতে শুরু করলে ব্যাকএন্ড তার ব্যক্তিগত ঠিকানা উল্লেখ করা একটি Location হেডার দিয়ে উত্তর দিতে পারে। সেই হেডার অনুসরণ করা ব্রাউজার পাবলিক এন্ট্রি পয়েন্ট ছেড়ে এমন কিছুতে পৌঁছাতে চায় যা এটি রিজলভ করতে পারে না। সচেতনভাবে কনফিগার করা উত্তর পুনর্লিখন ব্যক্তিগত URL-কে পাবলিক ঠিকানার ওপর ম্যাপ করে:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;দুই দিকই প্রকৃত মান দিয়ে প্রতিস্থাপন করুন। সংকীর্ণ পরিধিও বুঝুন: মিলে যাওয়া Location ও Refresh হেডারের লেখা পুনর্লিখিত হয়, কিন্তু HTML, JavaScript বা ডাউনলোড করা ফাইলে এমবেড করা URL পুনর্লিখিত হয় না।
কোনো অ্যাপ্লিকেশন যদি সর্বত্র নিখুঁত লিঙ্ক তৈরি করে, তবে টেকসই সমাধান হলো তার নিজের এক্সটার্নাল-URL কনফিগারেশন, প্রক্সিতে পুনর্লিখনের নিয়মের ক্রমবর্ধমান তালিকা নয়। আউটপুট ঠিক দেখানো পর্যন্ত নিয়ম যোগ করলে এমন কনফিগারেশন তৈরি হয় যা প্রথম এমন পাতাতেই ব্যর্থ হয় যা কেউ পরীক্ষা করেনি। একটি সঠিক অ্যাপ্লিকেশন সেটিং পুরো সংগ্রহের জায়গা নেয়।
হেডার পুনর্লিখন যা মেরামত করতে পারে না
কয়েকটি সংলগ্ন সমস্যা রিডাইরেক্ট সমস্যার মতো দেখায়, কিন্তু তা নয়। আপস্ট্রিমে পাঠানো Host হেডারকে ব্যাকএন্ডের ভার্চুয়াল হোস্টের সঙ্গে মিলতে হতে পারে। TLS আপস্ট্রিমের নির্দিষ্ট সার্ভার নাম ও সার্টিফিকেট যাচাই দরকার হতে পারে, এবং উত্তর হেডার পুনর্লিখন এ দুটির কোনোটিরই উপকার করে না।
কুকির পরিধি ও ডোমেইন অ্যাট্রিবিউট অ্যাপ্লিকেশন ও তার কনফিগারেশনের বিষয়। প্রক্সি সারা দিন হেডার ফেলে দিতে বা পুনর্লিখন করতে পারে এবং তবুও এমন সেশন তৈরি করে যা দ্বিতীয় অনুরোধেই ব্যর্থ হয়, কারণ কুকিটি এমন হোস্টের জন্য দেওয়া হয়েছিল যা ব্রাউজার কখনও দেখেনি। সেই ব্যর্থতা মাঝে মাঝে ঘটে বলে দেখা যায়, তাই এটি টিকিট সারিতে এত দিন টিকে থাকে। কুকির ডোমেইন পড়লেই সাধারণত এক মিনিটে তদন্ত শেষ হয়।
প্রমাণীকরণ ও ব্যাকএন্ড নির্বাচনকেও উদ্দিষ্ট অ্যাপ্লিকেশনের মধ্যে সীমাবদ্ধ রাখুন। একটি পাবলিক রিভার্স প্রক্সি সার্ভারের VPN দিয়ে একটি অ্যাপ্লিকেশন প্রকাশ করবে, সেই হোস্ট যে কোনো ব্যক্তিগত ঠিকানায় পৌঁছাতে পারে এমন একটি সর্বজনীন গেটওয়ে হয়ে ওঠার বদলে. একটি সাধারণ location যা আহ্বানকারী যা চায় তা-ই ফরওয়ার্ড করে, একটি প্রকাশিত সেবাকে আপনার ব্যক্তিগত নেটওয়ার্কের ম্যাপে পরিণত করে। আপস্ট্রিমের নাম স্পষ্টভাবে দিন এবং সেখানেই রাখুন।
অনুরোধ যে ক্রমে ভ্রমণ করে সেই ক্রমে পরীক্ষা করুন
পরপর তিনটি বিষয় নিশ্চিত করুন: NGINX উদ্দিষ্ট location বেছে নিয়েছে, ব্যাকএন্ডে অনুরোধ সম্পন্ন করেছে, এবং ব্রাউজার পরবর্তী যেকোনো রিডাইরেক্ট অনুসরণ করে উপসম্পদ লোড করেছে। প্রতিটি ধাপের নিজস্ব লগ লাইন আছে, এবং সেগুলো ক্রমে পড়লে অস্পষ্ট 502 একটি নির্দিষ্ট অনুসন্ধানে পরিণত হয়।
আপনার দরকারি পার্থক্য হলো ব্যর্থ আপস্ট্রিম সংযোগ আর পৌঁছানো-অসম্ভব ব্যক্তিগত নামে পাঠানো ব্রাউজারের মধ্যে। প্রথমটি প্রক্সি এরর লগে দেখা যায়; দ্বিতীয়টি এমন অনুরোধ হিসেবে দেখা যায় যা কখনও আসে না, আর ব্রাউজার এমন হোস্টের অভিযোগ করে যা সে রিজলভ করতে পারে না। দুটি ভিন্ন সমস্যা, দুটি ভিন্ন ফাইল, এবং তাদের একটিই কেবল proxy_redirect-এর সঙ্গে সম্পর্কিত।