আপনার /64 ভাগ করলে IPv6 VPN ক্লায়েন্টদের কাছে রুট হয় না

ক্লায়েন্ট একটি গ্লোবাল IPv6 ঠিকানা দেখায়, হ্যান্ডশেক সম্পন্ন হয়েছে, এবং ইন্টারনেট থেকে কিছুই ফিরে আসে না। পুল সেটিং সঠিক দেখায় কারণ এটি সত্যিই সঠিক; ঠিকানাটি বৈধ এবং টানেল এটি বহন করে। যা ব্যর্থ হয় তা হলো ডেলিভারি, আর ডেলিভারি নির্ভর করে VPN সার্ভারের উপরে নেওয়া একটি সিদ্ধান্তের উপর, যাতে কোনো ক্লায়েন্ট-সাইড কনফিগারেশন প্রভাব ফেলতে পারে না।

মিথ: আপনার /64-এর একটি অংশ ইতিমধ্যেই পৌঁছানো যায়

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

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

সম্পূর্ণ ব্যর্থতা এটাই: সামনের দিক কাজ করে কারণ আপনার সার্ভার তা পাঠায়, আর ফেরতের দিকটি এক হপ দূরেই মরে যায় কারণ আপস্ট্রিম কখনো জানতে পারেনি ক্লায়েন্টটির অস্তিত্ব আছে।

অন-লিংক ডেলিভারি আসলে কী দাবি করে

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

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

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

রাউটেড ডেলিভারি কী দাবি করে

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

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

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

ঠিক করতে হবে দুটি স্বাধীন রুট

পুল প্রিফিক্স এবং ক্লায়েন্টের নিজের ডিফল্ট রুট আলাদা সেটিংস, আর এদের গুলিয়ে ফেলা আংশিক সংযোগ তৈরি করে যা ভাঙা টানেলের মতো দেখায়। পুল সার্ভারকে বলে কোন ঠিকানাগুলো বিতরণ করতে হবে। ক্লায়েন্টের রুট ঠিক করে ক্লায়েন্ট কোন গন্তব্যগুলো আদৌ টানেলে পাঠাবে।

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

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

আপনি যে নীতিই প্রয়োগ করুন, IPv6 যে নিয়ন্ত্রণ ট্রাফিকের উপর নির্ভর করে তা চালু রাখুন। Packet Too Big বার্তাগুলো কেবল TCP ও UDP অনুমোদনকারী ফায়ারওয়ালের চিরাচরিত বলি, এবং সেগুলো ফেলে দিলে এমন সংযোগ তৈরি হয় যা প্রতিষ্ঠিত হয়েই বড় স্থানান্তরে আটকে যায়।

রাউটার বিজ্ঞাপন তৃতীয় চলমান অংশ। যদি গেটওয়ে আপলিংকে বিজ্ঞাপন দেওয়া শুরু করে, তবে ক্লায়েন্ট ও প্রতিবেশীরা অন-লিংক প্রিফিক্স সম্পর্কে যা ভাবে তা বদলে যেতে পারে, যা আপনি এইমাত্র নথিভুক্ত করা ডিজাইনটি নিঃশব্দে বাতিল করে দিতে পারে।

ডিজাইনটি নথিভুক্ত করুন যাতে পুনর্নির্মাণ তা পুনরুৎপাদন করে

তিনটি বস্তু আলাদাভাবে লিখুন: ক্লায়েন্ট বরাদ্দ, ক্লায়েন্টের গন্তব্য রুট, এবং বরাদ্দের জন্য আপস্ট্রিমের ডেলিভারি পদ্ধতি। যার তিনটিই আছে সে স্থাপনাটি পুনর্নির্মাণ করতে পারে; যার কেবল পুল সেটিং আছে সে মূল বাগটিই পুনরুৎপাদন করবে।

তারপর ফেরত দিকটি স্পষ্টভাবে পরীক্ষা করুন, এমন একটি প্যাকেট দিয়ে যা বাইরে থেকে ফিরে আসতে হবে। openvpn(8) ম্যানুয়াল server-ipv6 ও redirect অপশনগুলো কভার করে, আর আপনার প্রদানকারীর রাউটিং নিশ্চিতকরণ ম্যানুয়াল যে অর্ধেক কভার করতে পারে না তা কভার করে।