কেন একটি /32 হোস্ট রুট VPN এন্ডপয়েন্টকে পৌঁছানোযোগ্য রাখে

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

একটি ঠিকানা, টেবিলে একটি এন্ট্রি

একটি IPv4 হোস্ট রুট /32 প্রিফিক্স বহন করে এবং একটি IPv6 হোস্ট রুট /128 বহন করে, যার অর্থ এন্ট্রিটি ঠিক একটি গন্তব্য ঠিকানার সাথে মিলতে পারে। টেবিলে অন্য কিছু নড়ে না: ঢেকে রাখা সাবনেট এবং ডিফল্ট রুট যেখানে ছিল সেখানেই থাকে। সরু এন্ট্রিটি ওই ঠিকানার জন্য জেতে কারণ এর প্রিফিক্স দীর্ঘ, পরে যোগ করা হয়েছে বলে নয়।

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

ক্লায়েন্ট থেকে বাইরের দিকে এন্ট্রিটি পড়ুন

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

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

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

স্থায়ী এন্ট্রি আর রানটাইম এন্ট্রি ভিন্নভাবে ব্যর্থ হয়। রানটাইমটি সেশনের সাথে মিলিয়ে যায়, আর স্থায়ীটি রিবুট কাটিয়ে ওঠে এবং যেই গেটওয়ে আর নেই সেখানে ট্র্যাফিক পাঠিয়ে চলে।

এন্ডপয়েন্ট ব্যতিক্রম এবং রিকার্সন ফাঁদ

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

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

অ্যাপ্লিকেশন সত্যিই যে পথ ব্যবহার করে তা যাচাই করুন

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

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

পথ ভুল হলে, কিছু সম্পাদনা করার আগে ঠিক করুন প্রয়োজনটি একটি নেটওয়ার্ক না একটি ঠিকানা। একক-ঠিকানার প্রয়োজন মন্তব্য ও মালিকসহ একটি হোস্ট রুটকে ন্যায্য করে; ঘুরতে থাকা ঠিকানার সেবার দরকার ডোমেইন-ভিত্তিক রাউটিং বা সৎ সাবনেট সিদ্ধান্ত।

যে এন্ট্রিগুলো আর বাস্তব গন্তব্যের সাথে মেলে না সেগুলো সরান এবং যেগুলো রাখছেন সেগুলো টুকে রাখুন। একটি ব্যাখ্যাহীন /32 তিন মাস পরে বাগ থেকে আলাদা করা যায় না, আর পরের ব্যক্তিটি কী এর উপর নির্ভর করত না জেনেই এটি মুছে ফেলবে।