VPN রুট ক্যাশ কি আপনার পরিবর্তন লুকাচ্ছে? তিনটি জিনিস পরীক্ষা করুন

পরিবর্তন কার্যকর না হলে রুট ক্যাশ মোছাই প্রথম প্রবৃত্তি, আর আধুনিক Linux-এ এটি বৃথা শ্রম: বৈশ্বিক IPv4 রুট ক্যাশ বহু বছর আগে সরানো হয়েছে, তাই ip route show cache কিছুই ছাপে না এবং মোছার কিছু নেই। যে অবস্থা আপনাকে বোকা বানায় তা এক স্তর উপরে থাকে: একটি সকেট, একটি NAT ম্যাপিং, একটি রিজলভার বা পুরোনো প্রোফাইল আবার প্রয়োগ করা একটি নেটওয়ার্ক ম্যানেজারে। তিনটি প্রশ্ন এই কেসগুলো আলাদা করে: ভুল পথ কি নতুন ফ্লো থেকে আসছে নাকি পুরোনো সংযোগ থেকে, আপনার প্ল্যাটফর্ম কি আদৌ রুট ক্যাশ করে, এবং অবস্থাটি রাউটিংয়ে নাকি তার উপরে। ইন্টারফেস রিসেট করার আগে এগুলোর উত্তর দিন।

পরীক্ষা এক: পুরোনো পথ কি নতুন ফ্লো থেকে আসছে?

প্রতিষ্ঠিত সংযোগ যে রুট নিয়ে তৈরি হয়েছিল তা ধরে রাখে। তাই টানেলের উপর দিয়ে একটি SSH সেশন রাউটিং টেবিলের পরিবর্তন টিকে যায়, আর নতুন সেশন সঙ্গে সঙ্গে নতুন পথ নেয়, এবং তাই «পরিবর্তন কিছুই করেনি» প্রায়ই মানে «পুরোনো সকেট এখনো এটি ধরে আছে»। নতুন প্রসেস দিয়ে পরীক্ষা করুন, ইতিমধ্যে খোলা উইন্ডো দিয়ে নয়।

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

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

নতুন ফ্লো সঠিক পথ নিলে এবং পুরোনোটি পুনরুদ্ধার না হলে রাউটিং দেখা বন্ধ করুন। রুটটি ঠিক ছিল; সেশনটি পুরোনো ছিল।

পরীক্ষা দুই: আপনার প্ল্যাটফর্ম কি আদৌ রুট ক্যাশ রাখে?

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

অন্য প্ল্যাটফর্ম আলাদা, আর পরামর্শ কপি করাই এখানে ভুল হয়। Windows একটি গন্তব্য ক্যাশ রাখে যা আপনি netsh interface ip delete destinationcache দিয়ে পরিষ্কার করতে পারেন। BSD ও macOS route -n get দিয়ে প্রতি-গন্তব্য অনুসন্ধান দেখায়, আর তাদের ক্যাশ নিজের সময়সূচিতে মেয়াদোত্তীর্ণ হয়। এগুলোর একটিতে কাজ করা কমান্ড Linux-এ কিছুই করে না, তাই একই সমাধান চেষ্টা করা অর্ধেক মানুষের কাছে ব্যর্থ মনে হয়।

NAT বা conntrack টেবিল রুট ক্যাশ নয়, যদিও একই উপসর্গ তৈরি করে। আপনার পরিবর্তনের আগে অনূদিত একটি ফ্লো তার অনুবাদ ধরে রাখে, আর রাউটিং নীতি অনেক আগে সরে যাওয়ার পরও conntrack -L এটি দেখাবে। এটি বাসি অবস্থা, কিন্তু রুট মোছা এটিকে স্পর্শ করবে না।

পরীক্ষা তিন: অবস্থাটি রাউটিংয়ে, নাকি তার উপরে?

অন্য কিছু পড়ার আগে বর্তমান লুকআপ পড়ুন: গন্তব্যের জন্য ip route get, তারপর from ও সোর্স ঠিকানা সহ একই কমান্ড, তারপর ip rule show। এই তিনটি আপনার উদ্দেশ্যের সঙ্গে মিললে রাউটিং ঠিক করার স্তর নয়, আর বাসি পর্যবেক্ষণ অন্য জায়গা থেকে এসেছে।

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

তিনটি উত্তর আপনাকে কী সিদ্ধান্তে পৌঁছাতে দেয়

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

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

যদি সত্যিই কিছু মোছাতে হয়, রোগনির্ণয়ের সঙ্গে মেলা সবচেয়ে ছোট জিনিসটি মোছান: একটি প্রসেসের সকেট, একটি conntrack এন্ট্রি, রিজলভার ক্যাশ। তারপর একই নতুন-ফ্লো পরীক্ষা পুনরাবৃত্তি করুন এবং কী বদলেছে লিখে রাখুন।

আপনার নোটে তিনটি অবস্থা আলাদা রাখুন

সংরক্ষিত কনফিগারেশন, বর্তমান লুকআপ ও পর্যবেক্ষিত ফ্লো তিনটি ভিন্ন সত্য, আর সেগুলোকে «ক্যাশ»-এ মিশিয়ে ফেলাই ত্রুটিটি পুনরুৎপাদন করা কঠিন করে তোলে। রুটের মালিক প্রোফাইল বা ইউনিট, ip route get-এর আউটপুট, এবং প্রকৃত সংযোগের সোর্স ও গন্তব্য লিখুন।

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