ইন্টারনেট কি শুধু VPN অ্যাপ চালু থাকলেই কাজ করে? চারটি স্তর দেখুন
Windows-এ একটি VPN অ্যাপ প্রক্সি, ভার্চুয়াল অ্যাডাপ্টার, রুট ও DNS পিছনে ফেলে যায়। প্রতিটির জন্য Linux ও macOS কমান্ডসহ চারটি স্তর ধাপে ধাপে যাচাই করুন।
এক সপ্তাহ একটি ফ্রি VPN ক্লায়েন্ট বা ব্রাউজার এক্সটেনশন চালিয়ে বন্ধ করলেন, আর ইন্টারনেট থেমে গেল। Wi-Fi আইকন এখনও সংযোগ দেখায়, একই রাউটারের অন্য ডিভাইসগুলো ঠিক আছে, আর ব্রাউজিং ফিরিয়ে আনে কেবল অ্যাপটি আবার চালু করা বা আনইনস্টল করা। এই ধরনটি নির্ভরতা তৈরি করা এনক্রিপশন নয়। এটি এমন কনফিগারেশন যা অ্যাপটি টানেলের মালিকানার বাইরে কোথাও লিখেছে।
ক্লায়েন্ট এমন সেটিংস বদলায় যা টানেলের নয়
Windows বা macOS-এ একটি প্রাইভেসি ক্লায়েন্ট সাধারণত একসাথে তিন জায়গায় হাত দেয়। এটি সিস্টেম HTTP প্রক্সি সেট করে, যেটি Internet Options-এ দেখানো একই ফিল্ড। প্যাকেট ধরার জন্য এটি একটি ভার্চুয়াল অ্যাডাপ্টার, প্রায়ই TAP ড্রাইভার, ইনস্টল করে। আর এটি রিজলভার তালিকা নতুন করে লেখে, অথচ ডিসকানেক্ট চাপলে কেবল টানেলটিই উধাও হয়।
ব্রাউজার এক্সটেনশন আরও সংকীর্ণ জিনিস। এটি সাধারণত নিজের প্রোফাইল বা একটি ব্রাউজার যে প্রক্সি অনুসরণ করে সেটি বদলায়। এজন্যই একটি ব্রাউজার ব্যর্থ হতে পারে অথচ কমান্ড-লাইন টুল চলতে থাকে, বা উল্টোটা: অন্য স্তরগুলোতে হাত দেওয়ার ক্ষমতা এক্সটেনশনের কখনও ছিল না। কোন স্তরটি বদলেছে সেটিই ঠিক করে কোন টুল ভাঙবে।
যেভাবেই হোক, বাসি সিদ্ধান্তটি নিয়েছিল এমন সফটওয়্যার যার তা ফেরানোর কোনো কারণ ছিল না। টানেল ছিল দৃশ্যমান অংশ, আর পরিষ্কার বন্ধ হওয়ার পথও কেবল তারই ছিল। বাকি সব এমন স্টোরের সেটিং যা প্রক্রিয়ার চেয়ে বেশি দিন টেকে, তাই অ্যাপটি সরানোই একমাত্র ধাপ যা তিনটিকেই একসাথে ফিরিয়ে দেয়। যেকোনো কিছু পুনরায় ইনস্টল করার আগে ওই স্টোরগুলো পড়াই উপসর্গকে নির্ণয়ে বদলায়।
তিনটি অবশিষ্টাংশ, তিনটি আলাদা ব্যর্থতা
প্রথম অবশিষ্টাংশ হলো এমন প্রক্সি যা কিছুই দেখায় না: LAN প্রক্সি বক্সটি এখনও টিক করা, বা কনফিগারেশন স্ক্রিপ্টের URL এমন localhost পোর্টে যেখানে আর কোনো প্রসেস শুনছে না। ব্রাউজার প্রতিটি অনুরোধ সেই মৃত পোর্টে পাঠিয়ে আটকে থাকে, যতক্ষণ না টাইমআউটটি মৃত নেটওয়ার্কের মতো দেখায়। দ্বিতীয়টি এমন অ্যাডাপ্টার যা এখনও ডিফল্ট রুটের মালিক, কারণ TAP-Windows ডিভাইস বা ভেন্ডরের রাউটিং ড্রাইভার আনইনস্টলের পরেও বাস্তব ইন্টারফেস থাকে। এটি যে রুট পেয়েছিল তা ধরে রাখে, আর ট্রাফিক এমন টানেলে হারিয়ে যায় যা নেই। কোনো অবশিষ্টাংশই নিজের কথা বলে না; দুটোই হুবহু বিভ্রাটের মতো দেখায়।
তৃতীয়টি DNS, আর এটি অন্য দুটির চেয়ে আগে ব্যর্থ হয়। যদি রিজলভার তালিকায় কেবল টানেল দিয়ে পৌঁছানো যায় এমন সার্ভার থাকে, তবে একটি পৃষ্ঠাও চাওয়ার আগেই প্রতিটি লুকআপ টাইমআউট হয়, তাই ব্রাউজার মৃত প্রক্সির বদলে অগম্য সাইট জানায়। আপনার যেটিই থাকুক, কোনোটিই নেটওয়ার্ক অর্থে বিভ্রাট নয়। প্রতিটি এমন অবশিষ্টাংশ যা কেউ বাতিল করেনি, আর প্রতিটি আলাদা জায়গায় সারানো হয়।
চারটি স্তর ধাপে ধাপে নামুন
অ্যাপ্লিকেশনের সবচেয়ে কাছ থেকে শুরু করে নিচে নামুন, কারণ স্তরগুলো দৃশ্যমানতার সেই ক্রমেই ব্যর্থ হয়। প্রতি পরীক্ষায় একটিমাত্র স্তর বদলান, আর প্রতিটির পরে আবার পরীক্ষা করুন। সবকিছু একসাথে রিসেট করলে সাধারণত ব্রাউজিং ফিরে আসে, আর কোন অবশিষ্টাংশ এর কারণ ছিল তা বলতে আপনি পারেন না, ফলে পরের ইনস্টল একই ধাঁধা তৈরি করে। ক্রম হলো প্রক্সি, অ্যাডাপ্টার, রুট, রিজলভার।
Windows-এ প্রতিটি যাচাই অপারেটিং সিস্টেমের সঙ্গে আসা একটি কমান্ড, তাই কিছু ইনস্টল করতে হয় না। এগুলো ক্রমে চালান এবং আউটপুট একসাথে রাখুন, কারণ চারটি উত্তর পাশাপাশি না হলে অর্থ বোঝা যায় না। এগুলো প্রক্সি, অ্যাডাপ্টার, IPv4 রুট ও রিজলভার তালিকা—এই ক্রমে জানায়:
netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress
Linux ও macOS-এর নিজস্ব কমান্ড দরকার, আর সেগুলো একে অন্যের বদল নয়। Linux-এ রুট আসে ip route থেকে আর রিজলভার resolvectl status থেকে যেখানে systemd-resolved এর মালিক, নইলে cat /etc/resolv.conf। macOS-এ রুট আসে netstat -rn থেকে, রিজলভার scutil --dns থেকে, আর সিস্টেম প্রক্সি scutil --proxy থেকে। যে macOS পাঠক ip route চালান তিনি command not found পান, আর সেখানকার /etc/resolv.conf কর্তৃত্বপূর্ণ কনফিগারেশন নয়, একটি উৎপন্ন স্টাব। স্তর দেখার আগে প্ল্যাটফর্ম দেখুন, নইলে প্রথম কমান্ডটিই ফলাফল হয়ে যায়।
প্রতিটি স্তরের জন্য একটি প্রশ্ন করুন: অ্যাপ বন্ধ থাকলেও এই মানটি কি এখনও এমন কিছু দেখায় যা বিদ্যমান? মৃত পোর্টের প্রক্সি, টানেলহীন অ্যাডাপ্টার, বন্ধ ইন্টারফেস দিয়ে ডিফল্ট রুট এবং টানেলের ভেতরের রিজলভার—সবগুলোর উত্তর না। যেকোনো একটি না-ই উপসর্গ ব্যাখ্যা করতে যথেষ্ট, এজন্যই প্রতি পরীক্ষায় একটি পরিবর্তন জরুরি।
প্রক্সি কোনো টানেল নয়
প্রক্সি অনুরোধ গ্রহণ করে, অন্যত্র এনে আনে, আর প্রতিক্রিয়া ফিরিয়ে দেয়, অর্থাৎ এটি গন্তব্য জানে এবং সাইট নিজে যা এনক্রিপ্ট করেনি তা দেখে। এটি অন্য প্রোটোকল বহন করে না। গন্তব্য আগে থেকেই TLS ব্যবহার না করলে এটি পথ রক্ষা করে না। আর যে এটি ইনস্টল করেছে সে আপনার অংশগ্রহণ ছাড়াই এটি বদলাতে পারে।
এই পার্থক্যই জিজ্ঞাসার যোগ্য প্রশ্নটি বদলে দেয়। প্রক্সি পিছনে থেকে গেলে টানেল উঠেছে কিনা নয়, বরং কোন প্রোগ্রাম এখনও আপনার ব্রাউজার চালাচ্ছে তা খুঁজে বের করুন। টানেল পুরোপুরি সুস্থ এবং ব্যর্থতার সঙ্গে সম্পূর্ণ অপ্রাসঙ্গিক হতে পারে।
এমন ক্লায়েন্ট আসলে কী করেছে জানতে চাইলে তার ড্যাশবোর্ড পড়ার বদলে তা পর্যবেক্ষণ করুন। Process Monitor রেকর্ড করে সে কোন রেজিস্ট্রি কী ও ফাইলে হাত দেয়, আর প্যাকেট ক্যাপচার দেখায় তার ট্রাফিক কোথায় গেছে। দুটোই সাধারণ টুল, আর দুটোই যেকোনো স্টেটাস লাইটের চেয়ে অবশিষ্টাংশের প্রশ্নের ভালো উত্তর দেয়। কোনোটিরই অ্যাপ চালু থাকা দরকার নেই।
উপাদান সরান, প্রমাণ নয়
টেকসই সমাধান হলো যে জিনিসটি সেটিং লিখেছে তা সরানো। অ্যাপ আনইনস্টল করুন, এটি যোগ করা ভার্চুয়াল অ্যাডাপ্টার মুছুন, প্রক্সি ও রিজলভার তালিকা পরিষ্কার করুন, তারপর রিবুট করে অ্যাপ আনইনস্টল থাকা অবস্থাতেই পরীক্ষা করুন। সেই মুহূর্তে ব্রাউজিং কাজ করলে আপনি সমাধান নয়, কারণ খুঁজে পেয়েছেন। কোন স্তরটি বাসি ছিল তা টুকে রাখুন, কারণ একই ভেন্ডর একই ভুল দুবার করতে ঝোঁকে।
পরের ক্লায়েন্ট ইনস্টল করার পর উপসর্গ ফিরে এলে সেবাটি কিছু ভেঙেছে বলে সিদ্ধান্ত নেওয়ার আগে আবার চারটি স্তর হাঁটুন। প্রমাণ সাধারণত তখনও চারটি জায়গার একটিতে থাকে। দ্বিতীয় অ্যাপ পঞ্চম স্তর তৈরি করে না; সে চারটির একটিই বদলায়।
পুনরায় ইনস্টল প্রক্সি রিসেট করে কিন্তু বাসি অ্যাডাপ্টার নয়, আর তালিকায় দুটি রিজলভার রেখে যেতে পারে। এই অসমতাই বলে দেয় কেন সব রিসেট বোতামের চেয়ে আনইনস্টল-তারপর-পরীক্ষা ভালো। এটি পরেরবার সংযোগ কাটলে তুলনার জন্য একটি ভিত্তিরেখাও দেয়।