কেন একটি OpenVPN প্রোফাইল বাড়িতে কাজ করে কিন্তু হোটেলে ব্যর্থ হয়

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

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

চারটি নেটওয়ার্ক সত্য লোকেশন বদলালে বদলে যায়

প্রথম সত্যটি হলো স্থানীয় নেটওয়ার্ক আপনাকে আদৌ বের হতে দেয় কি না। একটি ক্যাপটিভ পোর্টাল ডিভাইসটিকে একটি লগইন পাতায় ঢুকিয়ে বাকি সবকিছু আটকে রাখে যতক্ষণ না সেই পাতা সম্পূর্ণ হয়, অর্থাৎ প্রোফাইল যতই সঠিক হোক টানেল শুরু হতে পারে না।

দ্বিতীয়টি নাম রেজলিউশন। যে পোর্টাল DNS আটকায় সে প্রতিটি কোয়েরির উত্তর নিজের ঠিকানা দিয়ে দেয়, ফলে VPN হোস্টনেম পোর্টালে রিজলভ হয় এবং ক্লায়েন্ট একটি ওয়েব পাতায় টানেল বানাতে চেষ্টা করে।

তৃতীয়টি ট্রান্সপোর্ট ফিল্টারিং। যে নেটওয়ার্ক কেবল ব্রাউজিং অনুমোদন করতে চায় তারা TCP 443 যেকোনো গন্তব্যে যেতে দেয় এবং প্রায় বাকি সবকিছু, UDP সহ, ফেলে দেয়।

চতুর্থটি অ্যাড্রেসিং। স্থানীয় সাবনেট টানেলের পেছনের নেটওয়ার্কের সঙ্গে ওভারল্যাপ করতে পারে, অথবা আপলিংক আদৌ কোনো ব্যবহারযোগ্য IPv4 পথ দিতে পারে না।

রেজলিউশন ও ক্যাপটিভ পোর্টাল

প্রোফাইলের হোস্টনেমটি সার্ভারের সংখ্যাসূচক ঠিকানা দিয়ে বদলে আবার চেষ্টা করুন। যদি IP সংযোগ করে কিন্তু নাম না করে, তবে দোষ রেজলিউশনের, আর প্রোফাইল নিজেই ঠিক আছে।

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

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

ট্রান্সপোর্ট ফিল্টারিং: আগে UDP, ব্যাকআপ হিসেবে TCP 443

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

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

কর্মক্ষমতার খরচ আশা করুন। TCP-র ভেতরে TCP ক্ষতিপূর্ণ লিংকে পুনঃপ্রেরণ বাড়ায়, তাই কাজ করা TCP টানেলও ভিড়যুক্ত হোটেল নেটওয়ার্কে ধীর লাগতে পারে। এটি পৌঁছানোর বিনিময়ে একটি লেনদেন, তাড়া করার মতো কোনো ত্রুটি নয়।

ঠিকানা সংঘর্ষ ও IPv4-হীন আপলিংক

টানেল প্রতিষ্ঠিত হয়েও কিছুই বহন করতে পারে না। যখন স্থানীয় LAN ও দূরের নেটওয়ার্ক 192.168.1.0/24-এর মতো প্রিফিক্স ভাগ করে, ক্লায়েন্ট দূরের হোস্টকে সরাসরি সংযুক্ত ভাবে এবং প্যাকেটটি টানেলের বদলে স্থানীয় লিংকে পাঠায়। উপসর্গটি হলো একটি অপ্রাপ্য সাবনেটসহ সফল সংযোগ, যা সার্ভার-পক্ষের রুট সমস্যা হিসেবে সহজেই ভুল পড়া হয়।

স্থায়ী সমাধান হলো দূরের LAN-কে একটি অপ্রচলিত প্রাইভেট রেঞ্জে সরানো। বাড়িতে কেউ ব্যবহার করে না এমন রেঞ্জ বাছাই, যেমন 10.42.0.0/24, একটি নয় বরং প্রতিটি ভবিষ্যৎ লোকেশনের জন্য সমস্যাটি ঠেকায়। স্থানীয় অস্থায়ী উপায় হলো সেই হোটেল, হটস্পট বা রাউটার এড়িয়ে চলা, যা মোটেই সমাধান নয়।

মোবাইল আপলিংক দুইটি ভিন্নতা যোগ করে। ক্যারিয়ার-গ্রেড NAT মানে ইনবাউন্ড সংযোগ পৌঁছায় না, যা সার্ভার হোস্ট করলে গুরুত্বপূর্ণ কিন্তু আউটবাউন্ড ক্লায়েন্টের জন্য নয়। NAT64 অনুবাদসহ শুধু IPv6 হিসেবে কনফিগার করা APN এমন ক্লায়েন্টকে ব্যর্থ করতে পারে যে আসল IPv4 পথ দাবি করে, আর স্বাভাবিক প্রতিকার হলো APN প্রোটোকল IPv4 বা ডুয়াল স্ট্যাকে বদলানো।

টানেল ওঠার পরের উপসর্গ

সংযোগ করে তারপর চুপ হয়ে যাওয়া টানেল সাধারণত keepalive বা MTU সমস্যা, ব্লক করা পোর্ট নয়। নির্দিষ্ট কয়েক মিনিট পর ঝরে পড়া সংযোগ keepalive বা পুনঃসমঝোতা টাইমারের দিকে ইঙ্গিত করে। ক্লায়েন্টকে তার পিয়ার প্রোব করতে ও উত্তর থামলে পুনরায় শুরু করতে সেট করুন, এবং ping সফল হলেও বড় ট্রান্সফার আটকে গেলে ছোট টানেল MTU পরীক্ষা করুন।

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