ip netns exec ও DNS: নেমস্পেসের ভিতরে নাম কেন ব্যর্থ হয়

একটি কমান্ড VPN নেমস্পেসের ভিতরে 10.8.0.5 ঠিকানায় কোনো অভিযোগ ছাড়াই পৌঁছায়, আর একই কমান্ড হোস্টনেম ব্যবহার করার মুহূর্তেই ব্যর্থ হয়। নেমস্পেসের নিজস্ব ইন্টারফেস, রুট ও সকেট আছে; নিজস্ব রিজলভার ফাইল নেই। কেউ সেখানে একটি ফাইল না রাখলে ভিতরের প্রক্রিয়াটি হোস্টের /etc/resolv.conf পড়ে এবং এমন একটি সার্ভারকে জিজ্ঞাসা করে যা ওই নেটওয়ার্ক স্ট্যাক থেকে পৌঁছানো নাও যেতে পারে।

এটি রাউটিং সমস্যা নয়, ফাইল-নির্বাচনের সমস্যা, এবং ঠিক এ কারণেই সংখ্যাসূচক গন্তব্যটি এখনও কাজ করে।

প্রক্রিয়াটি আসলে যে রিজলভার দৃশ্য পায়, তা যাচাই করুন

আপনি যে শেল ব্যবহার করেছেন, সেটি আপনার ডিবাগ করা প্রক্রিয়ার সমতুল্য বলে ধরে নেবেন না। একটি গ্রাফিক্যাল অ্যাপ্লিকেশন, একটি systemd ইউনিট এবং একটি কনটেইনার—প্রতিটি আলাদা মাউন্ট বা নেটওয়ার্ক কনটেক্সটে ঢুকতে পারে। একই লঞ্চ পথ দিয়ে লুকআপ চালান, এবং ভিতর থেকে রিজলভার ফাইলটি প্রিন্ট করুন।

ip netns add দিয়ে তৈরি নেমস্পেসের জন্য শুধু-পড়ার যাচাইটি সংক্ষিপ্ত:

ip netns exec vpn cat /etc/resolv.conf

ফলাফলে একটি পৌঁছানোযোগ্য ঠিকানা, একটি loopback স্টাব, নাকি ভিন্ন পৌঁছানোযোগ্যতার কোনো জায়গায় নির্দেশ করা সিমলিংক এসেছে—সেটি লক্ষ করুন।

exec হেল্পার আসলে কী মাউন্ট করে

ip-netns টুলটি প্রতি-নেমস্পেস কনফিগারেশন /etc/netns/NAME/-এর অধীনে নথিভুক্ত করে। কোনো প্রক্রিয়া লঞ্চ করলে হেল্পারটি একটি মাউন্ট নেমস্পেস তৈরি করে এবং সেই ফাইলগুলোকে তাদের স্বাভাবিক পথের উপর bind-mount করে, তাই প্রক্রিয়াটি নেমস্পেস-নির্দিষ্ট কপিটি দেখে। এটি এই নির্দিষ্ট লঞ্চারের একটি সুবিধা। অন্য পথে, যেমন unshare বা কোনো কনটেইনার রানটাইম দিয়ে নেটওয়ার্ক নেমস্পেসে ঢুকলে এটি স্বয়ংক্রিয়ভাবে পুনরুৎপাদিত হয় না।

এখানে ফাঁদ হলো loopback রিজলভার: 127.0.0.53 বোঝায় নেমস্পেসের নিজের loopback, হোস্টের স্টাব নয়। যে স্টাব কেবল হোস্ট নেমস্পেসে শোনে, সেটি নতুন নেমস্পেসে কোনো সেবা হয়ে ওঠে না।

নেমস্পেস যে রিজলভারে পৌঁছাতে পারে, তা বেছে নিন

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

নিজস্ব রিজলভারযুক্ত অ্যাপ্লিকেশন, যেমন DNS over HTTPS ব্যবহারকারী একটি অ্যাপ, ফাইলটি সম্পূর্ণ উপেক্ষা করতে পারে। টুলটির নিজস্ব DNS সেটিং থাকলে resolv.conf বদলালে তার কোনো প্রভাব পড়বে না, আর নেমস্পেস কখনোই সমস্যা ছিল না।

ফাইলটি সঠিক জায়গায় লিখুন

/etc/netns/NAME/resolv.conf-এর অধীনে প্রতি-নেমস্পেস ফাইলটি তৈরি করুন এবং লঞ্চারকে তা উপস্থাপন করতে দিন। এটিকে সংক্ষিপ্ত রাখুন: এক বা দুইটি পৌঁছানোযোগ্য সার্ভার এবং কাজের প্রয়োজনীয় সার্চ ডোমেইন। একদল প্রক্রিয়ার জন্য বোঝানো দৃশ্য ঠিক করতে হোস্টের তৈরি রিজলভার ফাইল সম্পাদনা করবেন না, কারণ তাতে মেশিনের প্রতিটি অ্যাপ্লিকেশন বদলে যায়। হোস্ট কোনো রিজলভার ম্যানেজার ব্যবহার করলে তার বিরুদ্ধে লড়াই না করে ওই ম্যানেজার দিয়েই নেমস্পেস পথটি কনফিগার করুন।

রানবুকে ফাইলের বিষয়বস্তু লিখে রাখুন। নইলে পরের ব্যক্তি হোস্টের রিজলভার পরীক্ষা করে একটি কাজ করা উত্তর দেখে সিদ্ধান্তে আসবেন যে নেমস্পেস ঠিক আছে।

পুরো পথটি আবার পরীক্ষা করুন

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

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