IPv6 শাখা উপসর্গ: সার্ভারে iroute-ipv6 নাকি route-ipv6?

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

দুটি নির্দেশনা, দুটি ভিন্ন কাজ

route-ipv6 একটি সাধারণ রুট স্থাপন: সার্ভার একটি কার্নেল রুট যোগ করে যা উপসর্গকে তার টানেল ইন্টারফেসের দিকে দেখায়। iroute-ipv6 একটি নির্দিষ্ট ক্লায়েন্টের প্রসঙ্গের অন্তর্গত এবং অভ্যন্তরীণ মালিকানা ঘোষণা করে, তাই ডেমন জানে যে ওই উপসর্গের ট্রাফিক একটি নির্দিষ্ট ক্লায়েন্টের কাছে পাঠানো উচিত, কার্নেল রুট যে পিয়ারকে আকস্মিকভাবে নাম দেয় তার কাছে নয়।

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

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

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

কোনটি কোথায় যায়

রুট সার্ভারের পরিচালিত কনফিগারেশনে যায়, যেখানে এটি ওই সার্ভার প্রক্রিয়ার জন্য প্রযোজ্য। iroute ক্লায়েন্ট-নির্দিষ্ট ফাইলে যায়, যা শাখা ডিভাইসের প্রমাণিত পরিচয়ের নামে।

যে ফাইল নাম প্রকৃত পরিচয়ের সাথে মেলে না তা কখনও পড়া হয় না, আর লক্ষণ হুবহু অনুপস্থিত iroute-এর মতো। সার্ভার যে পরিচয় প্রমাণ করেছে তা যাচাই করুন, তারপর ফাইল নাম অক্ষর ধরে ধরে যাচাই করুন।

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

পুল ও শাখা উপসর্গ আলাদা রাখুন, কারণ তাদের ওভারল্যাপ এমন ধাঁধা তৈরি করে যা কোনো নির্দেশনা সমাধান করতে পারে না।

অন্য ক্লায়েন্টের কী দরকার

যে দ্বিতীয় ক্লায়েন্টকে ওই শাখায় পৌঁছাতে হবে তার মালিকানা নয়, ঘোষণা দরকার। উপসর্গ আপনি যে ক্লায়েন্টদের চান তাদের কাছে পাঠান, আপনার কনফিগারেশনের সাথে মানানসই ক্লায়েন্ট বা গ্রুপ প্রসঙ্গে।

এটি শাখার নিজের কাছে পাঠাবেন না, কারণ ওই ডিভাইসের কাছে উপসর্গ ইতিমধ্যে সংযুক্ত নেটওয়ার্ক হিসেবে আছে।

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

শাখা ডিভাইসে ফেরার পথ

মালিকানা তখনই সাহায্য করে যখন শাখা প্যাকেট ফরওয়ার্ড করে এবং তার LAN জবাব দিতে জানে। শাখা ডিভাইসে IPv6 ফরওয়ার্ডিং সক্রিয় করুন, এবং নিশ্চিত করুন যে তার LAN-এর হোস্টরা VPN পুলের ট্রাফিক ফিরে শাখার দিকে পাঠায়, পুল না জানা ডিফল্ট রুটের দিকে নয়।

সেই ফেরার পথ IPv6-তে সেই হারানো রুট সমস্যার সমতুল্য যা মানুষ IPv4-তে ভোগে।

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

যখন জোড়া তবুও যথেষ্ট নয়

কিছু স্থাপনা এই পথ একেবারেই ব্যবহার করে না। কার্নেলের ডেটা পথ এবং প্রোডাক্ট-পরিচালিত সার্ভারদের নিজস্ব সমর্থিত রুট হ্যান্ডলিং আছে, আর userspace উদাহরণ সরাসরি স্থানান্তরিত নাও হতে পারে।

অন্যের জন্য লেখা গাইড থেকে নির্দেশনা কপি করার আগে নিশ্চিত করুন আপনার বিল্ড কোন ডেটা পথ ব্যবহার করে।

শেষে, ঠিকানার পরিধি মনে রাখুন: অনন্য স্থানীয় উপসর্গ যেমন fd00:7a::/64 ডিজাইন অনুযায়ী ব্যক্তিগত এবং সার্বজনীন IPv6 পৌঁছানোর বিষয়ে কিছু বলে না। এটিকে অভ্যন্তরীণ প্রবেশ হিসেবে গণ্য করুন, আর ইন্টারনেটে বাইরে যাওয়াকে নিজস্ব নীতি সহ আলাদা বিষয় রাখুন।