দুটি সেলুলার সাইট, কোনো ইনবাউন্ড পোর্ট নেই: কাজ করা একটি হাব তৈরি করুন

সেলুলার আপলিংকে থাকা দুটি সাইট উভয় দিকেই একই সমস্যায় পড়ে: কোনোটিই অননুরোধিত IPv4 সংযোগ গ্রহণ করতে পারে না, তাই কোনোটিই সরাসরি টানেলে সার্ভারের ভূমিকা নিতে পারে না। যে আর্কিটেকচার কাজ করে তা মাঝখানে একটি পৌঁছানোযোগ্য তৃতীয় পক্ষ রাখে, যেখানে প্রতিটি সাইট বাইরের দিকে ডায়াল করে এবং মাঝখানটি কেবল আপনার অনুমোদিত ট্রাফিক ফরওয়ার্ড করে। সেই মাঝখানটি আপনার পরিচালিত একটি রাউটার বা পিয়ারদের পরিচয় করানো একটি পণ্য হতে পারে, আর এই দুটি এক নয়। নিচের ধাপগুলো এমনভাবে সাজানো যে প্রতিটি পরবর্তী ধাপ তার উপর নির্ভর করার আগেই প্রমাণ তৈরি করে।

কোনো সাইটেই ডায়াল করা যায় না, তাই দুটিকেই বাইরে ডায়াল করতে হবে

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

সাধারণ সেলুলার ঘটনাটি ক্যারিয়ারের অনূদিত রেঞ্জের একটি ঠিকানা এবং তার মধ্য দিয়ে একটি ডিফল্ট রুটের মতো দেখায়। এটি মেরামতের যোগ্য কোনো ত্রুটি নয়; এটিই হাবের অস্তিত্বের কারণ। আপনি খুঁজছেন এমন যেকোনো ঠিকানা যা সাইটটি আগে কথা না বলেই তৃতীয় পক্ষ পৌঁছাতে পারে।

দুটি কমান্ড আপনার সামনে থাকা সাইটটির অ্যাড্রেসিং প্রশ্নের উত্তর দেয়। সেগুলো সাইট রাউটারে চালান, তার পেছনের ল্যাপটপে নয়:

ip -4 addr show scope global
ip -6 addr show scope global

কে পিয়ারদের পরিচয় করায়, আর কে প্যাকেট বহন করে

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

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

প্রতি সাইটে একটি রুট, যার মালিক একটি পিয়ার

হাবের প্রতি সাইটে একটি টানেল, প্রতিটির পেছনে আলাদা LAN প্রিফিক্স, এবং প্রতিটি প্রিফিক্সের জন্য একটি রুট দরকার যা তার মালিককে নাম দেয়। উদাহরণে হাব 10.61.0.1, সাইট A হলো 10.61.0.11 যার LAN 10.60.10.0/24, আর সাইট B হলো 10.61.0.12 যার LAN 10.60.20.0/24। নিচের প্রতিটি রুট টানেল ইন্টারফেসের দিকে নয়, প্রিফিক্সের মালিক পিয়ারের দিকে নির্দেশ করে:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

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

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

ক্যারিয়ারের মধ্য দিয়ে প্রতিটি ম্যাপিং জীবিত রাখুন

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

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

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

দুই দিক প্রমাণ করুন, তারপর পুনরুদ্ধার প্রমাণ করুন

যাচাই দিকনির্ভর, তাই A থেকে B-তে একটি ping নকশার অর্ধেক প্রমাণ করে, ফেরার রুট সম্পর্কে কিছুই নয়। হাবে একই সোর্স-সচেতন লুকআপ দিয়ে উত্তর পথ পরীক্ষা করুন, তারপর অন্য দিক থেকে পরীক্ষাটি পুনরাবৃত্তি করুন। নতুন হ্যান্ডশেকও প্রমাণের অন্তর্গত, কারণ এক ঘণ্টা নিষ্ক্রিয় টানেল পুরোনো ম্যাপিং পরীক্ষা করতে পারে:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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