Wi-Fi বদলালে বা Ethernet লাগালে আপনার VPN কেন কেটে যায়
'নতুন SSID, অ্যাক্সেস পয়েন্টের মধ্যে রোমিং আর লাগানো কেবল - তিনটি আলাদা জায়গায় টানেল ভাঙে। আগে সোর্স অ্যাড্রেস, তারপর রুট, তারপর প্রোটোকল দেখুন।'
দুটি ঘটনা একটিই ব্যর্থতা হিসেবে রিপোর্ট হয়: ল্যাপটপ অন্য Wi-Fi নেটওয়ার্কে চলে গেছে, অথবা Wi-Fi চালু থাকতেই কেবল লাগানো হয়েছে। ক্লায়েন্ট এখনও বলে সংযুক্ত, আইকন সুস্থ দেখায়, আর টানেল কিছুই বহন করে না। ভেতরে কেবল তিনটি অবস্থা নড়তে পারে - লিংক, লোকাল অ্যাড্রেস, ডিফল্ট রুট - আর কোনটি নড়েছে তার উপরই নির্ভর করে টানেল নিজে থেকে ঠিক হবে, নাকি আবার সংযোগ দরকার। আমি এই ক্রমেই সেগুলো দেখি, কারণ অ্যাকাউন্ট সেটিংস বদলে কোনোদিনই এগুলোর একটি ঠিক হয়নি।
লিংক, অ্যাড্রেস আর রুট আলাদাভাবে নড়ে
একই নেটওয়ার্কের অ্যাক্সেস পয়েন্টের মধ্যে রোমিং সাধারণত L2 ইভেন্ট। রেডিও আবার অ্যাসোসিয়েট করে, ইন্টারফেস তার অ্যাড্রেস আর গেটওয়ে ধরে রাখে, আর টানেল নির্ভর করে এমন কিছুই বদলায় না, তাই বড় অফিসে হাঁটাচলা মাঝে মাঝে ধরা পড়ে না। অন্য SSID-তে যোগ দেওয়া তা নয়: পুরোনো ইন্টারফেস নেমে যেতে পারে, DHCP নতুন অ্যাড্রেস, নতুন গেটওয়ে আর নতুন রিজলভার দেয়, আর টানেল যে আউটার ফ্লো ব্যবহার করছিল তা আর থাকে না।
Ethernet তৃতীয় একটি রূপ যোগ করে। Wi-Fi কখনও নামে না, তাই লিংক ইভেন্ট একেবারেই ঘটে না, তবু তারযুক্ত ইন্টারফেস নিজের অ্যাড্রেস নিয়ে হাজির হয় এবং প্রায়ই মেট্রিকে ডিফল্ট রুট জিতে নেয়। টানেল এমন পথে চলতে থাকে যা আর পছন্দের নয়, অথবা ক্লায়েন্ট তার সকেট যে বেতার নেটওয়ার্কে শুরু করেছিল তাতেই পিন করে রাখে। ব্রাউজার থেকে দুটোই একই রকম দেখায়: কেবল ক্লিক করা মুহূর্তেই পেজ আটকে যায়।
তাই প্রথম প্রশ্ন Wi-Fi বদলেছে কি না তা নয়। প্রশ্ন হলো, আপনি যে অ্যাড্রেসে বাঁধা আছেন বা এন্ডপয়েন্টের রুট, টানেল চালু থাকার সময় বদলেছে কি না।
আউটার সকেট এমন এক অ্যাড্রেসে পিন করা যা এইমাত্র উধাও হয়েছে
প্রতিটি টানেল একটি আউটার ফ্লো: একটি লোকাল অ্যাড্রেস ও পোর্ট সার্ভারের অ্যাড্রেস ও পোর্টের সঙ্গে কথা বলে। Linux-এ সেটি পুরোনো সোর্সে বাঁধা একটি UDP সকেট; অ্যাড্রেসটি যে ইন্টারফেস ধরে আছে তা সরিয়ে নিলে পাঠানো হয় EADDRNOTAVAIL দিয়ে ব্যর্থ হয়, নয়তো নতুন ইন্টারফেস দিয়ে এমন সোর্স নিয়ে বেরোয় যা সার্ভার কখনও দেখেনি।
দূর প্রান্ত নিজের পিন ধরে রাখে। MOBIKE ছাড়া একটি IKEv2 SA অ্যাড্রেস জোড়া দিয়ে চিহ্নিত হয়, আর একটি OpenVPN সেশন যে পিয়ার অ্যাড্রেস শিখেছে তাতে বাঁধা থাকে, আর একটি NAT ম্যাপিং তার সৃষ্টিকারী প্রাইভেট অ্যাড্রেস, পোর্ট ও পাবলিক অ্যাড্রেসের। ভিন্ন NAT-এর পিছনে গেলে প্রতিটি উত্তর এমন ম্যাপিংয়ে যায় যা আর নেই। আপনার মেশিনে কিছুই ভুলভাবে কনফিগার করা নেই; পাঁচ-টুপল এমন এক নেটওয়ার্কের দিকে দেখাচ্ছে যা আপনি ছেড়ে এসেছেন।
তত্ত্ব দেওয়ার আগে অবস্থাটা পড়ুন:
ss -unpপ্রতিটি টানেল সকেট আসলে কোন লোকাল অ্যাড্রেস ও পোর্ট ধরে আছে তা দেখায়।ip route get 203.0.113.10কার্নেল এই মুহূর্তে এন্ডপয়েন্টের জন্য যে সোর্স অ্যাড্রেস ও ডিভাইস ব্যবহার করবে তা ছাপে।wg show wg0 endpoints,swanctl --list-sasঅথবা ক্লায়েন্ট লগ দূর প্রান্ত যে পিয়ার অ্যাড্রেসের সঙ্গে কথা বলছে বলে মনে করে তা দেখায়।
সকেটের অ্যাড্রেস আর রুট লুকআপ অসঙ্গত হলে আপনি ভাঙনটি খুঁজে পেয়েছেন, আর কোনো ক্রেডেনশিয়াল বদল তাতে হাত দেবে না।
নতুন সোর্স অ্যাড্রেস নিয়ে প্রতিটি প্রোটোকল কী করে
ক্লায়েন্টরা পরিবর্তনটি ভিন্ন মাত্রায় শোষে, আর টেবিলটিই আমার ক্লায়েন্ট কনফিগের সঙ্গে তুলনার জিনিস, রিকানেক্ট আচরণ থেকে আন্দাজ করার বদলে।
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuard-এর রোমিং নিয়ম এক দিকেই কাজ করে: ক্লায়েন্টকে আগে নতুন অ্যাড্রেস থেকে পাঠাতে হবে। পুরোনো ইন্টারফেসে বাঁধা সকেট তা কখনও করে না, তাই হ্যান্ডশেক টাইমার বুড়ো হতে থাকলেও টানেল জাগ্রত দেখাতে পারে। প্রোটোকল বিবরণ এন্ডপয়েন্ট আপডেটের শর্তটি নিখুঁতভাবে বলে, আর কোনো কনফিগ বদলানোর আগে তা পড়া উচিত।
MOBIKE আলোচনা করে ঠিক হয়, ধরে নেওয়া হয় না। সার্ভার এটি না দিলে ক্লায়েন্টকে আবার সংযোগ স্থাপন করতে হবে, আর এটি এমন সত্য যা আপনি SA তালিকা বা লগ থেকে নিশ্চিত করেন, ঘুরন্ত চাকা থেকে অনুমান করেন না।
পথ ঠিক করে রুটের অগ্রাধিকার, Wi-Fi আইকন নয়
দুটি ইন্টারফেসই চালু থাকলে কার্নেল মেট্রিক আর প্রিফিক্স দৈর্ঘ্য দিয়ে বেছে নেয়। ip route show default প্রার্থীদের তালিকা দেয় আর ip route get 203.0.113.10 সোর্স অ্যাড্রেসসহ প্রকৃত সিদ্ধান্তটি ঠিক করে। মেট্রিক 100-এ তারযুক্ত ডিফল্ট আর 600-এ বেতার ডিফল্ট মানে কেবল বসামাত্রই এন্ডপয়েন্ট সরে যায়, অথচ আগে সকেট খোলা প্রতিটি অ্যাপ্লিকেশন তার পুরোনো সোর্স ধরে রাখে।
Windows একই কাজ করে স্বয়ংক্রিয় ইন্টারফেস মেট্রিক দিয়ে, লিংক গতির পক্ষপাত নিয়ে। Get-NetRoute -DestinationPrefix 0.0.0.0/0 প্রার্থীদের সাজায় আর Find-NetRoute -RemoteIPAddress 203.0.113.10 স্ট্যাক যে ইন্টারফেস ও সোর্স বেছে নিত তা ফেরত দেয়। যে ক্লায়েন্ট তার আউটার সকেট একটি ইন্টারফেসে বাঁধে, মেট্রিক উল্টে যাওয়ার পরেও সেটিই ব্যবহার করে; এটি বাঁধার সিদ্ধান্ত, রাউটিং ত্রুটি নয়।
Android বিভাজনটি দৃশ্যমান করে: ConnectivityManager উপলব্ধ নেটওয়ার্ক আর আলাদা ডিফল্ট জানায়, আর যে VPN অ্যাপ সকেটকে Network অবজেক্টে বাঁধে তা আবার না বাঁধা পর্যন্ত সেই বাঁধন ধরে রাখে। macOS-এ, scutil --nwi প্রাথমিক ইন্টারফেস আর সিস্টেম যে ক্রম ব্যবহার করত তা ছাপে।
DNS, MTU আর IPv6 সংযুক্তির সঙ্গে সরে
নতুন সংযুক্তি নতুন রিজলভার আনে। systemd-resolved-এ DNS প্রতি-লিংকে, resolvectl status কোন লিংক একটি নামের উত্তর দেয় তা দেখায়, আর যে গেস্ট নেটওয়ার্ক নিজের রিজলভার দেয় সেটি লিংক আবার অগ্রাধিকার না পাওয়া পর্যন্ত টানেলের পাঠানো DNS অব্যবহৃত রেখে দিতে পারে। ক্যাপটিভ পোর্টাল আরও খারাপ করে: প্রথম HTTPS অনুরোধের উত্তর এন্ডপয়েন্ট নয়, পোর্টাল দেয়, আর ক্লায়েন্ট মৃত সার্ভার নথিভুক্ত করে।
পথের MTU-ও বদলায়। Ethernet আর Wi-Fi সাধারণত 1500 বাইট, PPPoE 1492, আর মোবাইল লিংক প্রায়ই কম বহন করে। যে টানেল ছোট MTU উত্তরাধিকারে পায় সেটি বড় প্যাকেটে আটকে যায়, ছোট অনুরোধ সফল হয়, যা অর্ধভাঙা সংযোগের মতো পড়া যায়। ping -M do -s 1472 203.0.113.10 DF সেট করা 1500 বাইটের প্যাকেট পাঠায়; নীরবতা মানে পথটি আপনার ধারণার চেয়ে ছোট।
IPv6 হলো অন্য অর্ধেক। যে নেটওয়ার্ক নতুন প্রিফিক্স দেয় তা ডুয়াল-স্ট্যাক ক্লায়েন্ট যে সোর্স ব্যবহার করত তা বদলায়, আর শুধু v4 টানেল পলিসি না মেলানো পর্যন্ত v6 ট্র্যাফিককে বাইরে রাখে। ip -6 route show default আর ip -6 addr show নতুন লিংকের আদৌ v6 পথ আছে কি না তার উত্তর দেয়।
বর্ণনা না করে রূপান্তরটি পুনরুৎপাদন করুন
একটি নিরীহ অনুরোধ বেছে নিন আর পরিবর্তনের দুই পাশে একই তিনটি কমান্ড চালান: ip -br addr, ip route show default, ip route get 203.0.113.10। তারপর দেখুন টানেল এখনও প্যাকেট ছাড়ে কি না - tcpdump -ni any udp port 51820 WireGuard-এর জন্য, বাকি সবের জন্য অনুরূপ পোর্ট। পুরোনো সোর্স থেকে বেরোনো প্যাকেট মানে বাঁধার সমস্যা। নতুন সোর্স থেকে বেরিয়ে উত্তর না পাওয়া প্যাকেট মানে দূর প্রান্ত বা মাঝের NAT।
প্রথম ব্যর্থতার সঙ্গে কোন ঘটনাটি মিলল তা টুকে রাখুন: লিংক নামা, অ্যাড্রেস বদল, বা ডিফল্ট রুট বদল। এগুলো ভিন্ন মালিকের দিকে দেখায় - এমন ক্লায়েন্ট যা আবার বাঁধতে হবে, এমন অ্যাড্রেস যা আবার নিতে হবে, বা এমন রুট যা কনফিগ ফাইলের, চিরস্থায়ী বাইপাস নিয়মের নয়।
ঠিক হয়েছে বলার আগে নিশ্চিত করুন যে সরাসরি ট্র্যাফিকের ব্লকটি ফাঁকের সময়েও টিকে আছে আর নামগুলো নতুন সংযুক্তি দিয়ে রিজলভ হয়। সুইচের পরেও ক্লায়েন্ট পুরোনো এন্ডপয়েন্ট ধরে রাখলে আগে রোমিং বা float সেটিং ঠিক করুন। সঠিকভাবে রোমিং করেও উত্তর না পেলে সার্ভারের পিয়ার পরিচয় আর পথের NAT দেখুন, আর দুটি নেটওয়ার্ক প্রসঙ্গই প্রতিবেদনে রাখুন যাতে পরের ব্যক্তি তুলনা করতে পারেন।