হোটেলের Wi-Fi: সার্ভারে পৌঁছানোর আগেই VPN ব্যর্থ হয়

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

মিথ: হোটেল VPN ব্লক করে

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

এখানে টানেল দুর্বল নির্ণায়ক, কারণ পোর্টাল অনুমোদিত না থাকলে ব্যর্থ হওয়া একমাত্র নিশ্চিত অ্যাপ্লিকেশন এটি। সাধারণ ওয়েব অ্যাক্সেস ভালো সূচক, কারণ এটি আপনাকে সাইন ইন পাতা নিজেই দেখাতে পারে।

এই ক্রমটি আরেকটি কারণে গুরুত্বপূর্ণ: কিল সুইচ বা সর্বদা-চালু মোডযুক্ত ক্লায়েন্ট পোর্টাল লোড হতে দেবে না, আর ব্যবহারকারী সেটিং নয়, নেটওয়ার্ক ভাঙা বলে সিদ্ধান্তে আসে। দুটি তথ্যই একসঙ্গে সত্য, আর হোটেলে বদলানো যায় কেবল একটিকে। ক্লায়েন্টের নিজস্ব নিয়ন্ত্রণ দিয়ে সুরক্ষা বন্ধ করুন, সাইন ইন করুন, তারপর আবার চালু করুন। অন্য সব কিছু আসল ক্রমটি লুকানো একটি ঘুরপথ।

আগে পোর্টাল শেষ করুন, তারপর সাধারণ HTTPS পরীক্ষা করুন

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

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

প্রথম অনুরোধটি সাধারণ HTTP-তে একটি পরিচিত ক্যাপটিভ পোর্টাল সনাক্তকরণ এন্ডপয়েন্টকে জিজ্ঞাসা করে; রিডাইরেক্ট বা অপ্রত্যাশিত বিষয়বস্তু মানে আপনি এখনও পোর্টালের পেছনে। দ্বিতীয়টি একটি সাধারণ HTTPS সাইট পরীক্ষা করে। যদি প্রথমটি হস্তক্ষেপ দেখায় আর দ্বিতীয়টি ব্যর্থ হয়, তবে সাইন ইন অসম্পূর্ণ এবং VPN-এর সঙ্গে এর কোনো সম্পর্ক নেই।

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

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

আসল প্রোফাইল ও তার ত্রুটি সংরক্ষণ করুন

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

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

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

কেবল অপারেটরের দেওয়া বিকল্প ব্যবহার করুন

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

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

প্রদত্ত প্রোফাইল বেশি বিস্তারিত মাত্রায় চালালে প্রথম উপযোগী ত্রুটি সাধারণ ব্যর্থতার ডায়ালগে মিলিয়ে যাওয়ার বদলে দৃশ্যমান থাকে। পোর্ট বা প্রোটোকল নিজে সম্পাদনা না করে অপারেটরের দেওয়া ফাইল ব্যবহার করুন, কারণ স্থানীয় পরিবর্তন অপর প্রান্তে মিলে যাওয়া শ্রোতা তৈরি করতে পারে না।

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

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