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

পুরোনো টুকরোগুলো আপনি লক্ষ্য করার আগেই ভুল ছিল। কেবল খুলে ফেলা শুধু সেগুলোকে দৃশ্যমান করেছে।

কার্নেলকে জিজ্ঞাসা করুন প্যাকেট কোথায় যাবে

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

লুকআপটি দুবার চালান, একবার পাবলিক ঠিকানার জন্য আর একবার অভ্যন্তরীণ ঠিকানার জন্য, কারণ স্প্লিট-টানেল নীতি একটি ঠিকানাকে সৎভাবে রুট করতে পারে আর অন্যটিকে ফেলে দিতে পারে।

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

রিজলভারও মৃত লিংকটি ধরে রাখে

systemd-resolved হোস্টে DNS সার্ভারগুলো একটি বৈশ্বিক তালিকার বদলে লিংকের অন্তর্গত। যে VPN লিংক নেমে গেছে সেটি কিছু সময় নিজের সার্ভারসহ নিবন্ধিত থাকতে পারে, আর তখন প্রতিটি লুকআপ এমন ঠিকানার জন্য অপেক্ষা করে যা কখনো উত্তর দেবে না। এই বিলম্ব মৃত নেটওয়ার্কের মতো লাগে এবং মানুষকে রুটের দিকে তাকাতে পাঠায় যখন রুট ঠিকই আছে।

resolvectl status
resolvectl query intranet.example.com

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

রেজিস্ট্রেশন ঠিক করুন, নয় /etc/resolv.conf। বর্তমান Ubuntu ও Fedora ইনস্টলেশনে ওই পথটি রিজলভারের রানটাইম অবস্থার একটি সিমলিংক, তাই সম্পাদনা হয় উপেক্ষা হয়, নয়তো পরের নেটওয়ার্ক ইভেন্টে পুনর্লিখিত হয়।

VPN কখনো নিজে থেকে শুরু হয় না

NetworkManager একটি বেস সংযোগের উপরে VPN তোলে এবং কোন বেসটি অনুসরণ করতে হবে তা ওই বেসের connection.secondaries থেকে শেখে। সংযোগ সেটিংস রেফারেন্স স্পষ্টভাবে বলে যে VPN প্রোফাইলের জন্য অটোকানেক্ট বাস্তবায়িত নয়। এই শ্রেণির ব্যর্থতার পেছনের পুরো প্রক্রিয়া এটাই: বেস বদলান, আর VPN-কে হাতে আবার জোড়া লাগাতে হবে বা পুনরায় সক্রিয় করতে হবে।

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

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

আপগ্রেড কোনো বার্তা ছাড়াই সেটিংস ফেলে দিতে পারে

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

হাতে লেখা হুকগুলোও সরে যায়। পুরোনো ক্রমের একটি অনুমেয় মুহূর্তে রুট ইনস্টল করা স্ক্রিপ্ট এখন ইন্টারফেস তৈরির আগে চালাতে পারে, বা ক্লায়েন্টের সময় শেষ হওয়ার পরে।

লাইভ প্রোফাইলকে আপনি যে প্লাগইন সত্যিই রাখেন তার সাথে মিলিয়ে দেখুন, আপনার মনে থাকা আচরণের সাথে নয়। কোনো কী ডকুমেন্টেশন থেকে চলে গেলে পুরোনো প্রপার্টি ফেরানোর বদলে কাজটি একটি ডিসপ্যাচার স্ক্রিপ্ট বা সমর্থিত বিকল্পে সরান।

তিনটি অবস্থা, তিনটি আলাদা মেরামত

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

What the lookup showsWhat it meansRepair
A default route via a device that exists but is unusedLeftover route from an earlier activationRemove the stale entry, or bounce the profile that installed it
A tunnel device with no client processThe client skipped its cleanupFix the disconnect path, then clear the leftover device state
No tunnel device and no active profileMissing base connection or broken pairingBring up the base, then pair the VPN with it again

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

সম্পর্কিত নিবন্ধ