VPN-এর মাধ্যমে IPv6: ডেলিগেট করা প্রিফিক্স ঠিকানার পুল নয়

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

ধাপ এক: আপনি কোন ভূমিকা পরিবেশন করছেন তা ঠিক করুন

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

কোনো কনফিগারেশন খোলার আগে সেই প্রশ্নের উত্তর দিন। এই ধাপের পরের সবকিছুই আপনি কোন উত্তর দিয়েছেন তার ওপর নির্ভর করে।

ধাপ দুই: একটি একক হোস্টের জন্য ঠিকানা নির্ধারণ

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

দুই প্রান্তে ঠিকানা ও রুট সারণি দিয়ে যাচাই করুন, তারপর একটি অনুরোধ পাঠান। অনুরোধটি সঠিকভাবে বেরিয়ে গেলে এবং কিছু ফিরে না এলে, ত্রুটি ক্লায়েন্টের ঠিকানায় নয়, দূরের প্রান্তের রুটে।

ধাপ তিন: টানেলের পেছনের রাউটারের জন্য ডেলিগেশন

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

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

ধাপ চার: ফেরত রুট স্পষ্ট করুন

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

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

ধাপ পাঁচ: রাউটারের পেছন থেকে যাচাই করুন

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

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

ফিরিয়ে নেওয়া

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

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