IPv6 টানেলের প্রান্তে ping ব্যর্থ? :: ঠিকানাটি যাচাই করুন

আপনার IPv6 টানেলের এক প্রান্ত অন্য প্রান্তে ping করে, আর কেবল এক দিকেই উত্তর আসে। ইন্টারফেস চালু, রুট ঠিক দেখাচ্ছে, আর লগে কিছুই এর ব্যাখ্যা দেয় না। আপনি যে ঠিকানাটি দিয়েছেন সেটি সাবনেট-রাউটার anycast ঠিকানা, যা আদৌ কোনো হোস্ট ঠিকানা নয়, এবং দুই-প্রান্তের লিংকে এর ডেলিভারি লক্ষ্য ঠিক একটি: প্রেরক। কোনো টাইমআউট মান এটি সারায় না, কারণ ঠিকানাটি আপনি যা ভাবছেন তা করছে না।

যে লক্ষণ ঠিকানাটির দিকে ইঙ্গিত করে

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

সব-শূন্য আইডেন্টিফায়ার anycast হিসেবে সংরক্ষিত

RFC 4291 সব-শূন্য ইন্টারফেস আইডেন্টিফায়ারকে সাবনেট-রাউটার anycast ঠিকানা হিসেবে রাখে, তাই /64 যেমন 2001:db8:4a::/64 এই ঠিকানায় কোনো ব্যবহারযোগ্য হোস্ট নেই। 2001:db8:4a:: রক্ষণভাগটি নিজের জায়গার যোগ্য: রাউটার বিজ্ঞাপন ও প্রতিবেশী আবিষ্কার ওই রূপেই ঠিকানা দেয়, আর রাউটার যে প্রিফিক্স পরিবেশন করে তার হয়ে উত্তর দেয়। একটি টানেল প্রান্তে ওই মান বসালে একটি পাতাকে রাউটারের ভূমিকা দেওয়া হয়, তাই কিছুই ফিরে আসে না। প্রিফিক্সের অন্য যেকোনো আইডেন্টিফায়ার হোস্ট হিসেবে কাজ করে, তাই সমাধান সাধারণত এক অঙ্ক।

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

হোস্ট ঠিকানা বরাদ্দ করুন এবং প্রিফিক্স রুট করুন

দুই প্রান্তের জন্য ::1 এবং ::2 বেছে নিন, একটি যোগ করুন ip -6 addr add 2001:db8:4a::2/64 dev tun0, তারপর দূরের প্রিফিক্স ঠিকানার চেষ্টা না করে তা রুট করুন। 2001:db8:4a::/64 এর জন্য টানেল থেকে বেরোনো রুট দূর প্রান্তকে পৌঁছানোযোগ্য করে; একা ঠিকানাটি কেবল স্থানীয় ইন্টারফেস কনফিগার করে।

সম্পূর্ণ টানেলে তৃতীয় ধাপ আছে — ডিভাইসের মধ্য দিয়ে গ্লোবাল unicast-এর জন্য ডিফল্ট রুট, যা সবকিছু টানেলে পাঠানোর IPv6 সমতুল্য। এটি বাদ দিলে IPv4 টানেলের ভেতরে চলার সময় IPv6 ভৌত লিংক ব্যবহার করতেই থাকে, তাই হোস্ট ঠিক সেই ট্র্যাফিকই ফাঁস করে যা আপনি আচ্ছাদিত বলে ভেবেছিলেন। যাচাই করুন ip -6 route get 2001:4860:4860::8888 দিয়ে এবং উত্তর ধরে নেওয়ার বদলে এটি কোন ডিভাইসের নাম বলে তা পড়ুন।

রাউটিংয়ের আগেই multicast প্রত্যাখ্যাত

Android যাচাই করে VpnService.Builder -এর জন্য ঠিকানা ও রুট LinkAddress দিয়ে, এবং ওই কনস্ট্রাক্টর multicast সোজা প্রত্যাখ্যান করে। এটি একটি multicast প্রিফিক্স রুট হিসেবে দিলে ফলাফল রুট নয়, বরং খারাপ LinkAddress প্যারামিটারের ব্যর্থতা, যা একটি যাচাইয়ের উত্তর, নেটওয়ার্কের উত্তর নয়। প্রত্যাখ্যানটি মাধ্যমের সঙ্গে মেলে: পয়েন্ট-টু-পয়েন্ট tun ডিভাইসে লিংক-স্তরের multicast নেই, তাই তার উপর গ্রুপ রুট বসানোর কোনো ডেলিভারি মডেল নেই। গ্রুপ ঠিকানা স্ট্যাক নিজেই তৈরি ও ভোগ করে, হাতে কনফিগার করে না।

IPv6 all-nodes ও solicited-node ঠিকানা একই নিয়মের অধীনে পড়ে। ইন্টারফেস সেগুলো বহন করে কারণ স্ট্যাক সেগুলো সেখানে রেখেছে, কোনো নীতি সেগুলো চেয়েছিল বলে নয়।

টানেল এর বদলে কী বহন করতে পারে

টানেল জুড়ে multicast ডিসকভারি সরানোর জন্য দরকার এমন একটি স্তর যা গ্রুপ সদস্যতা বোঝে: একটি TAP ব্রিজ যা Ethernet সেগমেন্ট উপস্থাপন করে, অ্যাপ্লিকেশন-স্তরের রিলে, বা একটি রাউটিং প্রোটোকল যাকে স্পষ্ট করে বলা হয়েছে কোন পিয়ারগুলিতে প্রতিলিপি করতে হবে। VpnService মডেলে এর কিছুই নেই, যেখানে অ্যাপ্লিকেশন প্যাকেট পড়ে ও লেখে এবং টানেলের জন্য গ্রুপে যোগ দেওয়ার কোনো কল নেই। হয় গ্রুপ বোঝে এমন উপাদান যোগ করুন, নয়তো ডিজাইন থেকে দাবিটি বাদ দিন।

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

কিছু বরাদ্দ করার আগে তিনটি যাচাই

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

প্ল্যাটফর্ম যে রুট কখনো বসায়নি তা বেশিক্ষণ অপেক্ষা করে ডিবাগ করা যায় না, আর যে ঠিকানা কখনো হোস্ট ছিল না তা আরও ভালো ping দিয়ে সারানো যায় না।