রাউটেড VPN জুড়ে IPv6 নেবার ডিসকভারি কেন ব্যর্থ হয়

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

কনফিগারেশনের আগে স্কোপ

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

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

ফাঁদ হলো অন-লিংক অনুমান

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

একক সার্ভিসের জন্য /128 সবচেয়ে কম বিস্ময়কর ব্যবস্থা এবং এটি দ্ব্যর্থতা সম্পূর্ণ দূর করে। নেবার ডিসকভারি স্পেসিফিকেশন বার্তা-সেট ও এই সিদ্ধান্ত নেওয়া অন-লিংক ফ্ল্যাগ বর্ণনা করে।

ব্রিজিং সচেতনভাবেই নিয়ম বদলায়

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

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

অ্যাপ্লিকেশন যে ঠিকানা ব্যবহার করে সেটি দিয়েই পরীক্ষা করুন

ip -6 route get দিয়ে রুট নিশ্চিত করুন, ip -6 neigh দিয়ে নেবার এন্ট্রি দেখুন, তারপর রাউটেড পথে সার্ভিসটি নিশ্চিত করুন। DNS ও ফেরতের পথ আলাদা যাচাই, আর সুস্থ নেবার এন্ট্রি এদের কোনোটিই প্রমাণ করে না।

অ্যাপ্লিকেশন যদি লিংক-লোকাল বা ডিসকভারি-ভিত্তিক গন্তব্যে জোর দেয়, তবে তা টিউনিং নয়, নকশার আলোচনা, কারণ কোনো ক্লায়েন্ট সেটিং লিংক-সীমিত প্রক্রিয়াকে রাউটার জুড়ে কাজ করাতে পারে না।

আপনার কোন নকশা আছে তা লিখে রাখুন

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

বার্তা-সেট একবার পড়লে লিংক-স্কোপ বৈশিষ্ট্যকে VPN বাগ হিসেবে ব্যাখ্যা করার প্রলোভন চলে যায়, যা এই ক্ষেত্রে সবচেয়ে ব্যয়বহুল ভুল রোগনির্ণয়।