কেন হোস্টের URL দিয়ে গেস্ট ভার্চুয়াল মেশিনে PAC প্রক্সি ব্যর্থ হয়

«হোস্ট এই PAC ফাইলটি ব্যবহার করে, তাই আমি VM-এ একই URL দিয়েছি» একটি যুক্তিসঙ্গত বাক্য এবং একটি অসম্পূর্ণ পরিকল্পনা। একটি PAC URL প্রক্সির দিকে নয়, একটি নীতি স্ক্রিপ্টের দিকে নির্দেশ করে। যতক্ষণ না গেস্ট সেই স্ক্রিপ্ট আনতে, নিজের ঠিকানা দিয়ে মূল্যায়ন করতে এবং স্ক্রিপ্ট যে প্রক্সির নাম দেয় সেখানে পৌঁছাতে পারে, ততক্ষণ URL কেবল একটি সেটিংস ফিল্ডের স্ট্রিং। ভার্চুয়াল মেশিনে প্রক্সি নীতির চারপাশের বেশিরভাগ বিভ্রান্তি আসে ওই এক লাইনকেই সম্পূর্ণ কনফিগারেশন ভেবে নেওয়া থেকে।

PAC URL একটি স্ক্রিপ্ট, প্রক্সি নয়

ফাইলটিতে একটি ফাংশন আছে যা একটি URL ও একটি হোস্ট নেয় এবং প্রক্সির বর্ণনা বা DIRECT শব্দটি ফেরত দেয়। URL-এ এমন কিছু নেই যা অ্যাপ্লিকেশনকে বলে ট্রাফিক কোথায় পাঠাতে হবে; ওই সিদ্ধান্ত রানটাইমে, স্ক্রিপ্টের ভেতরে, স্ক্রিপ্ট প্ল্যাটফর্মের কাছে যে তথ্য চায় তা দিয়ে নেওয়া হয়। PAC URL গ্রহণ করা একটি সেটিংস ডায়ালগ আসলে একটি সিদ্ধান্ত পদ্ধতির দিকে পয়েন্টার গ্রহণ করে।

এই পার্থক্যই ব্যাখ্যা করে কেন URL কপি করা কাজ হয়েছে বলে মনে হতে পারে। ফিল্ড পূর্ণ হয়, সেটিং সংরক্ষিত হয়, আর ব্যর্থতা দেখা যায় কেবল পরে, যখন স্ক্রিপ্ট আনা যায় না বা স্ক্রিপ্ট এমন প্রক্সি ফেরত দেয় যেখানে গেস্ট পৌঁছাতে পারে না।

চারটি ধাপ প্রতিটি ভিন্নভাবে ব্যর্থ হয়

গেস্টের ভেতরে চারটি কাজ ক্রমে ঘটতে হবে, আর প্রতিটির নিজস্ব ত্রুটি-চিহ্ন আছে। গেস্ট PAC ফাইলটি আনে। অ্যাপ্লিকেশন স্থানীয় তথ্য দিয়ে অনুরোধ করা URL-এর জন্য স্ক্রিপ্টটি মূল্যায়ন করে। নির্বাচিত প্রক্সি রিজলভ করা হয় এবং সেখানে পৌঁছানো হয়। প্রক্সি চাইলে প্রমাণীকরণ ঘটে।

আনাটাই প্রমাণ করে শুরু করুন, কারণ তা ছাড়া পরের সব কিছু অর্থহীন। ব্যক্তিগত সার্ভারে থাকা PAC ফাইলের জন্য যেকোনো নিয়ম সাহায্য করার আগেই সেই সার্ভারে অনুমোদিত পথ দরকার, আর অগম্য স্ক্রিপ্টের ভেতরের প্রক্সি-নির্বাচন সেই পথ তৈরি করতে পারে না যা এটি আনবে:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

যদি ওই অনুরোধ গেস্ট থেকে ব্যর্থ হয় এবং হোস্ট থেকে কাজ করে, তবে সমস্যা স্ক্রিপ্টের বিষয়বস্তুতে নয়, গেস্টের PAC সার্ভারের পথে। যদি এটি একটি JavaScript ফাইল ফেরত দেয়, তবে দ্বিতীয় ধাপে যান এবং স্ক্রিপ্ট গেস্টের প্রসঙ্গে কী সিদ্ধান্ত নেয় তা খুঁজে বের করুন।

একই স্ক্রিপ্ট VM-এর ভেতরে ভিন্নভাবে সিদ্ধান্ত নেয়

PAC ফাংশন অনুরোধ করা হোস্ট এবং মূল্যায়ন চালানো মেশিনের তথ্য পরীক্ষা করতে পারে। ক্লায়েন্টের নিজের ঠিকানার উপর গড়া নিয়ম, যেমন কোনো ইন্টারফেস ঠিকানা বা সাবনেট সদস্যতা পরীক্ষা, ভৌত হোস্টের নয়, গেস্টের ঠিকানা দেখবে। হোস্ট-সাইড NAT-এর পিছনে এগুলো ভিন্ন ঠিকানা, তাই একই স্ক্রিপ্ট VM-এর ভেতরে ভিন্ন প্রক্সি বেছে নিতে বা DIRECT-এ ফিরে যেতে পারে।

এটি স্ক্রিপ্টের ত্রুটি নয়। স্ক্রিপ্ট ভিন্ন ইনপুট দিয়ে ঠিক যা করার জন্য লেখা হয়েছিল তাই করছে, এবং এটিই সেই বিভ্রান্তিকর রিপোর্ট ব্যাখ্যা করে যেখানে হোস্ট প্রক্সি ব্যবহার করে আর গেস্ট সরাসরি সংযুক্ত হয়। সিদ্ধান্তটি নিয়ে অনুমান না করে পুনরুৎপাদন করুন: ঠিকানা ও URL নেওয়া একটি PAC মূল্যায়ক, যদি আপনার ডিস্ট্রিবিউশনে থাকে, এক কমান্ডেই প্রশ্নের মীমাংসা করে। নাহলে যে অ্যাপ্লিকেশনটি সত্যিই ব্যবহার হবে সেটি দিয়েই পরীক্ষা করুন, এবং অনুমান না করে তার প্রক্সি লগ পড়ুন।

এই সিদ্ধান্তে পৌঁছাবেন না যে গেস্ট হোস্টের প্রক্সি সেটিংস উত্তরাধিকারে পেয়েছে কারণ তার ট্রাফিক হোস্ট-সাইড অনুবাদের মধ্য দিয়ে যায়। নেটওয়ার্ক অনুবাদ প্যাকেট এগিয়ে দেয়; এটি অ্যাপ্লিকেশন কনফিগারেশন কপি করে না, আর সিস্টেম প্রক্সি হলো অ্যাপ্লিকেশন কনফিগারেশন।

যে টুলগুলো PAC পড়েই না

কমান্ড-লাইন টুল আলাদা সীমা, আর এখানেই অনেক সময় নষ্ট হয়। curl PAC ফাইল চালায় না, যেমনটি তার প্রক্সি ডকুমেন্টেশন স্পষ্ট বলে। PAC ডাউনলোড URL-এ প্রক্সি ভেরিয়েবল নির্দেশ করলে স্ক্রিপ্ট প্রক্সি এন্ডপয়েন্ট হয়ে যায় না; টুলটি একটি JavaScript ফাইলের সাথে HTTP বলার চেষ্টা করবে এবং নেটওয়ার্ক সমস্যার মতো দেখতে ব্যর্থতা পাবে।

একই কথা প্রযোজ্য অনেক প্যাকেজ ম্যানেজার, ভাষার রানটাইম ও বিল্ড টুলের ক্ষেত্রে, যারা কেবল স্পষ্ট প্রক্সি ভেরিয়েবল বা নিজেদের কনফিগারেশন মানে। যদি আপনার দরকারের পরীক্ষাটি CLI টুল হয়, তবে PAC স্ক্রিপ্ট যে নির্দিষ্ট প্রক্সি বেছে নিত সেটি দিয়ে সেটিকে কনফিগার করুন, এবং এই বেছে নেওয়া কীভাবে করলেন তা লিখে রাখুন যাতে পরের ব্যক্তি তা পুনরাবৃত্তি করতে পারেন।

Linux-এ ডেস্কটপ অ্যাপ্লিকেশনের জন্য সিস্টেম সেটিংকে স্বয়ংক্রিয় মোডে বসাতে হবে এবং একটি URL দিতে হবে; মোড এখনো ম্যানুয়াল থাকা অবস্থায় সংরক্ষিত URL কিছুই করে না। দুটোই পরীক্ষা করুন, এবং গেস্টের ভেতরে পরীক্ষা করুন:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT-ও একটি সিদ্ধান্ত

PAC ফলাফল DIRECT মানে অ্যাপ্লিকেশন HTTP প্রক্সি এড়িয়ে যায়, এই নয় যে সে নেটওয়ার্ক থেকে পালিয়েছে। ফলাফল সংযোগটি এখনো অপারেটিং সিস্টেমের রুট অনুসরণ করে টানেলের মধ্য দিয়ে যেতে পারে, বা প্রক্সি ব্যবহারের সাথে সম্পর্কহীন কারণে ব্যর্থ হতে পারে। উল্টোদিকে, প্রক্সি ফলাফল একটি অ্যাপ্লিকেশনের অনুরোধ বর্ণনা করে, গেস্টের প্রতিটি প্রসেস নয়।

তাই যে দিকে প্রয়োজনটি লেখা হয়েছে সেই দিকে যাচাই করুন। যদি প্রয়োজন হয় «এই অ্যাপ্লিকেশনটি অভ্যন্তরীণ সাইটে পৌঁছায়», তবে প্রমাণ করুন যে ওই অ্যাপ্লিকেশন পৌঁছায়, এবং কোন প্রক্সি বা রুট এটি বহন করেছে তা লিখুন। যদি প্রয়োজন হয় «VM কর্পোরেট নেটওয়ার্কে আছে», তবে নির্বাচিত প্রক্সির মধ্য দিয়ে কাজ করা ব্রাউজার ওই ব্রাউজারের পক্ষে প্রমাণ, তার বেশি কিছু নয়।

পরীক্ষা পাস করানোর জন্য হোস্টের টানেল বন্ধ করা বা ফরওয়ার্ডিং নীতি শিথিল করার বদলে গেস্টের ভেতরে শৃঙ্খলটি ঠিক করুন। শৃঙ্খলটির চারটি লিঙ্ক, আর যেকোনো একটি বাদ দেওয়া পরিবর্তন পরেরবার স্ক্রিপ্ট আপডেট হওয়া বা গেস্টের ঠিকানা বদলানো পর্যন্ত টিকে থাকবে।