IPsec গেটওয়ে থেকে পিং আলাদা সোর্স অ্যাড্রেস ব্যবহার করে

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

পিং যে তিনটি ভিন্ন প্রশ্নের উত্তর দিতে পারে

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

আগে প্রশ্নটি বেছে নিন। নইলে ব্যর্থ পিং আপনার আগে থেকে থাকা যে-কোনো তত্ত্বের পক্ষে প্রমাণ হয়ে যায়।

গেটওয়ে কেন এমন অ্যাড্রেস বেছে নেয় যা আপনি আশা করেননি

কোনো গন্তব্যে পিং করলে লোকাল স্ট্যাক তার সঙ্গে মেলা রুট থেকে সোর্স বেছে নেয়। রুট-ভিত্তিক টানেলে সেটি হতে পারে টানেল ইন্টারফেসের লিংক অ্যাড্রেস, যা অনেক সাইট ডিজাইনে পয়েন্ট-টু-পয়েন্ট হপের জন্য বেছে নেওয়া 169.254.x.x জোড়া। এই অ্যাড্রেসগুলো লিংক কাজ করার জন্যই আছে; দূর প্রান্তে এগুলো অ্যাপ্লিকেশন-সোর্স নেটওয়ার্ক হিসেবে ঘোষণা করা হয় না।

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

সোর্স সচেতনভাবে বেছে নিন

নিয়ন্ত্রিত Linux গেটওয়েতে এমন সোর্স বেছে নিন যা ইতিমধ্যে লোকালি অ্যাসাইন করা আছে: ping -c 4 -I 10.30.0.1 10.40.0.20। এখানে অ্যাড্রেসগুলো উদাহরণের জন্য, তাই গেটওয়ের আসল ভেতরের অ্যাড্রেস ও আসল দূরের গন্তব্য বসান, এবং নিশ্চিত করুন আপনার বেছে নেওয়া সোর্স এই ডিভাইসেরই এবং সাইট পলিসি তা গ্রহণ করে।

টেস্টের জন্য কোনো ওয়ার্কলোডের অ্যাড্রেস ধার করবেন না। গেটওয়েতে অ্যাসাইন করা নেই এমন হোস্টের ছদ্মবেশ তৈরি করে এমন ফলাফল যা কেউ পুনরুৎপাদন করতে পারে না, আর কিছু স্ট্যাকে এটি এমনভাবে ব্যর্থ হয় যা টানেলের ত্রুটির মতো দেখায়।

শুধু রিকোয়েস্ট নয়, রিপ্লাই পথও পড়ুন

দূরের গন্তব্যে আসলে কোন সোর্স পৌঁছায় তা যাচাই করুন, পথে কোনো ইচ্ছাকৃত ট্রান্সলেশন থাকলে তাও ধরে। তারপর দূর প্রান্তের সেই সোর্সে ফেরার রুট এবং তা যে সিলেক্টর বা পলিসি অনুমোদন করে তা যাচাই করুন। অপ্রত্যাশিত সোর্স নিয়ে আসা রিকোয়েস্ট রাউটিং ও পলিসির প্রশ্ন, ক্রিপ্টোগ্রাফির নয়।

এখানেই আরেকটি পিংয়ের চেয়ে প্যাকেট ক্যাপচার বেশি সহায়ক: এটি দেখায় দূর প্রান্ত কোন সোর্স দেখেছে, আর সেই অ্যাড্রেসেই তার উত্তর পৌঁছাতে হবে।

তারপর ওয়ার্কলোড পরীক্ষা করুন

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

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

শুধু একটি ডায়াগনস্টিক উত্তর পেতে 169.254.0.0/16-এর জন্য একটি ব্যাপক রুট যোগ করবেন না। এতে বিভ্রান্তিকর টেস্টের বদলে স্থায়ী রাউটিং সিদ্ধান্ত তৈরি হয়, আর পরের ব্যক্তি প্রসঙ্গ ছাড়াই তা উত্তরাধিকার সূত্রে পান।