VPN DNS কাজ করে, কিন্তু .local নামগুলো এখনও ব্যর্থ হয়: কে সেগুলো সমাধান করে?

একই VPN-এ দুটি মেশিন, একই হোস্টনাম, আর তাদের মধ্যে কেবল একটি সেটি সমাধান করে: পার্থক্যটি সাধারণত টানেল নয়, বরং কোন রিজলভার উত্তর দিয়েছে। Linux ডেস্কটপে সেই নামটি নেম সার্ভিস সুইচের মধ্য দিয়ে, systemd-resolved-এর স্টাবের মধ্য দিয়ে, বা অ্যাপ্লিকেশন নিজের সঙ্গে আনা একটি রিজলভারের মধ্য দিয়ে যেতে পারে, এবং এগুলোর প্রত্যেকে একই সাফিক্সে নিজের নিয়ম প্রয়োগ করে। সাফিক্সেই নিয়মগুলো ভিন্ন হয়, কারণ .local কোনো নিরপেক্ষ লেবেল নয়। কোনো কিছু কোন ক্রমে চলে তা বদলানোর আগে ব্যর্থ প্রোগ্রামটি আসলে কোন পথ নেয় তা বের করুন।

দুটি রিজলভার, দুটি ভিন্ন উত্তর

প্রচলিত glibc লুকআপ nsswitch.conf-এর hosts: লাইন ধরে হাঁটে এবং একটি উত্তর না দেওয়া পর্যন্ত প্রতিটি মডিউলকে পালাক্রমে জিজ্ঞাসা করে। আর যে ক্লায়েন্ট স্টাব লিসেনারের মাধ্যমে systemd-resolved-এর সঙ্গে কথা বলে সে বদলে একটি একক প্রসেসকে জিজ্ঞাসা করে, এবং সেই প্রসেস প্রতিটি লিঙ্কের নীতি আর নিজের বিশেষ কেসগুলো প্রয়োগ করে। যে অ্যাপ্লিকেশন নিজের রিজলভার নিয়ে আসে, বা তা করে এমন লাইব্রেরি লিঙ্ক করে, সে দুটোই এড়িয়ে যেতে পারে। তাই একটি হোস্টনামের একই মেশিনে তিনজন মালিক থাকতে পারে, এবং তাদের মধ্যে কেবল একজন জানে VPN কী চেয়েছিল।

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

কোন কমান্ডটি আসলে আপনার রিজলভারকে জিজ্ঞাসা করেছিল

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

কেন .local আপনার unicast জোন এড়িয়ে যায়

systemd-resolved-এর রেফারেন্স বলে যে .local-এ শেষ হওয়া বহু-লেবেল নাম, mDNS চালু থাকলে সাধারণ unicast DNS-এ নয়, বরং সাধারণত multicast DNS-এ যায়। RFC 6762 সেই নেমস্পেসটি link-local multicast-এর জন্য আলাদা রাখে, তাই একটি কর্পোরেট জোন সঠিক রেকর্ড ধরে রাখতে পারে যা সেই সাফিক্সের জন্য কখনও জিজ্ঞাসা করা হয় না। টানেল রিজলভারকে নিখুঁতভাবে রাউট করতে পারে এবং তবুও দৌড়ে হেরে যেতে পারে। ক্যাশ থেকে সফল ping এইমাত্র যে লুকআপ হলো তা নিয়ে কিছুই বলে না।

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

সরু ব্যতিক্রম বৈশ্বিক পুনর্বিন্যাসকে হারায়

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

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

পরিবর্তনের পরে কী প্রমাণ করবেন

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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