দুটি আপলিংক fe80::1 ভাগ করে নিলে IPv6 নীতি রাউটিং

আপনার দুটি আপলিংক আছে, এবং ip -6 route show দুইটিতেই একই পরবর্তী হপ দেখায়: default via fe80::1 dev uplink0 এবং default via fe80::1 dev uplink1। এটি নকল ঠিকানার দ্বন্দ্ব নয়, এবং শুধু পরবর্তী হপ fe80::1 একটি নীতি টেবিলে কপি করলে কার্নেল বুঝতে পারে না আপনি কোন লিংক চেয়েছেন। আসল প্রশ্নটি উপসর্গটি যতটা ইঙ্গিত দেয় তার চেয়ে সংকীর্ণ: দ্বিতীয় টেবিলের কি একটি লিংক দরকার নাকি দুটোই, এবং রিবুটের পরে কী সেই রুটগুলোকে বাঁচিয়ে রাখে। ক্রমান্বয়ে যাচাই করা তিনটি শর্ত এর বেশিরভাগটাই মিটিয়ে দেয়।

একই fe80::1 আসলে দুটি আলাদা প্রতিবেশী

লিংক-লোকাল ঠিকানা একটি লিংকেই সীমিত, তাই fe80::1 দুইবার ছাপা একটি ঠিকানা নয়; এটি দুটি প্রতিবেশী যারা কেবল একটি সাফিক্স ভাগ করে। জোন ইনডেক্স হলো হোস্টের বলা উপায় কোনটি সে বোঝাচ্ছে, তাই fe80::1%uplink0 এবং fe80::1%uplink1 কার্নেলের কাছে আলাদা গন্তব্য, এবং সেই সাফিক্স কখনো দূরের রাউটারে যায় না। RFC 4007 এর পেছনের জোন মডেল বর্ণনা করে, আর এজন্যই একটি নীতি টেবিলকে প্রতিটি লিংক-লোকাল পরবর্তী হপের সঙ্গে ডিভাইস বহন করতে হয়।

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

ডিভাইসটি সরালে রুটটি লেখার অযোগ্য হয়ে যায়। ip -6 route add default via fe80::1 table 200 গেটওয়ে রিজলভ করতে পারে না, এবং iproute2 এটি Error: Nexthop has invalid gateway. দিয়ে প্রত্যাখ্যান করে; dev uplink0 যোগ করুন এবং কমান্ডটি সফল হয়, কারণ ডিভাইসই পরবর্তী হপকে ওই দুটি প্রতিবেশীর একটিতে পিন করে। ডিভাইস আপনাকে যা বলতে পারে না তা হলো uplink0 এই টেবিলের জন্য সঠিক লিংক কি না, আর অন্য হোস্ট থেকে কপি করা রুট সেই হোস্টের ইন্টারফেসের নামও সঙ্গে আনে, আর ঠিক এখান থেকেই আসল ভুলগুলো আসে।

শর্ত এক: টেবিলে একটি লিংক না দুটি

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

সেই দ্বিতীয় ক্ষেত্রে নিয়ম ঠিক করে কখন একটি টেবিল জিজ্ঞাসা করা হয়, আর রুট ঠিক করে এরপর প্যাকেট কোথায় যায়:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

কোনো একটি বস্তুই অন্যটির বিকল্প নয়, এবং কেবল একটি ডিফল্ট রাখা টেবিলও তার গেটওয়ে রিজলভ করতে ব্যর্থ হতে পারে। যদি যোগ করা প্রত্যাখ্যাত হয়, বা রুটটি উপস্থিত কিন্তু অব্যবহারযোগ্য হয়, তবে ওই ইন্টারফেসের সংযুক্ত প্রিফিক্সটি একই টেবিলে রাখুন, অথবা প্রিফিক্সটি অন্যত্র রাউট হলে হপটিকে onlink হিসেবে চিহ্নিত করুন। উপরের ব্লকে 2001:db8:100::/48 uplink1-এ ওই সংযুক্ত প্রিফিক্সের প্রতিনিধি, কোনো ইচ্ছামতো গন্তব্যের নয়। fwmark নিয়ম কেবল এমন চিহ্ন খরচ করে যা অন্য কিছুকে বসাতে হয়, ফরওয়ার্ডিং পথে nftables বা iptables নিয়ম থেকে বা সকেটে SO_MARK থেকে, তাই চিহ্নের উৎস ছাড়া কপি করা ব্লক কিছুর সঙ্গে মেলে না।

শর্ত দুই: মেট্রিক মৃত প্রদানকারী শনাক্ত করে না

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

টেবিল তৈরি হওয়ার পর পছন্দটি যাচাই করুন, এবং যেভাবে কার্নেল দেখবে সেভাবেই যাচাই করুন। ip -6 route get 2001:db8:100::1 যে রুটটি ব্যবহার হবে সেটি ছাপায়, ডিভাইস ও নির্বাচিত সোর্স ঠিকানাসহ, এবং এটি নীতি নিয়ম মানে। ভুল আপলিংকের সোর্স ঠিকানা হলো সাধারণ সংকেত যে একটি নিয়ম আপনার প্রত্যাশার আগেই মিলে গেছে।

শর্ত তিন: কে স্থায়িত্বের মালিক তা ঠিক করুন

ip -6 route add দিয়ে যোগ করা রুট রিবুট পর্যন্ত বা কিছু তা ফ্লাশ করার আগ পর্যন্ত টেকে। রাউটার বিজ্ঞাপন থেকে শেখা ডিফল্ট একটি লাইফটাইম বহন করে এবং রাউটার তা প্রত্যাহার করতে পারে, অন্যদিকে হাতে যোগ করা ডিফল্ট নিজে থেকে কখনো মেয়াদোত্তীর্ণ হয় না। দুটিকে এক টেবিলে মেশানোই হলো সেই পথ যেখানে একটি পুরোনো স্থায়ী রুট নতুন বিজ্ঞাপিত রুটকে ছাড়িয়ে যায়, যে আপলিংকের কথা এটি বলত সেটি বহু আগে বন্ধ হয়ে যাওয়ার পরেও।

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

অন্য হোস্টের জন্য ফরওয়ার্ড করা রাউটারে টেবিলকে দোষ দেওয়ার আগে net.ipv6.conf.all.forwarding দেখুন। ফরওয়ার্ডিং বন্ধ থাকলে অন্য নেটওয়ার্কে ঠিকানা করা প্যাকেট বাদ পড়ে, টেবিল 201 যতই সঠিক হোক।

নকশাটি লিখে রাখুন যাতে পরের ব্যক্তি এটি নিরীক্ষা করতে পারেন

কেবল fe80::1 সংরক্ষণ করা একটি তালিকা গুরুত্বপূর্ণ ক্ষেত্রগুলো ফেলে দেয়। গন্তব্য, পরবর্তী হপ, ডিভাইস, টেবিল ও মেট্রিক একসঙ্গে লিখুন, সঙ্গে প্রতিটি রুট কোথা থেকে এসেছে—বিজ্ঞাপিত, ম্যানেজার-উৎপন্ন বা স্ট্যাটিক। পরে কেউ জিজ্ঞাসা করলে দ্বিতীয় আপলিংকটি সত্যিই ট্রাফিক বহন করছে কি না, সেই রেকর্ড অনুমান ছাড়াই উত্তর দেয়।

টেবিলটিকে সমাপ্ত বলার আগে ip -6 neigh show dev uplink0 দিয়ে প্রতিবেশী নিশ্চিত করুন, ক্রমবিন্যাসের দুর্ঘটনার জন্য ip -6 rule show আবার পড়ুন, এবং ডিফল্ট রুট নেওয়া পিংয়ের বদলে নিয়মের সঙ্গে মেলে এমন ট্রাফিক দিয়ে পরীক্ষা করুন। তারপর ইচ্ছাকৃতভাবে একটি আপলিংক নামিয়ে দিন এবং দেখুন কার্নেল কোন রুটে ফিরে যায়; উত্তরটি আপনার লেখা রুটের সঙ্গে মেলা উচিত।