টানেল এখনো চালু, রুট চলে গেছে: দুটি VPN ব্যর্থতা আলাদা করা

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

একটি ঘটনার মতো দেখানো তিনটি ধাপ

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

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

আগে ইনস্টল করা রুট পড়ুন

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

ip route get 10.20.5.10
ip route show 10.20.0.0/16

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

তারপর প্রোটোকলের নিজের দৃষ্টিভঙ্গি দেখুন

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

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

যখন ঘড়িগুলো মিলে না

টানেল লগ, রাউটিং লগ এবং অ্যাপ্লিকেশনের প্রথম ব্যর্থতা তাদের প্রকৃত সময় অঞ্চল ব্যবহার করে একই সময়রেখায় রাখুন। যদি প্রতিবেশী হারানো আগে আসে, তবে টানেলই রুটটি নিজের সঙ্গে নামিয়ে এনেছে। যদি প্রত্যাহার আগে আসে, তবে রাউটিং বদলেছে এবং টানেল পরে প্রতিক্রিয়া দিয়েছে। এগুলো ভিন্ন মালিকের ভিন্ন ঘটনা, আর ক্রমটাই পুরো সন্ধান।

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

লুপ ছাড়া পুনরুদ্ধার

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

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