WireGuard 5G শাখা: শাখাই হাবের সঙ্গে সংযোগ করুক

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

এটি সচেতনভাবে কনফিগার করুন, তারপর যে অংশটি মানুষ কাজ করে বলে ধরে নেয় সেটি যাচাই করুন। দুই ধাপেই কয়েক মিনিট লাগে, আর এই নকশাগুলো সাধারণত দ্বিতীয় ধাপেই ব্যর্থ হয়।

কোন পক্ষ স্থির এন্ডপয়েন্ট ধরে রাখে

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

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

শাখাকে এমন কনফিগারেশন দিন যা নম্বর বদল সহ্য করে

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

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

পঁচিশ সেকেন্ড হলো NAT ম্যাপিং সচল রাখার জন্য প্রায়ই উদ্ধৃত উদাহরণ, প্রতিটি পিয়ারের জন্য বাধ্যবাধকতা নয়। আপনি বাস্তবে যে ম্যাপিং টাইমআউট দেখেন তা থেকে এটি নির্ধারণ করুন, এবং মনে রাখুন ইন্টারফেস চালু থাকা পর্যন্ত এটি মিটারযুক্ত লিংকে ট্রাফিক তৈরি করে।

হাবে শাখা পিয়ারের অনুমোদিত প্রিফিক্সগুলোকে শাখা যা পাঠাবে তার সবকিছু ঢাকতে হবে। অনুপস্থিত প্রিফিক্স দূর প্রান্তে রাউটিং ব্যর্থতার মতো আচরণ করে এবং কোনো পক্ষেই সতর্কতা তৈরি করে না, তাই প্রথম প্রকৃত প্যাকেটের আগেই এটি পর্যালোচনা করা উচিত। প্রথম সংযোগের আগে হাবের অনুমোদিত প্রিফিক্সগুলোর সঙ্গে শাখার ইন্টারফেস ঠিকানাগুলো মিলিয়ে দেখুন।

ম্যাপিং ও ফলওভার যাচাই করুন

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

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

তারপর যে ব্যর্থতার জন্য এই নকশা তৈরি হয়েছে, তা পরীক্ষা করুন। প্রাথমিক WAN টেনে খুলে ফেলুন এবং নিশ্চিত করুন যে হাবের দিকে শাখার অন্তর্নিহিত রুট এখন সেলুলার ইন্টারফেস দিয়ে যায়। একটি টানেল ভাঙা ভৌত পথ মেরামত করতে পারে না, তাই মৃত আপলিংকের দিকে তাক করা বাইরের রুট হ্যান্ডশেক টাইমআউট তৈরি করে যা হুবহু হাবের সমস্যার মতো দেখায়।

যদি বাইরের পথ স্পষ্টভাবে বাঁধা বা পলিসি-রাউট করা থাকে, ফলওভারে সেটিও অন্তর্ভুক্ত করতে হবে। সঠিকভাবে পড়া যায় এমন নকশা আর বিদ্যুৎবিভ্রাট সহ্য করা নকশার মধ্যকার এই ফাঁকটাই সাধারণত একমাত্র অনুপস্থিত জিনিস।

এই নকশা কী সমাধান করে না

এখানে কিছুই শাখার দিকে ভিতরে আসা সংযোগের অনুমতি দেয় না। যদি সদর দপ্তরের কোনো কিছুকে সেলুলার সাইটে ডায়াল করতে হয়, তবে ওই প্রয়োজনটির জন্য টানেলের অভিমুখ ভুল, আর ডায়নামিক DNS কেবল একটি নাম হালনাগাদ করে। প্রোভাইডারের অনুবাদ, আগত পলিসি এবং ক্লায়েন্টের এন্ডপয়েন্ট রিফ্রেশ সবই পথ আটকে থাকে, আর বদলে যাওয়া রেকর্ড ক্যারিয়ার-গ্রেড NAT খুলতে পারে না।

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

রানবুকে চারটি জিনিস লিখুন: কে শুরু করে, কোন প্রিফিক্সগুলো অনুমোদিত, কীপঅ্যালাইভ কতক্ষণ, এবং প্রাথমিক লিংক পড়ে গেলে কী হয়। ভবিষ্যতের অপারেটরের রাত তিনটায় সত্যিই যে লাইনগুলো দরকার, সেগুলোই এই লাইনগুলো।