ICMP রিডাইরেক্ট বনাম আপনার VPN রুট: আসলে কী বদলায়

যে ফ্লো টানেল পেরোবে তার পরবর্তী হপ আলাদা হয়ে যায়, আর কেউ ক্যাপচারে একটি ICMP রিডাইরেক্ট দেখতে পায়। এটি একটি অনুমান, রোগনির্ণয় নয়। রিডাইরেক্ট হলো আরও ভালো পরবর্তী হপ সম্পর্কে রাউটারের প্রস্তাব, আর হোস্ট তা মানবে কি না তা নির্ভর করে প্ল্যাটফর্ম, ইন্টারফেস ও ঠিকানা-পরিবার অনুযায়ী আলাদা হওয়া সেটিংসের উপর।

রিডাইরেক্ট হলো রাউটারের কাছ থেকে আসা একটি প্রস্তাব

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

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

এই পার্থক্যেই বেশিরভাগ রিডাইরেক্ট তদন্ত ভুল পথে যায়।

IPv4 ও IPv6 এটি ভিন্নভাবে পৌঁছে দেয়

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

নীতির নবগুলোও আলাদা, তাই কোনো হোস্ট IPv4 রিডাইরেক্ট গ্রহণ করে IPv6 উপেক্ষা করতে পারে, বা উল্টোটা।

প্রসঙ্গত ফ্লোটি যদি দুটোর যেকোনোটি ব্যবহার করতে পারে, তবে দুটি পরিবারই যাচাই করুন।

গ্রহণযোগ্যতা হোস্টের নীতি, নেটওয়ার্কের বাস্তবতা নয়

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

নিরাপদ-রিডাইরেক্ট সেটিংস আরও সীমিত করে দেয় কোন গেটওয়েগুলোকে বিশ্বাস করা যাবে।

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

রিডাইরেক্ট যা ব্যাখ্যা করতে পারে না

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

পুরোনো ক্যাপচার হলো অন্য ফাঁদ, কারণ নেটওয়ার্ক বদলানো ক্লায়েন্টের স্থানীয় গেটওয়ে আলাদা।

আগের সংযোগের পুরোনো রিডাইরেক্ট বর্তমান পথ সম্পর্কে কিছুই ব্যাখ্যা করে না, তাই এখন কোন ইন্টারফেস নিয়ন্ত্রণ-ট্রাফিক পাচ্ছে তা লিখে রাখুন।

টানেলকে দোষ দেওয়ার আগে রুট যাচাই করুন

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

একটি সুরক্ষিত পথ নিঃশব্দে অসুরক্ষিত হয়ে যাওয়ার কারণ কখনোই রিডাইরেক্ট হওয়া উচিত নয়, এজন্যই গ্রহণ-নীতি নকশা-পর্যালোচনায় থাকে। RFC 792-এর সংজ্ঞা IPv4 বার্তা কী বলতে পারে তার প্রামাণ্য উৎস হিসেবে টিকে আছে।

রুট লুকআপ ও ক্যাপচারের সময়-স্ট্যাম্প একসঙ্গে লিখুন, পরের ব্যক্তি আপনার সিদ্ধান্ত পুনরুৎপাদন করতে পারবে।