কেন VPN সাইটের 403 প্রক্সি ব্যর্থতা নয়
উৎসের 403, প্রত্যাখ্যাত CONNECT এবং 407 চ্যালেঞ্জ ভিন্ন সীমা চিহ্নিত করে। প্রথমে প্রক্সির এগ্রেস পথ ব্রাউজারের VPN ঠিকানার সঙ্গে তুলনা করুন।
ব্যবহারকারীরা VPN বন্ধ করে, একটি অভ্যন্তরীণ সাইটে 403 পান এবং জানান যে প্রক্সি নষ্ট। তিনটি আলাদা বিষয় ওই পৃষ্ঠাটি তৈরি করতে পারে: উৎস অনুরোধটি প্রত্যাখ্যান করেছে, ফরওয়ার্ড প্রক্সি টানেল খুলতে অস্বীকার করেছে, অথবা প্রক্সি নিজের ক্রেডেনশিয়াল দাবি করেছে। এগুলোর প্রত্যেকটি ভিন্ন প্রশ্নের সঠিক উত্তর, আর সেগুলোকে একটি সাধারণ ব্যর্থতার পৃষ্ঠায় মিশিয়ে ফেললে আপনার কাছে থাকা একমাত্র প্রমাণটুকু নষ্ট হয়। যে উপাদান প্রত্যাখ্যানটি করেছে তার ভিত্তিতে এটি আলাদা করুন, তারপর প্রতিটি উপাদান আসলে যে নেটওয়ার্ক পথ ব্যবহার করে তা তুলনা করুন।
403 তৈরি করা উপাদানটির নাম দিন
HTTP স্ট্যাটাস কোড তার মালিক যে পাঠিয়েছে। যখন উৎস 403 ফেরত দেয়, তখন সে অনুরোধটি বিশ্লেষণ করে সিদ্ধান্ত নিয়েছে যে কলকারীর হয়তো সম্পদটি নেই, এটি পরিবহন সমস্যা নয় বরং অনুমোদনের উত্তর। যখন ফরওয়ার্ড প্রক্সি CONNECT-এ 403 উত্তর দেয়, তখন সে টানেল তৈরি করতে সম্পূর্ণ অস্বীকার করেছে এবং উজানে কাউকে কখনও যোগাযোগ করা হয়নি। যখন সে 407 উত্তর দেয়, তখন সে নিজের ক্রেডেনশিয়াল চায়, যার সঙ্গে অ্যাপ্লিকেশনের লগইনের কোনো সম্পর্ক নেই।
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 এই ভূমিকাগুলো সংজ্ঞায়িত করে, প্রক্সি-নির্দিষ্ট চ্যালেঞ্জসহ। মূল অংশ পড়ার আগে উত্তরটির নিজস্ব স্ট্যাটাস এবং যেকোনো Proxy-Authenticate হেডার পড়ুন, কারণ বন্ধুত্বপূর্ণ HTML ত্রুটি পৃষ্ঠা সাধারণত লুকিয়ে রাখে কোন উপাদানটি এটি লিখেছে।
CONNECT টানেল বাইট রিলে থেকে কী লুকায়
প্রক্সি CONNECT-এ 200 ফেরত দেওয়ার পর সে বাইট রিলে করে এবং ব্রাউজার উৎসের সঙ্গে নিজের TLS সেশন রাখে। তাই বাইট-রিলে করা প্রক্সি ওই সেশনের ভেতরের এনক্রিপ্ট করা 403 পড়তে পারে না, আর সে কখনও প্রত্যাখ্যানের লেখক হয় না। টানেল খোলার আগের প্রত্যাখ্যান সম্পূর্ণ ভিন্ন ঘটনা, যা এক স্তর নিচে তৈরি হয়।
TLS সমাপ্তকারী রিভার্স প্রক্সি ভিন্ন অবস্থানে: সে TLS সীমার মালিক, HTTP বিশ্লেষণ করে এবং বৈধভাবে উত্তর পুনর্লিখন বা আটকাতে পারে। এই সামর্থ্য কনফিগারেশনের পছন্দ, সাধারণভাবে প্রক্সির বৈশিষ্ট্য নয়, আর এটি অ্যাপ্লিকেশনের অ্যাক্সেস নীতি এড়ানোর অনুমতি দেয় না। উত্তর পড়া একটি সামর্থ্য; কলকারী কী দেখতে পাবে তা ঠিক করা উৎসের কাজই থাকে।
ব্যবহারিক ফল হলো, 403 ব্যাখ্যা করার আগে আপনাকে জানতে হবে আপনি তিনটি আকৃতির কোনটি চালান। স্ট্রিম প্রক্সিতে HTTP পরিদর্শনের নিয়ম যোগ করলে তাকে দৃশ্যমানতা মেলে না, আর বাইট রিলে থেকে উৎসের প্রত্যাখ্যান ব্যাখ্যা আশা করলে আপনাকে ভুল লগে খুঁজতে পাঠাবে।
প্রক্সির এগ্রেস পথ ব্রাউজারের টানেল ঠিকানার সঙ্গে তুলনা করুন
VPN-এ সংযুক্ত ব্রাউজার আলাদা একটি প্রক্সি সার্ভারকে স্বয়ংক্রিয়ভাবে ওই টানেলে সরায় না। উৎস প্রক্সির এগ্রেস ঠিকানা দেখে, আর প্রক্সি যদি এখনও স্থানীয় ডিফল্ট রুট দিয়ে বের হয়, তবে সুরক্ষিত সাইট এমন ঠিকানা দেখে যা তাকে কখনও বিশ্বাস করার জন্য কনফিগার করা হয়নি। ল্যাপটপের ভেতরের VPN ঠিকানা ওই উৎসের কাছে অদৃশ্য। কাজ করা টানেলও এমন সাইট থেকে 403 দেয় যেটি বাকি সবার জন্য ঠিক আচরণ করে—এটাই তার সবচেয়ে সাধারণ কারণ।
ঠিকানাগুলো যাতে গুলিয়ে না যায়, তাই দুটি পথ আলাদাভাবে পরীক্ষা করুন।
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateপ্রথম অনুরোধ দেখায় আপনার নিজের ঠিকানার জন্য উৎস কী উত্তর দেয়, দ্বিতীয়টি দেখায় প্রক্সির ঠিকানার জন্য সে কী উত্তর দেয়। মিলে যাওয়া জোড়া 403 উৎসের অনুমোদন নিয়মের দিকে ইঙ্গিত করে; 200-এর পরে 403 প্রক্সি পথের দিকে ইঙ্গিত করে। VPN পুল অন্তর্ভুক্ত ধরে নেওয়ার বদলে উৎসের মালিককে জিজ্ঞাসা করুন নিয়মের সেটটি আসলে কোন উৎস ঠিকানা গ্রহণ করে।
যে অনুরোধ সীমাটি আলাদা করে, তা দিয়ে প্রতিটি সীমা পরীক্ষা করুন
প্রক্সি স্তরটিকে আলাদা করুন তাকে এমন কিছু চেয়ে যা অ্যাপ্লিকেশনের কারণে সে প্রত্যাখ্যান করতে পারে না। প্রক্সির পৌঁছানোর অনুমতি আছে এমন হোস্টে CONNECT, আউটপুট ফেলে দিয়ে, আপনাকে জানায় টানেল প্রবেশ আদৌ কাজ করে কি না।
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
যদি এটি CONNECT-এর জন্য 200 এবং তারপর TLS হ্যান্ডশেক দেখায়, তবে প্রক্সি প্রবেশ ঠিক আছে এবং পরের 403 উৎস থেকে এসেছে। যদি 407 দেখায়, --proxy-user দিয়ে প্রক্সি ক্রেডেনশিয়াল দিন এবং সাইট সম্পর্কে কোনো সিদ্ধান্তে আসার আগে পুনরাবৃত্তি করুন। যদি CONNECT লাইনে 403 দেখায়, তবে প্রক্সির নিজের অনুমোদন তালিকাই পরীক্ষার সীমা, আর অ্যাপ্লিকেশন এতে জড়িত নয়।
ক্রেডেনশিয়াল শেল ইতিহাস এবং পেস্ট করা ট্রান্সক্রিপ্ট থেকে দূরে রাখুন। কমান্ড লাইনে টাইপ করা প্রক্সি পাসওয়ার্ড অন্য স্থানীয় ব্যবহারকারীদের কাছে দৃশ্যমান, আর ক্রেডেনশিয়ালসহ ধরা পড়া CONNECT ট্রেস কোনো ট্রেস না থাকার চেয়েও খারাপ।
পৃষ্ঠাটি পুনর্লিখনের বদলে রায়টি পাঠযোগ্য রাখুন
কোন উপাদান প্রত্যাখ্যান করেছে জানার পর সেই উত্তরটি সংরক্ষণ করুন। যে রিভার্স প্রক্সি উৎসের 403-কে 504 টাইমআউট হিসেবে নতুন নাম দেয়, বা সেটিকে সাফল্যের পৃষ্ঠা দিয়ে বদলায়, সে অনুমোদনের সিদ্ধান্তকে প্রাপ্যতার গল্পের আড়ালে লুকায় এবং পরবর্তী উত্তরদাতাকে ভুল দলে পাঠায়। কাস্টম ত্রুটি পৃষ্ঠা ঠিক আছে যখন সেগুলো স্ট্যাটাস রাখে ও প্রেক্ষাপট যোগ করে।
ক্যাশিংও একই যত্ন দাবি করে। RFC 9111 নিয়ন্ত্রণ করে শেয়ার্ড ক্যাশ কীভাবে উত্তর পুনরায় ব্যবহার করতে পারে, আর একজন কলকারীর জন্য তৈরি প্রত্যাখ্যানকে অনুমতি হিসেবে অন্যের হাতে দেওয়া যাবে না। প্রত্যাখ্যান উত্তর যদি আদৌ সংরক্ষণ করা হয়, সেগুলো ব্যক্তিগত ও সীমিত রাখুন, এবং শুধু উজানের ট্রাফিক কমাতে কখনও প্রকাশ্য সতেজতার নিয়ম যোগ করবেন না।
একটি লিখিত রায় দিয়ে শেষ করুন যা উপাদান, তার তৈরি স্ট্যাটাস এবং উৎস যে সোর্স ঠিকানা দেখেছে তা নাম দেয়। সঠিক অনুরোধ, বলবৎ প্রক্সি সেটিংস এবং সময় লিখে রাখুন, যাতে পরের প্রতিবেদনটি স্মৃতি থেকে নতুন করে বের না করে একই প্রমাণের সঙ্গে মেলানো যায়। সেই রেকর্ড পরের প্রতিবেদনের উত্তর সেকেন্ডে দেয় এবং একই 403-কে আবার VPN বিভ্রাট হিসেবে নির্ণয় করা থেকে থামায়।