কেন আপনার /etc/hosts এন্ট্রি VPN-এর DNS-এ পৌঁছায় না

VPN সংযুক্ত করলে /etc/hosts আপলোড হয় না। সিস্টেম লুকআপকে সরাসরি DNS কোয়েরি থেকে আলাদা করুন, তারপর পরিচালিত জোনের মাধ্যমে ব্যক্তিগত নাম প্রকাশ করুন।

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

Hosts হলো স্থানীয় ওভাররাইড, জোন আপডেট নয়

ফাইলটি হলো এমন ম্যাপিংয়ের তালিকা যা নাম-সেবা লাইব্রেরিগুলো DNS সার্ভারকে জিজ্ঞাসা করার আগে বা তার বদলে দেখে। 10.40.0.20 build.corp.example-এর মতো একটি লাইন শুধু ওই একটি মেশিনের অ্যাপ্লিকেশনগুলো কী সিদ্ধান্তে পৌঁছাবে তা বদলায়। এটি কোনো রেকর্ড তৈরি করে না, টানেলের মধ্য দিয়ে যায় না, এবং টানেল যে DNS সার্ভারের দিকে ইশারা করে তার এই অস্তিত্বের কোনো ধারণাই থাকে না।

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

দুটি কমান্ড, দুটি ভিন্ন উপাদান

এ নিয়ে তর্ক বন্ধ করার দ্রুততম উপায় হলো পার্থক্যটি দুটি কমান্ডে দৃশ্যমান করা, দুটিই hosts এন্ট্রি থাকা ক্লায়েন্টে চালানো:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

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

ক্রমটি কনফিগারযোগ্য, এবং নির্দিষ্ট কোনো ডিস্ট্রিবিউশন সম্পর্কে সিদ্ধান্তে পৌঁছানোর আগে এটি যাচাই করা উচিত। /etc/nsswitch.conf-এ hosts: লাইনটি দেখুন; hosts: files dns আগে ফাইল দেখে। শুধু ক্রম বদলানোর জন্য সেই উদাহরণটি একটি কাজ করা কনফিগারেশনের ওপর কপি করবেন না, কারণ বাস্তব সিস্টেমগুলো প্রায়ই অতিরিক্ত উৎস এবং শর্তসাপেক্ষ সেবা এন্ট্রি তালিকাভুক্ত করে যা উদাহরণটিতে নেই।

systemd-resolved পরীক্ষাটিকে অস্পষ্ট করে

systemd-resolved ব্যবহার করা সিস্টেমে স্থানীয় স্টাবও hosts ডেটাবেস থেকে নাম সরবরাহ করে। তাই 127.0.0.53-কে কোয়েরি করা দূরবর্তী সার্ভারের স্বাধীন পরীক্ষা নয়, যদিও এটি DNS কোয়েরির মতো দেখায় এবং তেমনই আচরণ করে। রিজলভার কী জানে এবং কোন সার্ভারগুলোকে জিজ্ঞাসা করবে তা আপনি এভাবে নিশ্চিত করতে পারেন:

resolvectl query build.corp.example
resolvectl status

status আউটপুট প্রতি লিংকের DNS সার্ভারগুলোর নাম দেয়, আর এভাবেই আপনি জানতে পারেন VPN লিংক আদৌ কোনো রিজলভার পেয়েছে কি না। এই প্রশ্নটি hosts এন্ট্রি থেকে আলাদা এবং একটি ব্যক্তিগত নাম একজন নয়, বরং প্রত্যেক ব্যবহারকারীর জন্য ব্যর্থ হলে এটিই জিজ্ঞাসা করার মতো প্রশ্ন।

অ্যাপ্লিকেশনগুলো আরেকটি স্তর যোগ করতে পারে। নিজস্ব DNS-over-HTTPS সেটিংসযুক্ত ব্রাউজার, নিজস্ব রিজলভার কনফিগারেশনযুক্ত কনটেইনার, বা প্রসেসের আয়ুষ্কাল ধরে লুকআপ ক্যাশ করা রানটাইম—প্রত্যেকেই সিস্টেম থেকে ভিন্ন উত্তর দিতে পারে। একটিমাত্র কমান্ড মেশিনের প্রতিটি প্রোগ্রামকে বর্ণনা করে ধরে নেওয়ার বদলে আপনার প্রয়োজনীয় অ্যাপ্লিকেশনটিই পরীক্ষা করুন।

VPN জুড়ে আসলে কী একটি নাম ভাগ করে

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

hosts ফাইল বিতরণ একটি বৈধ বিকল্প, এবং এটি নাম-সেবা নয় বরং এন্ডপয়েন্ট ব্যবস্থাপনা। আপনি যদি এটি বেছে নেন, ফাইলটি ফ্লিট পরিচালনা করে যা তা ডিপ্লয়, সংস্করণভুক্ত ও অপসারণ করতে হবে, এবং ডিজাইনে ঠিক সেভাবেই বর্ণনা করা উচিত। “VPN এটি সামলায়” সেই প্রক্রিয়ার বর্ণনা নয়।

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

রিজলভ হওয়া নাম কোনো রুট নয়

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

তাই যখন প্রতিবেদন হয় “নামটি রিজলভ হয় কিন্তু সেবাটি পৌঁছানো যায় না”, তখন সিস্টেম লুকআপকে VPN DNS সার্ভারে একটি স্পষ্ট কোয়েরির সঙ্গে মিলিয়ে দেখুন, তারপর আপনি যে ঠিকানা পেয়েছেন তা সেবাটি আসলে যে ঠিকানা ব্যবহার করে তার সঙ্গে মিলিয়ে দেখুন। systemd-resolved রেফারেন্স এটি যে স্থানীয় উৎসগুলো দেখে তা নথিভুক্ত করে, আর সেই তুলনার জন্য এই ম্যাপটিই আপনার দরকার।

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

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