হোটেলের Wi-Fi-তে OpenVPN সংযোগ করছে না? TCP 443 ব্যবহার করুন
বাড়িতে কাজ করে কিন্তু হোটেল বা ক্যাম্পাসের Wi-Fi-তে আটকে যায় এমন প্রোফাইল তার ট্রান্সপোর্ট হারায়। ব্লকটা প্রমাণ করুন, লিসেনারকে TCP 443-এ নিন এবং খরচটা জানুন।
ক্লায়েন্ট খুলুন, Connect চাপুন এবং তার পরে আসা ডায়ালগের বদলে স্টেটাস লাইনটি পড়ুন। হোটেল, ক্যাম্পাস বা মোবাইল নেটওয়ার্কের পরে Connecting বা Waiting for server-এ আটকে থাকা প্রোফাইল সাধারণত পথের কোথাও তার ট্রান্সপোর্ট হারিয়েছে, তার ক্রেডেনশিয়াল নয়। পরের কাজটি হলো সার্ভার স্পর্শ করার আগে ওই নেটওয়ার্ক কী বহন করে তা জানা। একই প্রোফাইল অন্য কোথাও কাজ না করা পর্যন্ত কিছুই বদলাবেন না।
প্রথমে ফোনের হটস্পট থেকে পরীক্ষা করুন। সেখানে টানেল উঠলে সার্ভার, সার্টিফিকেট আর অ্যাকাউন্ট সবই ঠিক, আর বাকি একমাত্র চলক হলো আপনার সামনের নেটওয়ার্ক।
ক্লায়েন্ট থেকে শুরু করুন: স্টেটাস লাইন পড়ুন
স্টেটাস লাইন বলে দেয় কোন ধাপে ব্যর্থ হয়েছে। Connecting-এ আটকে থাকা ক্লায়েন্ট এখনো হোস্ট রিজলভ করছে বা বাইরের সকেট খুলছে; যে Waiting for server-এ পৌঁছায় তার পথ আছে কিন্তু উত্তর নেই; যে প্রমাণীকরণ করে তারপর পড়ে যায় তার সমস্যা সম্পূর্ণ আলাদা। ক্লায়েন্ট লগ এবং প্রোফাইলের নিজের remote ও proto ফিল্ড দেখায় ক্লায়েন্ট কী করতে চাইছে, আর কমান্ড-লাইন ক্লায়েন্টে --verb 4 একই বিবরণ ছাপে। আপনার সামনের নেটওয়ার্কের সঙ্গে তা মিলিয়ে দেখাই «VPN ব্লকড» কথাটিকে একটি নির্দিষ্ট দাবিতে বদলে দেয়।
তারপর যে যন্ত্রপাতি ইতিমধ্যেই আছে তা দিয়ে নেটওয়ার্ক পরীক্ষা করুন। nc -vzu 203.0.113.10 1194 একটি UDP ডেটাগ্রাম পাঠায়, curl -v telnet://203.0.113.10:443 জানায় TCP হ্যান্ডশেক সম্পূর্ণ হয় কি না, আর HTTPS পেজ লোড করা ব্রাউজার কেবল প্রমাণ করে যে আউটবাউন্ড 443 ওই একটি হোস্টেই পৌঁছায়। ছোট পরীক্ষা সেই প্রশ্নের উত্তর দেয় যা VPN ক্লায়েন্ট দিতে পারে না: কোন পোর্ট ও প্রোটোকল আদৌ এই নেটওয়ার্ক ছাড়ে।
তিনটি নেটওয়ার্ক আচরণ ক্লায়েন্টের দিক থেকে একই রকম দেখায় এবং ভিন্ন উত্তর দাবি করে। আউটবাউন্ড 443 খোলা থাকতে পারে, কেবল একটি প্রক্সি অনুমোদিত হতে পারে, অথবা 443 স্বচ্ছভাবে এমন একটি ইন্সপেকশন বক্সে পাঠানো হতে পারে যা এটি কী বহন করে তা পড়তে পারে না। প্রথমটি নিচের প্রোফাইল পরিবর্তনে সারানো যায়, দ্বিতীয়টি প্রক্সি সেটিংসে, আর তৃতীয়টি হ্যান্ডশেক সম্পূর্ণ করে তারপর আটকে যেতে পারে যখন ইন্সপেক্টর সিদ্ধান্ত নেয় স্ট্রিমটি তার পছন্দ নয়। কোনটির মুখোমুখি আপনি তা জানাই দশ মিনিটের পরিবর্তন আর ক্লায়েন্ট পুনঃইনস্টল করে কাটানো এক বিকেলের মধ্যে পার্থক্য।
লিসেনার ও প্রোফাইল একসঙ্গে সরান
সার্ভারের দিকে লিসেনারকে নেটওয়ার্ক যা অনুমোদন করে তাতে সেট করুন: সার্ভার কনফিগারেশনে port 443 ও proto tcp, তারপর সার্ভিসটি রিস্টার্ট করুন এবং ss -lntp দিয়ে সকেট নিশ্চিত করুন। ক্লায়েন্টের দিকে প্রোফাইলকে একমত হতে হবে, কারণ ট্রান্সপোর্ট ও পোর্ট টানেলের বাইরে থাকে: .ovpn-এ proto tcp ও port 443, অথবা অ্যাপের সেটিংস স্ক্রিনের সংশ্লিষ্ট ফিল্ড। এখনো UDP 1194-এ লক্ষ্য করা প্রোফাইল আগের মতোই ব্যর্থ হয়, আর প্রলোভন হলো ইতিমধ্যেই সারানো একটি ফায়ারওয়ালকে দোষ দেওয়া। একই হোস্ট যদি 443-এ HTTPS-ও উত্তর দেয়, তবে দুই লিসেনার ওই ঠিকানা ও প্রোটোকল ভাগ করতে পারে না; VPN-কে একটি দ্বিতীয় ঠিকানা দিন বা সামনে একটি ডিমাল্টিপ্লেক্সার বসান।
দুই প্রান্তে tcpdump -ni any port 443 দিয়ে প্রথম সংযোগটি অনুসরণ করুন। যে প্যাকেট ক্লায়েন্ট ছেড়ে কখনো পৌঁছায় না তার মানে নেটওয়ার্ক শেষ পর্যন্ত ফিল্টার করছে, অথবা প্রোফাইলের ঠিকানাটি আপনার অনুমানের মতো নয়। উত্তর ছাড়া আসা প্যাকেট আপনাকে সার্ভার লগে ফেরত পাঠায়, যেখানে প্রোটোকল মিল না থাকা সঙ্গে সঙ্গে বাদ পড়া প্যাকেট হিসেবে দেখা যায়।
যখন নেটওয়ার্ক থেকে কেবল প্রক্সি বেরোয়
কিছু গেস্ট নেটওয়ার্ক HTTP প্রক্সি ছাড়া কিছুই অনুমোদন করে না, যা বন্ধ পোর্টের চেয়ে আলাদা এক বাধা এবং OpenVPN-এর চেয়েও বেশি কিছু বাদ দেয়। যে ক্লায়েন্ট কেবল PPTP, L2TP/IPsec বা নিছক IPsec বলে, তাদের এটি ভেদ করার উপায় নেই, কারণ ওই ডিজাইনগুলো ধরে নেয় তাদের বাইরের প্রোটোকল সরাসরি সার্ভারে পৌঁছাবে। OpenVPN পারে, ক্লায়েন্ট প্রোফাইলে http-proxy proxy.example.net 8080 দিয়ে, যদি প্রক্সি আপনার পোর্টে CONNECT পদ্ধতি অনুমোদন করে। SOCKS প্রক্সি আরও সহজ, কারণ এটি ভেতরে কী আছে তা গ্রাহ্য না করেই স্ট্রিমটি পাঠিয়ে দেয়।
যেখানে ক্লায়েন্টে প্রক্সি সমর্থন নেই, সেখানে 443-এর ওপর SSH টানেল সাধারণত যা অবশিষ্ট থাকে। এটি একটি দ্বিতীয় স্তর যোগ করে, আর নেটওয়ার্কের অপারেটরের এ নিয়ে মতামত থাকতে পারে, তাই এটিকে স্থাপত্য নয়, এক ভ্রমণের সেতু হিসেবে দেখুন।
বিকল্পটি রাখার আগে তার দাম হিসাব করুন
TCP-এর ভেতরে TCP-এর একটি জানা দাম আছে। যখন বাইরের সংযোগ TCP এবং পেলোডও TCP, তখন হারানো সেগমেন্ট দুই স্তরেই পুনঃপ্রেরণ ঘটায়, আর ভেতরের সংযোগ এমন ক্ষতি থেকে পিছিয়ে যায় যা সে দেখতে পায় না। ব্রাউজিং তা টিকে যায়; ইন্টারঅ্যাকটিভ সেশন ও কল তা অনুভব করে। TCP 443 লিসেনারকে যেসব নেটওয়ার্ক তা দাবি করে তাদের জন্য বিকল্প হিসেবে রাখুন, আর যা এখনো UDP পাস করে তার জন্য UDP-কে ডিফল্ট রাখুন।
প্রোফাইলের নামে ও সাপোর্ট নোটে পছন্দটি লিখে রাখুন: কোন পোর্ট, কোন প্রোটোকল এবং কোন নেটওয়ার্ক তা ঘটিয়েছে। তারপর নেটওয়ার্কের প্রশাসককে জিজ্ঞাসা করুন পরবর্তী যন্ত্রপাতি নবায়নের পরেও ওই পোর্ট খোলা থাকবে কি না, কারণ নিঃশব্দে হারিয়ে যাওয়া বিকল্প কোনো বিকল্প না থাকার চেয়েও খারাপ।