কেন ক্যাপ্টিভ পোর্টাল আপনার VPN আটকায়, আর কীভাবে আবার সাইন ইন করবেন
পাবলিক Wi-Fi আপনার ডিভাইসকে অনুমোদন দেয় তার থেকে কোনো প্যাকেট বেরোনোর আগেই। পোর্টাল কী ফেলে দেয়, আপনার VPN কেন এটি ভুলভাবে জানায়, আর কোন ক্রমে আবার সংযোগ ফেরে।
একটি খোলা নেটওয়ার্কে আপনার অ্যাক্সেস পয়েন্ট শুধু প্যাকেট ইন্টারনেটে পৌঁছে দেয় না। পথের উপরের একটি পলিসি পয়েন্ট দেখে আপনার ডিভাইস এখনো অনুমোদিত হয়েছে কি না, আর অনুমোদন না হওয়া পর্যন্ত প্রায় সবকিছুই ফেলে দেওয়া হয়। আপনার VPN ক্লায়েন্ট সেই নীরবতাকে মৃত সার্ভার হিসেবে পড়ে। এটি খুব কমই তা বলে: WireGuard শূন্যতার মধ্যে হ্যান্ডশেক আবার পাঠায়, OpenVPN সংযোগের সময় শেষ হওয়ার কথা জানায়, আর IKEv2 সাড়া দিচ্ছে না এমন দূরবর্তী সার্ভার নিয়ে ত্রুটি 809 ফিরিয়ে দেয়।
পোর্টাল আসলে কী নিয়ন্ত্রণ করে
একটি ক্যাপ্টিভ পোর্টাল আসলে দুটি জিনিস জোড়া লাগানো: একটি পলিসি সিদ্ধান্ত পয়েন্ট আর একটি রিডাইরেক্টর। আপনার ডিভাইস যুক্ত হয়ে DHCP লিজ নিলে নেটওয়ার্ক আপনাকে অনুমোদনের আগের অবস্থায় রাখে।
সেই অবস্থা হলো ফায়ারওয়াল নিয়মের একটি সেট। এটি সাধারণত DNS অনুমোদন করে এবং পোর্টাল হোস্টের একটি ছোট তালিকায় HTTP বা HTTPS অনুমোদন করে, আর বাকি সব ফেলে দেয়। অনুমোদিত তালিকাটি হলো দেয়ালঘেরা বাগান, আর এতে প্রায় কখনোই কোনো VPN এন্ডপয়েন্ট থাকে না।
ফেলে দেওয়াগুলোর কোনোটিই ভদ্র নয়। VPN সার্ভারের দিকে পাঠানো প্যাকেট প্রত্যাখ্যান না করে ফেলে দেওয়া হয়, তাই ক্লায়েন্ট কোনো ICMP unreachable পায় না, কোনো TCP reset-ও পায় না, শুধু উত্তর না পাওয়াটাই পায়। ভেন্ডর অনুযায়ী রিডাইরেক্টর পোর্ট 80-এ সাইন-ইন পাতায় রিডাইরেক্ট দিয়ে উত্তর দিতে পারে, অথচ পোর্ট 443 ফেলে দেওয়া বা আটকানো হয়। রিডাইরেক্ট সহজে চোখে পড়ে কারণ সেগুলো সাধারণ HTTP উত্তর বহন করে; 443-এ আটকানোর জন্য এমন সার্টিফিকেট লাগে যা আপনার ব্রাউজার বিশ্বাস করতে অস্বীকার করবে।
অনুমোদন নিজেই সাধারণত ডিভাইসের MAC ঠিকানার সঙ্গে যুক্ত, কখনো লিজ নেওয়া IP-র সঙ্গে, আর এটি একটি টাইমারযুক্ত সেশন টেবিলে থাকে। সাইন ইন করলে একটি এন্ট্রি তৈরি হয়। যে ফায়ারওয়াল নিয়ম আপনার ট্রাফিক যেতে দেয়, সেটি শুধু সেই এন্ট্রি থাকা পর্যন্ত থাকে, তাই আপনার দিকে কিছু না বদলেও পুরো সমস্যাটি পরে ফিরে আসে।
কেন VPN হ্যান্ডশেক শুরুর আগেই মারা যায়
প্রতিটি প্রোটোকলের নিজস্ব ট্রান্সপোর্ট আছে, আর অনুমোদনের আগের ফায়ারওয়াল প্রতিটিকে ভিন্নভাবে ভাঙে। Windows ও iOS-এ IKEv2 চলে UDP 500 ও UDP 4500-এর উপর; এই পোর্টে ফেলে দিলে সেটি 809 হিসেবে দেখা দেয়, অথবা যে ক্লায়েন্ট ধাপগুলো আলাদাভাবে জানায় তাদের ক্ষেত্রে নাম-সমাধান ধরনের ব্যর্থতা হিসেবে দেখা দেয়। UDP 1194-এর উপর OpenVPN তার সময় শেষ না হওয়া পর্যন্ত সংযোগরত অবস্থায় থাকে। TCP 443-এর উপর OpenVPN হলো মজার ঘটনা, কারণ পোর্টাল TCP হ্যান্ডশেক শেষ করে তারপর নিজের রিডাইরেক্ট পাতা দিয়ে উত্তর দিতে পারে, তাই সময় শেষ হওয়ার বদলে আপনি TLS ত্রুটি দেখেন।
WireGuard সবচেয়ে পরিষ্কারভাবে পদ্ধতিটি দেখায়। এটি নকশাতেই শুধু UDP, কোনো TCP বিকল্প নেই, তাই যে ফায়ারওয়াল অজানা UDP ফেলে দেয় সে ট্রান্সপোর্টটাই সরিয়ে দেয়। ক্লায়েন্ট ক্রমবর্ধমান বিরতিতে হ্যান্ডশেক শুরু পাঠাতে থাকে আর এমন হ্যান্ডশেকের কথা জানায় যা কখনো শেষ হয় না। সেই বার্তায় কোথাও Wi-Fi-র উল্লেখ নেই, আর তাতে এমন কিছুও নেই যা বলে আপনি ব্রাউজার খুলুন।
প্ল্যাটফর্মগুলো আপনার VPN-এর আগেই অবস্থাটি বোঝার চেষ্টা করে। Windows সাইন-ইন বিজ্ঞপ্তি দেখাবে কি না ঠিক করতে একটি পরিচিত URL আনে, Android এমন একটি এন্ডপয়েন্ট চায় যার উত্তর 204 No Content হওয়া উচিত, আর Apple ডিভাইসগুলো একটি ছোট ক্যাপ্টিভ-নেটওয়ার্ক উইন্ডো খোলে। সেই প্রোবগুলো কাজ করে কারণ পোর্টাল প্রত্যাশিত বডির বদলে রিডাইরেক্ট দিয়ে উত্তর দেয়। একই আচরণ ব্যাখ্যা করে কীভাবে একটি পোর্টাল পুরোপুরি সুস্থ দেখাতে পারে অথচ আপনার টানেল মৃত: প্রোব আর টানেলকে ভিন্ন নিয়মে বিচার করা হয়।
সেশন শেষ হওয়া আসলে কী রিসেট করে
স্থানগুলো আপনার VPN অ্যাকাউন্টের সঙ্গে সম্পর্কহীন কারণে সেশন শেষ করে: নিষ্ক্রিয়তার সময়সীমা, সর্বোচ্চ সেশন দৈর্ঘ্য, নতুন DHCP লিজ, বা ভিন্ন অ্যাক্সেস পয়েন্টে পুনরায় যুক্ত হওয়া। টাইমার বাজলে সেশন টেবিলের এন্ট্রিটি হারিয়ে যায় আর অনুমোদনের আগের নিয়মের সেটটি চেক-ইনের সময় যেমন ছিল ঠিক তেমনই ফিরে আসে।
প্রতিষ্ঠিত একটি টানেল প্রায়ই সুস্থ দেখানোর মতো যথেষ্ট সময় টেকে। কিপঅ্যালাইভ বার্তা পাঠানো চলতে থাকে, আর ক্লায়েন্ট তা খেয়াল করে কি না তা নির্ভর করে সে উত্তরহীন ট্রাফিককে কীভাবে দেখে, তাই পথ চলে যাওয়ার পরেও স্ট্যাটাস বাতি কিছুক্ষণ সবুজ থাকতে পারে। তারপর টানেল পড়ে যায় আর প্রতিটি পুনঃসংযোগের চেষ্টা একই বন্ধ পোর্টে ব্যর্থ হয়।
সেই মুহূর্তে ক্লায়েন্টের ত্রুটি আপনাকে বলে আপনি কোন ধাপে আছেন, যদি মন দিয়ে পড়েন:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
একটি বিষয় মানুষকে বিভ্রান্ত করে: সেশন যখন MAC ঠিকানার সঙ্গে বাঁধা, তখন সাইন-ইন পাতা রিলোড করলে কাজ নাও হতে পারে। আপনাকে সংযোগটি ছেড়ে দিয়ে আবার যুক্ত হতে হবে, যাতে পোর্টাল মেয়াদোত্তীর্ণ চেষ্টার বদলে নতুন অনুমোদনের চেষ্টা দেখে।
আগে সাইন ইন করুন, তারপর টানেল তোলেন
যে ক্রমটি কাজ করে তা হলো: ডিভাইসকে অনুমোদন দিন, পথ প্রমাণ করুন, VPN চালু করুন, টানেল প্রমাণ করুন, তারপর আপনার স্বাভাবিক ব্লকিং ফিরিয়ে আনুন। শেষ ধাপটি গুরুত্বপূর্ণ, কারণ পোর্টালে পৌঁছাতে আপনার যে সাময়িক অবস্থা দরকার, সেটি ঠিক সেই অবস্থা যা প্রতিরোধ করতে একটি কিল সুইচ থাকে।
টানেলের বাইরে ব্লক করার অপশনযুক্ত ডেস্কটপ ক্লায়েন্টকে পোর্টাল পাতা লোড হওয়ার জন্য সাময়িকভাবে থামাতে হবে, আর সেই টানেলের বাইরের সময়ে সংবেদনশীল অ্যাপ বন্ধ রাখা উচিত; এটিই একমাত্র বিরতি যখন স্থানীয় ট্রাফিক অসুরক্ষিতভাবে বেরোয়। ম্যানেজড সবসময়-চালু ডিভাইসে আপনার পলিসি সরানোর বদলে তার মালিক যে পদ্ধতি প্রকাশ করেছে সেটিই ব্যবহার করা উচিত। পোর্টাল কোনো সার্টিফিকেট সতর্কতা দেখালে থামুন: তা গ্রহণ করলে আপনার সেশন স্থানটির আটকানো প্রক্সির মধ্য দিয়ে যায়, আর সেই প্রক্সি আপনার পাঠানো সবকিছু পড়তে পারে। Android-এ সবসময়-চালু VPN-এর অধীনে লকডাউন টানেল ওঠার আগেই ট্রাফিক আটকায়, আর কিছু বিল্ড পোর্টালের প্রবাহকে ছাড় দিতে পারে না; আপনারটি না পারলে লকডাউন বন্ধ রাখার বদলে স্থানটির বিকল্প অ্যাক্সেস বা অন্য ডিভাইস ব্যবহার করুন। Apple-এর অন-ডিমান্ড নিয়ম এমনভাবে লেখা যায় যাতে প্রোব সফল না হওয়া পর্যন্ত টানেল প্রত্যাখ্যান করে, আর হোটেল নেটওয়ার্কে আপনি ঠিক সেই আচরণই চান।
আপনার কাছে থাকা টুল দিয়েই ক্রমানুসারে যাচাই করুন। টানেলের আগে হেডার ও বডি দুটোই দৃশ্যমান রেখে প্রোবটি চালান, আর দেখুন আপনার VPN ট্রান্সপোর্ট আদৌ কোনো উত্তর পায় কি না:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'অনুমোদনের আগে একটি সাধারণ পোর্টাল দুই উত্তর থেকে একটি দেয়: 302, যার Location সাইন-ইন পাতার দিকে ইশারা করে, অথবা 200, যার HTML বডি হলো পোর্টাল পাতা। কোনটি পেলেন তা লিখে রাখুন। সাইন-ইনের আগে রিডাইরেক্ট ব্যর্থতা নয়; এটি পোর্টাল আপনাকে বলছে কোথায় যেতে হবে। পোর্টাল সফলতার কথা জানানোর পর কমান্ডটি আবার চালান আর 200 প্রত্যাশা করুন যার বডি আক্ষরিক শব্দ Success। সেই স্ট্রিংটাই প্রোবকে অর্থবহ করে। আপনি সাইন ইন করার আগেই যদি হোস্ট স্বাভাবিকভাবে উত্তর দেয়, তবে এই নেটওয়ার্কে কোনো আটকানো পোর্টাল নেই। ক্যাপচারে অনুমোদনের আগের ফেলে দেওয়া মানে বাইরের প্যাকেট যার কিছুই ফিরে আসে না, অন্যদিকে কাজ করা পথ একই প্রবাহে এক সেকেন্ডের মধ্যে উত্তর দেখায়। সংযোগ করুন, তারপর ক্যাপচারটি আবার করুন।
পোর্টাল হ্যাঁ বলার পরেও টানেল ব্যর্থ হলে
সাইন-ইনের সাফল্য অনুমোদিত ট্রান্সপোর্টের সমান নয়। অনেক স্থান পোর্টাল ও সাধারণ ব্রাউজিং অনুমোদন করে অথচ UDP পুরোপুরি ব্লক করে, ফলে WireGuard ও UDP-র OpenVPN ভাঙা থাকে আর TCP 443 কাজ করে। TCP 443 পার হয় কিন্তু UDP না পারলে সেটি স্থানটির নীতি, আপনার ভুল কনফিগার করা ক্লায়েন্ট নয়, তাই ট্রান্সপোর্ট বদলান বা সীমাটি মেনে নিয়ে এগিয়ে যান। এরপরও পুনঃসংযোগ ব্যর্থ হলে সঠিক ত্রুটিটি রেখে দিন; এটি বলে দেয় আপনি কোন ধাপে আটকে আছেন।
অন্য ব্যর্থতাগুলো ডিভাইসেই থাকে। পুরনো MAC-এ বাঁধা থাকা সেশন, নিজস্ব লিজযুক্ত দ্বিতীয় Wi-Fi অ্যাডাপ্টার, বা পোর্টালের সার্টিফিকেট ব্যতিক্রম ক্যাশে করা ক্লায়েন্ট—এদের প্রত্যেকেই পরিচ্ছন্ন পুনরনুমোদনের পরেও ব্যর্থ হতে পারে। সংযোগটি ছেড়ে দিন, আবার অনুমোদন নিন, আর ক্লায়েন্ট সেটিংসে হাত দেওয়ার আগে একবার চেষ্টা করুন। আপনি যে উপাদানগুলো দেখছেন তার পেছনের স্থাপত্য চাইলে RFC 8952 পড়ার মতো।
পোর্টাল নিজেই অনুমোদন দিতে অস্বীকার করলে সমস্যাটি অ্যাকাউন্ট বা ডিভাইস বরাদ্দে, আর কোনো VPN সেটিং তা সারাবে না। VPN-এর প্রস্থান দেশ বদলালে স্থানটির স্থানীয় অ্যাক্সেস অবস্থা রিসেট হয় না; সেই টেবিল আপনার ডিভাইসের সঙ্গে যুক্ত, আপনার বেছে নেওয়া সার্ভারের সঙ্গে নয়। স্থানটির অপারেটরকে জিজ্ঞাসা করুন এবং সময় দিন, কারণ তিনি সেশন টেবিলটাই দেখবেন।
পরের ভ্রমণের আগে তিনটি জিনিস লিখে রাখুন: শূন্য ধাপ হিসেবে পোর্টাল পাতা, আপনি যে প্রতিটি ডিভাইস বহন করেন তার জন্য ব্লকিং থামানোর ধাপ, আর একটি ট্রান্সপোর্ট ফলব্যাক যা আপনি সত্যিই পরীক্ষা করেছেন। দশ মিনিট আগে কাজ করা টানেল আবার থেমে গেলে সেটিকে মেয়াদোত্তীর্ণ অনুমোদন ধরুন আর VPN প্রোফাইলে হাত দেওয়ার আগে পোর্টালটি আবার দেখে নিন।