মোবাইল ডেটায় WireGuard চলে, কিন্তু একই Wi-Fi-তে চলে না
ল্যানের ভেতর থেকে রাউটারের পাবলিক ঠিকানায় পাঠানো অনুরোধ মোবাইল ডেটার অনুরোধের চেয়ে আলাদা পথ নেয়। আগে বাইরে থেকে পরীক্ষা করুন, তারপর স্থানীয় পথ বেছে নিন।
মোবাইল ডেটায় টানেল উঠে আসে, কিন্তু বাড়িতে গিয়ে একই প্রোফাইল, একই পিয়ার কী এবং মাঝখানে কোনো কনফিগারেশন পরিবর্তন ছাড়াই সংযোগ স্থাপনের অবস্থায় আটকে থাকে। পার্থক্যটি যাত্রাপথে: ল্যানের ভেতর থেকে রাউটারের পাবলিক ঠিকানায় যাওয়া অনুরোধ আর ইন্টারনেট থেকে আসা অনুরোধ একই পথে যায় না। বেশিরভাগ হোম গেটওয়ে হয় ফেরত পথটি বাস্তবায়ন করে না, নয়তো শুধু কিছু নির্দিষ্ট প্রোটোকলের জন্য করে। এতে কী-তে কিছুই বদলায়নি এমন অবস্থায়ও উপসর্গটি ভাঙা কী-এর মতো দেখায়। কী, পোর্ট ফরওয়ার্ড বা ক্লায়েন্ট প্রোফাইল স্পর্শ করার আগে কোন পথটি ব্যর্থ হয়েছে তা নির্ধারণ করুন।
একই ঠিকানা, দুটি আলাদা পথ
বাইরে থেকে একটি প্যাকেট রাউটারের পাবলিক ঠিকানায় পৌঁছায় এবং একটি পোর্ট-ফরওয়ার্ড নিয়ম সেটি অভ্যন্তরীণ হোস্টের WireGuard লিসেনারে পৌঁছে দেয়। ভেতর থেকে ক্লায়েন্ট একই পাবলিক ঠিকানা ডায়াল করে, তাই প্যাকেটটি ক্লায়েন্ট ছেড়ে রাউটারে পৌঁছায় এবং আবার ল্যানের দিকে ফেরাতে হয়। ফেরত মোড়টিতেই দুটি পথ আলাদা হয়ে যায়, কারণ রাউটারকে এমন একটি ফ্লো অনুবাদ করতে হয় যা একই ইন্টারফেস ছেড়ে আবার সেখানেই প্রবেশ করে। অনেক বাস্তবায়ন অনুবাদ করার বদলে সেটি ফেলে দেয়, আর তারপর ক্লায়েন্ট এমন একটি হ্যান্ডশেকের জন্য অপেক্ষা করে যা কখনোই পাঠানো হয়নি।
এই আচরণকে সাধারণত NAT লুপব্যাক বা হেয়ারপিনিং বলা হয়, আর এটি WireGuard-এর নয়, রাউটারের বৈশিষ্ট্য; RFC 4787-এ সেই অনুবাদ-পরিস্থিতিগুলো বর্ণিত আছে যেখানে গেটওয়ে এটি সমর্থন করতে পারে বা নাও পারে। WireGuard নিজে পথটি নিয়ে কোনো মত পোষণ করে না, কারণ এটি কেবল সেই প্যাকেটগুলোই দেখে যা তার ইন্টারফেসে পৌঁছায়। রাউটার যখন ফ্লোটি ফেলে দেয়, ডেমন কিছুই পায় না, ক্লায়েন্ট হ্যান্ডশেক টাইমআউট রিপোর্ট করে এবং সার্ভার লগ খালি থাকে। তাই খালি লগ হলো প্যাকেট কোথায় থেমেছিল তার একটি সূত্র, সার্ভার ডাউন আছে তার প্রমাণ নয়। এজন্যই পুনরায় ইনস্টল করলে কিছুই বদলায় না।
উল্টোটাও গুরুত্বপূর্ণ: ল্যান ঠিকানা থেকে হ্যান্ডশেকের চেষ্টা দেখানো একটি সার্ভার লগ প্রমাণ করে প্যাকেটটি পৌঁছেছে এবং পথটি ঠিক আছে, ফলে তদন্ত কী ও অনুমোদিত ঠিকানার দিকে সরে যায়। লগটি যা প্রমাণ করে তা পড়ুন, আপনি যা দেখতে চেয়েছিলেন তা নয়।
কিছু বদলানোর আগে সমস্যাটি পুনরুৎপাদন করুন
একই ডিভাইস ও একই প্রোফাইল দিয়ে অনুমোদিত বাহ্যিক নেটওয়ার্ক থেকে পরীক্ষা করুন, তারপর কিছু না বদলিয়ে ল্যানের ভেতরে পরীক্ষাটি আবার করুন। বাইরে সম্পূর্ণ হওয়া একটি হ্যান্ডশেক আর ভেতরে এমন একটি ক্লায়েন্ট যা ডিভাইস ছেড়েই না, অনুমানের বদলে অবস্থাটি পুনরুৎপাদন করে। দুটি চেষ্টাই একই প্রোফাইল ব্যবহার করতে হবে, নইলে তুলনাটি কিছুই প্রমাণ করে না।
তারপর দেখুন এই ডিভাইসের জন্য এন্ডপয়েন্ট নামটি কী ঠিকানায় রিজলভ হয়। এই তিনটি কমান্ড আরও দেখায় ক্লায়েন্ট আসলে কোন ঠিকানায় ডায়াল করেছে:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netপ্রথম কমান্ডটি জানায় ইন্টারফেসটি এই মুহূর্তে কোন এন্ডপয়েন্ট ব্যবহার করছে, আর বাকি দুটি দেখায় এই মেশিনে নামটি কী ঠিকানায় রিজলভ হয়। সার্ভারের মতো একই নেটওয়ার্কে বসে কোনো ক্লায়েন্ট পাবলিক ঠিকানা ডায়াল করলে সে হেয়ারপিন পথটি ব্যবহার করছে। কোনো ক্লায়েন্ট ল্যান ঠিকানা ডায়াল করলে তা নয়, আর সেখানে ব্যর্থতা ভিন্ন কোনো তদন্তের বিষয়। এই পার্থক্যই ঠিক করে পরের অংশটি এখানে প্রযোজ্য কি না।
কাছের সার্ভারে পৌঁছানোর সমর্থিত উপায়
সবচেয়ে পরিচ্ছন্ন ব্যবস্থা হলো স্প্লিট-হরাইজন উত্তর: পাবলিক নামটি ইন্টারনেটের জন্য পাবলিক ঠিকানায় এবং ভেতরের ক্লায়েন্টদের জন্য সার্ভারের ল্যান ঠিকানায় রিজলভ হয়। প্রোফাইলটি একটি এন্ডপয়েন্ট নাম রাখে আর রিজলভারই পথটি বেছে নেয়। এর জন্য অভ্যন্তরীণ DNS উত্তরের নিয়ন্ত্রণ দরকার, যা হোম রাউটার সাধারণত দেয় এবং কোনো প্রতিষ্ঠান সচেতনভাবেই ব্যবস্থা করতে পারে। সেই নিয়ন্ত্রণ ছাড়া বাকি বিকল্প হলো রাউটারের কোনো ফিচার বা দ্বিতীয় একটি প্রোফাইল।
রাউটারের ফিচারটি হলো রিফ্লেকশন: গেটওয়ে অভ্যন্তর-থেকে-পাবলিক ফ্লোটি অনুবাদ করে আবার ভেতরে পাঠিয়ে দেয়। যেখানে এটি কাজ করে সেখানে ক্লায়েন্টে কিছু বদলাতে হয় না, আর যেখানে কাজ করে না সেখানে কোনো ক্লায়েন্ট সেটিংই উদ্ধার করতে পারবে না। রাউটারের ফিচার-তালিকা পড়ার বদলে অভ্যন্তরীণ চেষ্টার সময় সার্ভার লগ দেখে এটি পরীক্ষা করুন।
প্রোফাইলে ব্যক্তিগত ঠিকানা বসানো একটি রোগনির্ণয়, কোনো নকশা নয়। এটি প্রমাণ করে সার্ভার ল্যানে উত্তর দেয়, আর ল্যাপটপটি বাড়ি ছাড়ার মুহূর্তেই একই প্রোফাইলটি ভেঙে যায়।
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
বাড়ির বাইরেও প্রোফাইলটি ব্যবহারযোগ্য রাখুন
যে পথই বেছে নিন, পরিচয় যাচাইয়ে হাত দেবেন না। এন্ডপয়েন্ট ঠিকানা পিয়ার পরিচয় নয়, আর ঠিকানা বদলালে এমন একটি অসম্পর্কিত পাবলিক কী মেনে নেওয়ার কোনো যৌক্তিকতা হয় না যা কেবল উত্তর দিচ্ছে। WireGuard কী দিয়েই প্রমাণ করে, তাই ভুল হোস্ট হ্যান্ডশেক ব্যর্থ করে, অপ্রত্যাশিত কিছুতে প্রবেশাধিকার দেয় না।
পাবলিক ঠিকানা বদলালে ডাইনামিক DNS-ই নামটিকে কাজে লাগাতে রাখে, আর ক্লায়েন্টের রিফ্রেশ আচরণ ঠিক করে পরিবর্তনটি কত দ্রুত কার্যকর হয়। ঠিকানা বদলানোর পর বাইরে থেকে এটি পরীক্ষা করুন, কারণ ল্যানের ক্ষেত্রে তা যাচাই করা যায় না। রেকর্ডের আয়ুর পরেও পুরোনো উত্তর ক্যাশে রাখে এমন রিজলভার সম্পর্কে সতর্ক থাকুন। আগের ঠিকানাতেই নির্দেশ করে থাকা নাম দেখতে ঠিক একটি ডাউন হয়ে যাওয়া সার্ভারের মতোই লাগে।
প্রোফাইলটি কোন নাম ব্যবহার করে এবং সীমানার দুই দিকে সেই নাম কী ঠিকানায় রিজলভ হয় তা লিখে রাখুন। কেউ নথিভুক্ত করেনি এমন রাউটার ফিচারের উপর নির্ভর করা প্রোফাইল হলো পরবর্তী ফার্মওয়্যার হালনাগাদ পর্যন্ত অপেক্ষা করা একটি সাপোর্ট কল। ওই নোটটিই পরের ব্যক্তিকে বলে দেয় ভেতরের ব্যর্থতা পরিচিত হেয়ারপিন কেস, নাকি নতুন কিছু।