ক্যাপচার টুল সারা সকাল কাজ করে, টানেল সংযুক্ত হয়, আর তারপর চুপ হয়ে যায়। সংযোগ বিচ্ছিন্ন করলেই আবার শুরু হয়। প্রথমে মনে হয় VPN প্রক্সিটা নষ্ট করেছে, কিন্তু প্রক্সি কনফিগারেশনে আসলে কিছুই বদলায়নি। বদলেছে অ্যাপ্লিকেশনগুলো এখন কোন কনফিগারেশন পড়ছে তা: একটি টানেল এন্ট্রি নিজের প্রক্সি সেটিংস বহন করতে পারে, একটি ম্যানেজড প্রোফাইল স্বয়ংক্রিয় কনফিগারেশন আবার চালু করতে পারে, আর কিছু রানটাইম অপারেটিং সিস্টেম যা দেয় তার কেবল একটি অংশ পড়ে। গ্লোবাল মানটি ধরার আগে প্রতি-সংযোগের মানটি পড়ুন।

Windows প্রতিটি সংযোগের জন্য আলাদা প্রক্সি রাখে

ইন্টারনেট অপশনসে দুটি স্তর আছে যেগুলো ডায়ালগে একই রকম দেখায়। লোকাল নেটওয়ার্ক সেটিংস সাধারণ লোকাল সংযোগে প্রযোজ্য, অন্যদিকে ডায়াল-আপ বা VPN এন্ট্রি HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections-এর অধীনে নিজের একটি কপি বাইনারি মান হিসেবে রাখে। চেনা গ্লোবাল রেজিস্ট্রি মান লিখলে সেই কপি আপডেট হয় না।

সংযোগের আগে টুল সঠিকভাবে আর সংযোগের পরে ভুলভাবে কাজ করলে ঠিক এভাবেই করে, অথচ তার সেটিংসে কোথাও দৃশ্যমান পরিবর্তন থাকে না। আপনি যে ডায়ালগের দিকে তাকিয়ে ছিলেন সেটি ছিল লোকাল নেটওয়ার্ক প্যানেল। সেটি সঠিক ছিল, আর অপ্রাসঙ্গিক ছিল। Windows আসলে যে এন্ট্রি ব্যবহার করছিল সেটি টানেলের জন্য তৈরি করা এন্ট্রি।

একটি এন্ট্রি বদলানোর সমর্থিত উপায় হলো WinINET connection option API: সংযোগের নাম, ফ্ল্যাগ, প্রক্সি সার্ভার ও বাইপাস তালিকা দিয়ে একটি INTERNET_PER_CONN_OPTION_LIST পূরণ করুন, প্রয়োগ করুন, তারপর রিফ্রেশ করুন। দ্রুত যাচাইয়ের জন্য টানেল এন্ট্রির নিজের সেটিংস ডায়ালগ খুলে তার প্রক্সি প্যানেল লোকাল নেটওয়ার্ক প্যানেলের সঙ্গে মিলিয়ে দেখুন; কোথায় দেখতে হবে জানলে পার্থক্যটা সাধারণত স্পষ্ট হয়।

ম্যানেজড PAC নিজেই আবার চালু হতে পারে

macOS-এ স্বয়ংক্রিয় প্রক্সি কনফিগারেশন স্ক্রিপ্ট ও প্রক্সি অটো-ডিসকভারি একটি নেটওয়ার্ক সার্ভিসের বৈশিষ্ট্য, মেশিনের নয়। একটি কনফিগারেশন প্রোফাইল এগুলো বাধ্যতামূলক করতে পারে, তাই টিক তুলে নেওয়ার পরও এগুলো ফিরে আসে, আর তখন প্রতিটি অনুরোধ স্ক্রিপ্ট যে প্রক্সি বেছে নেয় সেখানে যায়।

পরীক্ষা করুন এবং, অনুমোদিত হলে, ট্রাফিক বহনকারী সার্ভিসের জন্য ওই দুটি সুইচ বন্ধ করুন:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

অনুমান নয়, প্রকৃত সার্ভিসের নাম ব্যবহার করুন। ওয়াই-ফাই ও USB ইথারনেট অ্যাডাপ্টার দুটোই থাকা ল্যাপটপে এমন দুটি সার্ভিস থাকে, আর আপনার ট্রাফিক বহন করে কেবল একটি। scutil --proxy বর্তমান প্রাথমিক সার্ভিসের মানগুলো ছাপে। প্রোফাইল জিতেছে বলে সিদ্ধান্তে আসার আগে সেই আউটপুট আপনার সম্পাদিত মানের সঙ্গে মিলিয়ে দেখুন।

টুলকে আসল আপস্ট্রিমের দিকে পরিচালনা করুন

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

এই পদক্ষেপই আপনাকে পুনরায় কনফিগার করার বদলে ডিবাগিংয়ে রাখে।

প্রক্সিকে টানেলের ভেতরে ঠেলে দিন

OpenVPN-ভিত্তিক ক্লায়েন্ট টানেল ওঠার পর প্রযোজ্য প্রক্সি অপশন গ্রহণ করতে পারে, যা সুবিধাজনক যখন রুটগুলো ক্লায়েন্টের নিজের হাতে:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

কেবল যে ক্লায়েন্ট এই অপশন মানে তারাই এটি ব্যবহার করবে, আর এটি আপনার লিসেনিং পোর্ট প্রোফাইলে স্থায়ীভাবে বসিয়ে দেয়। এটিকে ডিপ্লয়মেন্ট মানদণ্ড নয়, ল্যাবের সুবিধা হিসেবে ধরুন, কারণ পরের প্রোফাইল পুশ এটা মুছে দেবে।

কিছু ক্লায়েন্ট সিস্টেম প্রক্সি কখনো পড়ে না

Firefox নিজের প্রক্সি সেটিংস রাখে, তাই সিস্টেম-প্রক্সি ব্যবহার করা ব্রাউজার না পারলেও এটি মাঝে মাঝে ক্যাপচার চালিয়ে যায়। স্বয়ংক্রিয় কনফিগারেশন বোঝে না এমন পুরোনো .NET ক্লায়েন্ট যেখানেই চলুক সরাসরি সংযোগ করে, তাই টানেল এন্ট্রি দিয়ে লোড হওয়া পেজও অ্যাপ্লিকেশনের ভেতরে ব্যর্থ হতে পারে।

নেটওয়ার্ক টুলেরও নিজস্ব কারণ থাকে। টানেল বা ফোন টেদারের উপর আটকে থাকা FTP সেশন প্রায়ই ক্লায়েন্টের আলোচিত অ্যাক্টিভ বনাম প্যাসিভ মোডের সমস্যা, আর কোনো প্রক্সি সেটিং তা বদলাবে না।

কনফিগারেশন পড়ুন, টগল নয়

এই ক্রমে কাজ করুন: টানেল এন্ট্রির নিজের প্রক্সি মান, প্রতি-সার্ভিস PAC ও অটো-ডিসকভারি অবস্থা, তারপর অ্যাপ্লিকেশনের নিজের প্রক্সি হ্যান্ডলিং। আপনার অনুমানের সঙ্গে প্রথম যেটি মেলে না সেখানেই থামুন।

এখানে প্রতিটি ঘটনাই কনফিগারেশন অগ্রাধিকারের সমস্যা। কোনোটিই টানেল আপনার টুল ভাঙছে না।

সম্পর্কিত নিবন্ধ