VPN চালানোর সময় আবার সংযোগ করে: রেডিও বদল নাকি IP বদল?
টাওয়ারের মধ্যে হ্যান্ডওভার IP পথ অক্ষত রাখতে পারে। যে ক্লায়েন্টরা টানেল সরায় তাদের সঙ্গে যারা এটি নতুন করে গড়ে তুলে তাদের তুলনা করুন, এবং নেটওয়ার্কের ঘটনা পড়ুন, যাত্রা নয়।
শহরের প্রান্ত পার হওয়ার সময় কল কেটে যায়, এবং VPN আইকন ঠিক সেই মুহূর্তেই অদৃশ্য হয়। এটি “টাওয়ার বদল টানেলটিকে মেরে ফেলেছে” হিসেবে লিখে রাখা প্রলুব্ধকর। দুটি ভিন্ন ঘটনা ঘটেছে, এবং তাদের মধ্যে কেবল একটি টাওয়ারের সঙ্গে সম্পর্কিত। একটি রেডিও হ্যান্ডওভার আপনার IP ঠিকানা, ডিফল্ট রুট ও সেশন সম্পূর্ণ অক্ষত রাখতে পারে, অথচ একটি প্রকৃত ঠিকানা পরিবর্তন যেকোনো টানেল ভেঙে দেবে যা তার সঙ্গে চলতে পারে না। ক্লায়েন্টরা সেই দ্বিতীয় ক্ষেত্রটি কীভাবে সামলায় তা তুলনা করাই কার্যকর অনুশীলন, কারণ এটি বলে দেয় আপনি নকশাকৃত আচরণ দেখছেন নাকি ত্রুটি।
টাওয়ার বদল মানেই ঠিকানা বদল নয়
মোবাইল নেটওয়ার্ক হ্যান্ডওভারের মধ্যেও প্যাকেট সেশন সচল রাখে যতক্ষণ অপারেটরের মোবিলিটি অ্যাঙ্কর একই থাকে। রেডিও লিঙ্ক বদলায়, টানেল তা লক্ষ্য করে না, এবং কোনো লগেই পুনঃসংযোগ দেখা উচিত নয়। শহরের ভেতরে চলাচলের জন্য এটিই সাধারণ ক্ষেত্র।
ঠিকানা বদলায় অ্যাঙ্করের মধ্যে স্থানান্তর, Wi-Fi থেকে সেলুলারে বদল, বা দীর্ঘ বিরতির পর অপারেটরের দিকে টানেল পুনঃস্থাপন। সেই ঘটনাগুলো আপনার প্যাকেট যে উৎস ঠিকানা বহন করে তা প্রতিস্থাপন করে, এবং একটি VPN সঙ্গী একটি সরেছে এমন সঙ্গী দেখে।
ব্যবহারিক ফল হলো চলাচল কোনো প্রমাণ নয়। চল্লিশ কিলোমিটার চলা একটি ডিভাইস সারা পথে একটি ঠিকানা রাখতে পারে, আর স্থির বসে থাকা একটি ডিভাইস দুবার ঠিকানা বদলাতে পারে কারণ নেটওয়ার্ক তেমনই সিদ্ধান্ত নিয়েছে। ঘটনাটি রেকর্ড করাই তাদের আলাদা করার একমাত্র উপায়।
দুটি নকশা: টানেল সরান বা নতুন করে গড়ুন
ক্লায়েন্টরা আলাদা এই বিষয়ে যে বাইরের উৎস বদলেছে বলে তারা কতটা গুরুত্ব দেয়। কেউ টানেলকে যে ঠিকানার উপর গড়া হয়েছিল তার সঙ্গে বেঁধে রাখে এবং সম্পূর্ণ পুনঃস্থাপন দাবি করে। অন্যরা প্রতিটি প্যাকেট স্বাধীনভাবে যাচাই করে এবং কেবল উত্তর কোথায় পাঠাবে তা হালনাগাদ করে।
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
উপরের সারি অনেক বিভ্রান্তিকর প্রতিবেদন ব্যাখ্যা করে। WireGuard-এর ভাঙার মতো কোনো সেশন নেই: প্রতিটি প্যাকেট সঙ্গীর সূচক বহন করে এবং যাচাই করা হয়, তাই নতুন ঠিকানা থেকে আসা বৈধ প্যাকেট সংজ্ঞা অনুযায়ী সেই সঙ্গীরই, এবং রেকর্ড করা প্রান্তবিন্দু তা অনুসরণ করে। যাত্রাপথে অবিরত “সংযুক্ত” দেখানো ক্লায়েন্ট সত্য বলছে।
নিচের সারিও ত্রুটি নয়। সেশন নতুন করে গড়া বর্তমান ঠিকানার বিরুদ্ধে যাচাই আবার চালায়, আর পুরনো ঠিকানা এখন অন্য কারও হতে পারে—তখন ঠিক এটাই আপনি চান।
চলাচল নয়, ঘটনাটি পর্যবেক্ষণ করুন
Android-এ কানেক্টিভিটি সাবসিস্টেম নেটওয়ার্ক পরিবর্তনগুলো ঘটনা হিসেবে প্রতিবেদন করে, আর সেগুলোই আপনার ক্লায়েন্টের আচরণের সঙ্গে সম্পর্কযুক্ত করা উচিত। ডাম্পটি দীর্ঘ, তবে প্রাসঙ্গিক অংশ হলো ডিফল্ট নেটওয়ার্ক ও তার ঠিকানা:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40সার্ভারের দিকে রোমিং ক্ষেত্রটির জন্য সরাসরি পরিমাপ আছে। WireGuard প্রতিটি সঙ্গীর সর্বশেষ যাচাইকৃত প্রান্তবিন্দু সংরক্ষণ করে, তাই ঠিকানা পরিবর্তন পুনঃসংযোগ হিসেবে নয় বরং বদলে যাওয়া মান হিসেবে দেখায়:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesযাত্রার আগে ও পরে প্রান্তবিন্দু তুলনা করুন। ঠিকানা ও পোর্ট অপরিবর্তিত থাকলে টানেলকে কিছুই করতে হয়নি এবং পুনঃসংযোগ অন্য জায়গা থেকে, সাধারণত অ্যাপ্লিকেশন থেকে এসেছে। প্রান্তবিন্দু বদলালেও হ্যান্ডশেকের সময়চিহ্ন যদি স্বাভাবিক কী নবায়ন ব্যবধানের কাছাকাছি থাকে, তবে টানেল পুনরায় চালু হয়নি, সরে গেছে।
পুনরায় চালু ভিন্ন দেখায়: হ্যান্ডশেকের সময়চিহ্ন পুনঃসংযোগের মুহূর্তে রিসেট হয়, এবং ক্লায়েন্ট শান্ত ধারাবাহিকতার বদলে আরম্ভের ক্রম লগ করে।
কখন পুনঃসংযোগই সঠিক আচরণ
প্রতিটি পুনঃসংযোগকে ত্রুটি ধরলে এমন কনফিগারেশন তৈরি হয় যা মৃত সেশন সচল রাখে। যে সঙ্গীর ঠিকানা বদলেছে কারণ নেটওয়ার্ক তা পুনর্বণ্টন করেছে, তার পুরনো ম্যাপিংয়ের ট্রাফিক পাওয়া চালিয়ে যাওয়া উচিত নয়, আর নীরবে চলতে থাকা ক্লায়েন্ট আইকন সবুজ থাকা সত্ত্বেও কালো গর্তে পাঠিয়ে দিতে পারে।
ব্যবহারকারীর দৃষ্টিকোণ থেকে দুই ব্যর্থতা তুলনা করুন। পুনঃসংযোগে কয়েক সেকেন্ড ও একটি নতুন যাচাই লাগে। পুরনো টানেলে লাগে এমন একটি অ্যাপ্লিকেশন যা ত্রুটি ছাড়াই আটকে যায়, যা ব্যাখ্যা করা অনেক কঠিন এবং “ইন্টারনেট নষ্ট হয়ে গেছে” হিসেবে রিপোর্ট হওয়ার সম্ভাবনা অনেক বেশি।
এর নিচে একটি নীতিগত প্রশ্নও লুকিয়ে আছে। একটি পথ হারানো ও আরেকটি প্রতিষ্ঠার মধ্যবর্তী ফাঁকে কিছু ক্লায়েন্ট সরাসরি ট্রাফিক পাঠাতে ফিরে যায়। তা প্রতিরোধ স্বয়ংক্রিয় পুনরুদ্ধার থেকে আলাদা নিয়ন্ত্রণ, এবং একটি ক্লায়েন্ট একটিতে ভালো ও অন্যটিতে খারাপ হতে পারে। যেকোনোটি সাজানোর আগে ঠিক করুন আপনার কোনটি দরকার।
পর্যবেক্ষিত ক্রমটি লিখে রাখুন
কার্যকর প্রতিবেদন ঘটনার উৎসের নাম নেয়: নতুন ঠিকানাসহ ডিফল্ট নেটওয়ার্ক পরিবর্তন, Wi-Fi থেকে সেলুলারে বদল, বা কোনো ঠিকানা পরিবর্তন ছাড়াই হ্যান্ডওভার। তারপর এটি বলে ক্লায়েন্ট কী করেছে, স্মৃতি থেকে নয় বরং সার্ভারের দিকের সময়চিহ্ন দিয়ে।
টানেল সরে গেলে তা বলুন এবং নতুন প্রান্তবিন্দু পরিবার লিখুন। নতুন করে প্রতিষ্ঠিত হলে লিখুন যাচাই প্রথম চেষ্টাতেই সফল হয়েছিল কি না এবং ফাঁক কতক্ষণ ছিল। এই তিনটি তথ্য সুস্থ মোবাইল নকশাকে নেটওয়ার্কের মধ্যে দোলাচল করা ক্লায়েন্ট থেকে আলাদা করে।
আর “টাওয়ার বদল” বাক্যাংশটি এড়িয়ে চলুন, যদি না ডিভাইসের লগ সত্যিই তা প্রতিষ্ঠা করে। Android-এর কানেক্টিভিটি ডকুমেন্টেশন সেই কলব্যাকগুলোর বর্ণনা দেয় যা উপলব্ধতাকে ডিফল্ট নেটওয়ার্ক পরিবর্তন থেকে আলাদা করে, এবং আপনার প্রতিবেদনের প্রয়োজন ঠিক সেই পার্থক্যটি। বাকি সব গাড়ি চালানোর গল্প।