Mac VPN ও PAC প্রক্সি: দুটি সিদ্ধান্ত, একটি সেটিং নয়

আপনার Mac একটি নীতি স্ক্রিপ্ট ডাউনলোড করে, তারপর সেই স্ক্রিপ্টকে জিজ্ঞাসা করে কোন অনুরোধ কোন মধ্যস্থ ব্যবহার করবে, আর টানেল কেবল ঠিক করে নির্বাচিত হপে কীভাবে পৌঁছানো হবে। দুটি উত্তরই একই সকেটে পৌঁছায়, তাই দুটিই সফল হওয়ার পরেও যে অনুরোধ ব্যর্থ হয়, সেটি দুটি ত্রুটি হলেও একটির মতো দেখায়। ডাউনলোডকে নির্বাচন থেকে এবং নির্বাচনকে রুট থেকে আলাদা করাই এই টিকিটগুলোর বেশিরভাগ কাজ। নিচের ক্রমটি macOS আসলে যা করে তা অনুসরণ করে, সাথে সেই পরীক্ষাগুলো যা প্রতিটি ধাপ দৃশ্যমান করে।

যেখানে PAC ঠিকানা ও প্রক্সি আলাদা হয়

https://config.corp.example/proxy.pac-এর মতো ঠিকানা ডাউনলোড করার একটি নথির নাম দেয়, আর সেই নথি ট্রাফিক পাঠানোর জন্য একটি সার্ভারের নাম দেয়। প্রক্সি হোস্টের ঘরে URL পেস্ট করলে ক্লায়েন্টকে এমন একটি ফাইল সার্ভারের সঙ্গে প্রক্সি সংযোগ খুলতে বলা হয়, যা কখনোই এমন সংযোগ শোনে না। ফাইলের ভিতরে একটি ফাংশন আছে যা ক্লায়েন্ট প্রতি অনুরোধে ডাকে, আর তার ফেরত মান ওই একক গন্তব্যের পরবর্তী হপ। এই পরোক্ষতা ব্যাখ্যা করে কেন একই নেটওয়ার্ক সেবায় দুটি মেশিনের আচরণ আলাদা হতে পারে, যদিও দুটিতেই সঠিক URL আছে। এটি আরও ব্যাখ্যা করে কেন প্রক্সি নিজে না ছুঁয়েও নীতি পরিবর্তন কার্যকর হয়।

আগে স্ক্রিপ্টটি পড়ুন, তারপর নিচের দিকের কিছু ব্যাখ্যা করুন, কারণ এর ভিতরের নিয়মগুলো প্রতিষ্ঠানের ব্যতিক্রম ও সেগুলো প্রয়োগের ক্রম বহন করে। আগের একটি বিস্তৃত পরিসর পরের অভ্যন্তরীণ সাফিক্সকে ঢেকে দিতে পারে, আর যে হোস্টের স্পষ্টতই প্রক্সি এড়ানো উচিত সে-ই এটি ব্যবহার করে চলতে থাকে। যখন কেউ জোর দেয় যে নীতিটি ভুল, তখন স্ক্রিপ্টই একমাত্র জায়গা যেখানে সেই দাবির নিষ্পত্তি হয়।

যেকোনো সিদ্ধান্তের আগে স্ক্রিপ্টটি আনতে হবে

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

নিচের তিনটি পরীক্ষা ক্রমে চালান এবং প্রথম ব্যর্থতায় থামুন, কারণ ধাপগুলোর কারণ এক নয়। একসাথে তারা দেখায় নীতিটি কনফিগার করা আছে কি না, এটি পৌঁছানো যায় কি না এবং এটি কী ফেরত দেয়।

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

প্রথম কমান্ডটি সক্রিয় সেবার প্রক্সি ডিকশনারি ছাপায়, সিস্টেম যে অটো-কনফিগারেশন URL ধরে রাখে সেটিসহ। দ্বিতীয়টি একটি নামকৃত সেবায় সংযুক্ত URL জানায়, যা Wi-Fi ও Ethernet-এর মধ্যে চলাচলকারী ল্যাপটপে গুরুত্বপূর্ণ। তৃতীয়টি ফাইলটি রেন্ডার না করেই আনে, তাই 404, টাইমআউট ও রিজলভার ব্যর্থতা আলাদা করা যায়। যদি শেষ কমান্ডটি স্ক্রিপ্ট ফেরত দেয় অথচ অ্যাপ্লিকেশনগুলো এখনো ব্যর্থ হয়, সমস্যা ইতিমধ্যে আনার বাইরে চলে গেছে।

DIRECT উত্তর আসলে কী বাদ দেয়

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

DIRECT-কে VPN-এর বাইরে ভাবা সেই ভুল, যা মানুষকে ভুল সেটিংস প্যানেলে পাঠায়। উল্টো চিত্রটিও সমান সাধারণ, কারণ একটি প্রাইভেট প্রক্সি বিভক্ত রুটে পৌঁছানো যায়, আর মেশিনের বাকি অংশ টানেলের বাইরে থাকে। তখন গন্তব্য যা জানায় তা প্রক্সির নিজের প্রস্থানের, যা অন্য দেশে থাকতে পারে। একটি অভ্যন্তরীণ হোস্ট ও একটি পাবলিক হোস্টের জন্য প্রত্যাশা লিখে রাখলে এটি দ্রুত ধরা পড়ে, কারণ স্ক্রিপ্ট প্রায়ই দুটিকে ভিন্নভাবে উত্তর দেয়। কোন হপ ঠিকানাটি তৈরি করেছে তা জানলে রিপোর্ট আর রহস্যময় থাকে না।

তিনটি ব্যর্থতা যা একটি ত্রুটি পৃষ্ঠা হিসেবে দেখা দেয়

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

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

প্রক্সিতে সম্পূর্ণ সংযোগ প্রশ্নটিকে প্রমাণীকরণে বা প্রক্সির নিজের নীতিতে সরিয়ে দেয়, যার মালিক আলাদা। পথে প্রক্সি ছাড়া অভ্যন্তরীণ হোস্টে সম্পূর্ণ সংযোগ রুটটিকে বাদ দেয় এবং নীতির দিকে ইশারা করে। দুটি কমান্ডই macOS প্রক্সি ডিকশনারি উপেক্ষা করে, যদি না শেল প্রক্সি ভেরিয়েবল এক্সপোর্ট করে, তাই আগে সেগুলো পরিষ্কার করুন। কোনো প্রোবই অন্যটিকে প্রমাণ করে না, তাই একটি ত্রুটি পৃষ্ঠা এতক্ষণ বিভ্রান্ত করে।

টিকিটের সাথে কী হস্তান্তর করবেন

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

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