নিহত openconnect: রুট আর DNS এখনও টানেলের দিকেই ইশারা করছে
মরা openconnect প্রসেস রুট আর রিজলভার এন্ট্রি ইনস্টল করা রেখে যেতে পারে। শাটডাউন পথ ধরে হাঁটুন, আপনার বিল্ড যে সিগন্যাল ডকুমেন্ট করে সেটি পাঠান, তারপর পরিষ্কার করুন।
টানেল বন্ধ, কিন্তু মেশিন এখনও আচরণ করছে যেন এটি চালু আছে: একটি লুকআপ টাইমআউট হওয়া পর্যন্ত ঝুলে থাকে, আর একটি রুট এমন ইন্টারফেসের দিকে দেখায় যা আর নেই। এটি এমন একটি openconnect প্রসেসের স্বাক্ষর যা তার ডিসকানেক্ট হেল্পার চালানো ছাড়াই মারা গেছে। এটি যে নেটওয়ার্ক অবস্থা তৈরি করেছিল তা এখনও ইনস্টল করা আছে, এবং সিস্টেমের অন্য কিছু জানে না কীভাবে তা সরাতে হয়।
যে ক্রমে অবস্থাটি তৈরি হয়েছিল সেই ক্রমে মেশিনটি হাঁটুন: প্রসেস, লিংক, রুট, রিজলভার। প্রতিটি ধাপ বলে দেয় ক্লায়েন্ট সত্যিই চলে গেছে নাকি শুধু আপনার টার্মিনাল থেকে বিচ্ছিন্ন হয়েছে, আর সেই পার্থক্যই ঠিক করে আপনি আদৌ কিছু মেরামত করবেন কি না।
কনফিগারেশন দিয়ে নয়, প্রসেস দিয়ে শুরু করুন
একটি টার্মিনাল খুলুন এবং কোনো রুটে হাত দেওয়ার আগে জিজ্ঞাসা করুন কী এখনও চলছে। pgrep -a openconnect প্রতিটি ইনস্ট্যান্স তার আর্গুমেন্টসহ তালিকা করে, যা pid ফাইল এবং তাকে দেওয়া স্ক্রিপ্ট দেখায়। যে প্রসেস আপনি আশা করেননি সেটি যেকোনো লগের চেয়ে দ্রুত ফ্যান্টম টানেল ব্যাখ্যা করে।
যদি কিছু না চলে, লিংকটি দেখুন। ip link show tun0 বলে দেয় ইন্টারফেসটি টিকে গেছে কি না, এবং ip route show dev tun0 এখনও তার সাথে বাঁধা রুটগুলো তালিকা করে। তারপর রিজলভারটি পরীক্ষা করুন resolvectl status। পরিবর্তন করার আগে তিনটি আউটপুটই লিখে রাখুন, কারণ সেই রেকর্ডই পরে পুরোনো এন্ট্রি আর নতুন এন্ট্রির পার্থক্য করতে দেয়।
যে ইন্টারফেস চলে যায় সে সাধারণত তার রুটগুলোও সাথে নিয়ে যায়। লিংকের পরেও যে রুট টিকে থাকে তার মানে সাধারণত প্রসেসটি এখনও জীবিত বা দ্বিতীয় কোনো ক্লায়েন্ট ডিভাইসটির মালিক।
হেল্পার স্ক্রিপ্টই পরিবর্তনগুলো ফিরিয়ে নেয়
openconnect নিজে ইন্টারফেস, রুট বা রিজলভার এন্ট্রি সরায় না। এটি একটি বাইরের হেল্পার ডাকে, /etc/vpnc/vpnc-script একটি upstream বিল্ডে এবং /usr/share/vpnc-scripts/vpnc-script Debian ও Ubuntu প্যাকেজে, এবং বেছে নেওয়া হয় -s দিয়ে। যে স্ক্রিপ্ট টানেল তোলে সেটিই তা ভেঙে ফেলে।
যদি প্রসেসটি সেই হেল্পার না ডেকে বেরিয়ে যায়, অবস্থাটি থেকে যায়। OpenConnect ম্যানুয়াল স্পষ্টভাবে বলে যে স্ক্রিপ্ট ছাড়া রাউটিং আর নেম সার্ভিস ঠিকভাবে কাজ করবে না, এবং হেল্পারকে সেই উপাদান হিসেবে বর্ণনা করে যা প্রস্থানের সময় ইন্টারফেসের অবস্থা ভেঙে ফেলে। এজন্যই ক্লায়েন্ট চালু করার সময় পথটি গুরুত্বপূর্ণ, যখন আপনি এটি চালান -s দিয়ে।
কোন সিগন্যাল সেই পথে পৌঁছায় তা সংস্করণে সংস্করণে বদলেছে। 7.06 ম্যানুয়াল SIGTERM-কে তাৎক্ষণিক প্রস্থান হিসেবে ধরে, যা স্ক্রিপ্ট বাদ দেয়। বর্তমান বিল্ডগুলো INT আর TERM-কে পরিষ্কার থামা হিসেবে ডকুমেন্ট করে, যেখানে সেশন লগঅফ হয় এবং হেল্পার চলে। আপনার কাছে যে বাইনারি সত্যিই আছে তার SIGNALS অংশ পড়ুন, দুই আচরণের যেকোনোটি ধরে নেওয়ার বদলে।
man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'
আপনার বিল্ড যে সিগন্যাল ডকুমেন্ট করে সেটি পাঠান
সিগন্যাল জানার পর প্রসেসটি প্যাটার্ন দিয়ে নয়, pid দিয়ে থামান।
pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"
তারপর exit status-এ ভরসা না করে প্রথম বিভাগের তিনটি পরীক্ষা আবার করুন। ip link show tun0 ব্যর্থ হওয়া উচিত, ip route show dev tun0 কিছু প্রিন্ট করা উচিত নয়, এবং resolvectl status আর VPN লিংক তালিকা করা উচিত নয়।
SIGHUP থামানোর বোতাম নয়: এটি সংযোগ বিচ্ছিন্ন করে, স্ক্রিপ্ট চালায় এবং সেশনটিকে পুনরায় চালুযোগ্য রাখে --cookie। SIGUSR2 তাৎক্ষণিক পুনরায় সংযোগ বাধ্য করে। SIGKILL পরিষ্কার সম্পূর্ণ বাদ দেয়, আর এই নিবন্ধটি ঠিক সেই অবস্থা নিয়েই।
resolv.conf প্রতিস্থাপন না করে রিজলভার ঠিক করুন
বেশিরভাগ Ubuntu সিস্টেমে /etc/resolv.conf systemd-resolved-এর একটি সিমলিংক, এমন ফাইল নয় যা আপনার সম্পাদনা করা উচিত। এটি প্রতিস্থাপন করলে প্রতিটি নেটওয়ার্কের নাম রেজলিউশন ভাঙে, শুধু VPN নয়। বরং টানেলের নিবন্ধন সরিয়ে দিন:
resolvectl revert tun0
resolvectl query example.com
সিস্টেমটি systemd-resolved-এর বদলে resolvconf ব্যবহার করলে, প্রতি-ইন্টারফেস রেকর্ডটি লিংক ছাড়তে বলার আগ পর্যন্ত থাকে, এবং resolvconf -d tun0 হল সমতুল্য কাজ। কোন রিজলভার ব্যবহৃত হচ্ছে তা কমান্ড বাছার আগে দেখে নিন।
মৃত লিংকের পেছনের সার্ভারের দিকে এখনও লক্ষ্য করা লুকআপ টাইমআউট হওয়া পর্যন্ত ঝুলে থাকে, আর সেই দেরি একটি নষ্ট DNS সার্ভারের মতো দেখায়, রয়ে যাওয়া রুটের মতো নয়।
পরের ডিসকানেক্টটিকে একঘেয়ে করুন
স্টার্টআপ আর শাটডাউনে pid ফাইলের পথ একই রাখুন, প্রতিবার --pid-file পাস করে, অথবা openconnect-কে একটি unit-এর অধীনে চালান যার KillSignal আপনার সংস্করণ যে সিগন্যাল ডকুমেন্ট করে তার সাথে মেলে। প্রথমে ফোরগ্রাউন্ডে পরীক্ষা করলে হেল্পার যে শাটডাউন বার্তা প্রিন্ট করে তা দেখতে পাবেন।
সংযোগ দিন, বিচ্ছিন্ন করুন, এবং তিনটি পরীক্ষা একবার চালান। পরিষ্কার প্রস্থান কোনো VPN লিংক, VPN রুট বা VPN রিজলভার এন্ট্রি রেখে যায় না। তিনটির একটি টিকে গেলে আপনি এখন জানেন কোন উপাদান পরিষ্কার করতে ব্যর্থ হয়েছে। পরের তদন্ত তখন ঝুলে থাকা লুকআপ থেকে নয়, সেই উত্তর থেকেই শুরু হয়।