VPN কাজ করছে, কিন্তু একটি অ্যাপে ইন্টারনেট নেই? তার প্রক্সি দেখুন

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

কোন স্তর প্রক্সি সেটিংয়ের মালিক

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

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

প্রতিটি টুল আসলে যে মান ব্যবহার করে তা পড়ুন

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

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

আপনার সামনের প্ল্যাটফর্মের সাথে মেলে কেবল সেই লাইনটি চালান, তারপর হোস্ট, পোর্ট ও শংসাপত্রের জন্য আউটপুট পড়ুন। এমন একটি মান http://proxy.corp.example:8080 মানে টুলটি প্রতিটি অনুরোধের জন্য ওই হোস্টকে জিজ্ঞাসা করে, আর খালি ফলাফল মানে এটি সরাসরি যায় এবং আসল ত্রুটি অন্যত্র। টিকিটে আউটপুট পেস্ট করার আগে ব্যবহারকারী ও পাসওয়ার্ডের অংশটি ঢেকে দিন, কারণ ওই স্ট্রিংগুলো মানুষ যতটা ধরে নেয় তার চেয়ে অনেক বেশি জীবন্ত শংসাপত্র।

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

ওভাররাইড মুছে ফেলুন এবং একই অনুরোধ আবার পরীক্ষা করুন

একটি স্তর বদলান, তারপর যে অনুরোধটি ব্যর্থ হয়েছিল ঠিক সেটিই পুনরাবৃত্তি করুন, কারণ ভিন্ন URL কিছুই প্রমাণ করে না। বর্তমান শেলে এনভায়রনমেন্ট ভেরিয়েবলগুলো আগে মুছুন, কারণ এই সম্পাদনা প্রত্যাবর্তনযোগ্য এবং টানেল ভাঙতে পারে না:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

যদি ভার্বোস আউটপুট এখনও প্রক্সির দাবি করে, তাহলে এনভায়রনমেন্টই কর্তৃত্ব ছিল না। আরও ওভাররাইড স্তূপ না করে এক স্তর উপরে যান।

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

সমাধানটি রিস্টার্টের পরেও টেকে কি না যাচাই করুন

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

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

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

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