ব্যক্তিগত DNS নামগুলো VPN ক্লায়েন্টে কেন ব্যর্থ হয় এবং কোথায় যাচাই করবেন

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

যেকোনো প্রোফাইল সম্পাদনার আগে যাচাই করুন ক্লায়েন্ট নামটি নিয়ে কী করে। Linux-এ resolvectl query files.corp.example দেখায় কোন লিঙ্ক ও কোন রিজলভার উত্তরটি তৈরি করেছে। Windows-এ Resolve-DnsName files.corp.example দেখায় কোন সার্ভার উত্তর দিয়েছে এবং কোন ঠিকানা ফিরিয়েছে।

কিছু বদলানোর আগে উত্তরটি পড়ুন

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

এই তিনভাগে ভাগ করা এক ঘণ্টার অনুমান বাঁচায়। এটি এও বলে VPN-এ হাত দিতে হবে কি না: যে নাম সঠিক ব্যক্তিগত ঠিকানায় সমাধান হয় তা রিজলভারের পথ আগেই প্রমাণ করেছে, তাই বাকি কাজ ডেটার পথে।

রিজলভারটি টানেলের ভেতর থেকে বিলি করুন

ক্লায়েন্ট দুটি দলে ভাগ হয়। একটিকে সার্ভার সংযোগ তৈরির সময় রিজলভার দিতে পারে; অন্যটি সেটিংটি স্থানীয় ফাইলে রাখে যা কোনো গেটওয়ে দূর থেকে বদলাতে পারে না।

OpenVPN প্রথম দলে আছে। সার্ভারে push "dhcp-option DNS 10.8.0.53" এবং push "dhcp-option DOMAIN corp.example" নিয়ন্ত্রণ চ্যানেল দিয়ে নিচে যায়, কিন্তু কেবল তখনই যখন ক্লায়েন্টের কনফিগারেশনে pull এখনও সক্রিয়। হাতে সম্পাদনা করা ক্লায়েন্ট যা pull-filter ignore "dhcp-option" বহন করে সেগুলো কখনও দেখবে না, এবং এই একটি লাইনই অবাক করার মতো অনেক ঘটনার ব্যাখ্যা দেয় যে «সার্ভার ঠেলছে কিন্তু আমার ল্যাপটপ মানছে না»।

WireGuard দ্বিতীয় দলে, কারণ প্রোটোকলে কোনো বিকল্প আলোচনাই নেই। রিজলভার ও অনুসন্ধান ডোমেইন ক্লায়েন্টের নিজের [Interface] ব্লকে DNS = 10.8.0.53, corp.example হিসেবে যায়। wg-quick এটি resolvconf বা systemd-resolved দিয়ে প্রয়োগ করে, এবং Windows-এ অফিসিয়াল ক্লায়েন্ট NRPT-এর সেই নিয়মগুলো ইনস্টল করে যা কেবল টানেল ওপরে থাকা পর্যন্ত থাকে: Get-DnsClientNrptPolicy সেগুলো তালিকাভুক্ত করে, যা ক্লায়েন্ট আপনার ফাইল কখনও প্রয়োগ করেছে কি না দেখার দ্রুত উপায় করে তোলে।

IPsec/IKEv2 মাঝখানে। strongSwan-এর attr প্লাগইন পুল থেকে নেওয়া DNS সার্ভার ফিরিয়ে দিতে পারে, এবং Windows ক্লায়েন্ট সাধারণত তা মেনে নেয়, কিন্তু যে প্রোফাইল নিজের নাম সার্ভার আঁকড়ে ধরে সেটি গেটওয়ে যা দেয় তার সবকিছু ছাড়িয়ে যায়। Linux ক্লায়েন্টে সমতুল্য হাতের ধাপ resolvectl dns wg0 10.8.0.53 এবং তারপর resolvectl domain wg0 '~corp.example'; দুটোই ইন্টারফেসের সঙ্গে হারিয়ে যায়, যা টানেলে সীমিত সেটিংয়ের জন্য ঠিক তেমনই যা আপনি চান।

প্রতিটি অনুসন্ধান গিলে ফেলার বদলে প্রত্যয় সীমিত করুন

ক্লায়েন্টের পুরো রিজলভার তালিকা আপনার অভ্যন্তরীণ সার্ভারের দিকে ঘুরিয়ে দেওয়া সহজ এবং সাধারণত ভুল। তখন প্রতিটি পাবলিক নাম আপনার ডেটা সেন্টারের নির্গমন দিয়ে সমাধান হয়, CDN দূরের ঠিকানা ফেরত দেয়, আর রিজলভারের একটি বিভ্রাট ব্যবহারকারীর ব্রাউজিংও সঙ্গে নিয়ে যায়।

ভেতরে কেবল ব্যক্তিগত প্রত্যয় পাঠান। systemd-resolved-এ যে ডোমেইন ~ দিয়ে শুরু হয় তা কেবল রাউটিংয়ের জন্য, তাই ~corp.example মানে সেই প্রত্যয়ের অধীন অনুসন্ধান সেই লিঙ্কের সার্ভারগুলোতে যায় যখন বাকি সবকিছু ভৌত নেটওয়ার্ক ব্যবহার করে চলে। Windows একই কাজ করে নামস্থানে সীমিত NRPT নিয়ম দিয়ে, এবং macOS /etc/resolver/-এর অধীন একটি অতিরিক্ত রিজলভার ফাইল দিয়ে।

মাল্টিকাস্ট নাম নিজেদের উত্তর পাওয়ার যোগ্য। .local নামগুলো গঠনগতভাবে link-local (RFC 6762) এবং বিন্দু-থেকে-বিন্দু tun ইন্টারফেস সেই মাল্টিকাস্ট গ্রুপ বহন করে না, তাই পাবলিক রিজলভার যোগ করলে সেগুলো প্রকাশ পাবে না এবং অভ্যন্তরীণ unicast রিজলভারকে সেগুলো সম্পর্কে জিজ্ঞাসা করলে NXDOMAIN ফিরে আসে। avahi-র মতো একটি প্রতিফলক প্রতিফলন মোডে দুটি খণ্ড জুড়তে পারে, কিন্তু এটি সার্ভার পক্ষের সিদ্ধান্ত যা কোনো ক্লায়েন্ট চাইতে পারে না। যদি প্রিন্টার বা NAS নামে পৌঁছানোযোগ্য হতেই হয়, তবে তার বদলে আপনার জোনে তাকে একটি A রেকর্ড দিন।

প্রমাণ করুন উত্তরটি ফিরে আসতে পারে

অপৌঁছনীয় ঠিকানার দিকে ইশারা করা সঠিক উত্তর ঠিক রিজলভারের সমস্যার মতোই দেখায় যতক্ষণ না আপনি পথটি যাচাই করেন। কার্নেলকে জিজ্ঞাসা করুন উত্তরটি কোথায় যাবে: ip route get 10.20.5.20 ইন্টারফেস এবং আরও কাজের কথা হলো যে উৎস ঠিকানা ব্যবহার করবে তা বলে দেয়।

রিজলভারের ঠিকানাটি নিজেই লক্ষ্য করুন। যে ক্লায়েন্টের DNS = 10.8.0.53 পাশে AllowedIPs = 10.20.0.0/16 আছে সে তার অনুসন্ধান ভৌত NIC দিয়ে বাইরে পাঠায়, যেখানে সেগুলো নিঃশব্দে মরে, কারণ রিজলভার টানেল যে কোনো উপসর্গের ভেতরে নেই। এই অমিল এই পুরো ক্ষেত্রে সবচেয়ে সাধারণ একক-কারণ ব্যর্থতা, এবং এটি অদৃশ্য থাকে যতক্ষণ না আপনি DNS সেটিংটি অনুমোদিত উপসর্গের সঙ্গে লাইন ধরে ধরে তুলনা করেন।

ওভারল্যাপিং সীমা উল্টো ব্যর্থতা ঘটায়। উত্তরটি সঠিক, পথটি আছে, আর সেটি ভুল হোস্টের দিকে ইশারা করে, কারণ বাড়িতে 192.168.0.0/24 একই সীমার দিকে টানেলের পথের চেয়ে বেশি নির্দিষ্ট। এক পাশ পুনঃসংখ্যায়িত করুন বা সরু পথ ঠেলে দিন, তারপর পরিষেবা হোস্টের ফায়ারওয়াল ও ফেরার পথ যাচাই করুন; strongSwan-এর ফরোয়ার্ডিং নিয়ে টীকা সেই পথের sysctl দিকটি কভার করে।

সার্টিফিকেট একটি আলাদা পরিচয় যাচাই যা মানুষ DNS-এর ঘাড়ে চাপায়। যদি ব্রাউজার সমাধানের ত্রুটির বদলে নামের অমিল জানায়, তবে অনুসন্ধান আগেই কাজ করেছে এবং সার্টিফিকেটের SAN-ই ঠিক করার বিষয়। HTTPS নামের বিরুদ্ধে পরীক্ষা করুন, কখনও খালি IP-র বিরুদ্ধে নয়।

গেটওয়ে থেকে নয়, ক্লায়েন্ট থেকে আবার পরীক্ষা করুন

যে অ্যাপ্লিকেশন নিয়ে ব্যবহারকারী অভিযোগ করে তার ভেতরেই পরীক্ষা করুন, কারণ কমান্ড লাইনের অনুসন্ধান প্রমাণ করে না যে ব্রাউজারও একই পথ নেয়। Chrome-এর নিরাপদ DNS এবং Firefox-এর network.trr.mode সিস্টেম রিজলভার পুরোপুরি বাইপাস করতে পারে, এবং যখন তা করে তখন ব্যক্তিগত নাম হয় ব্যর্থ হয় নয়তো কোনো পাবলিক রিজলভারে ফাঁস হয়। resolvectl query-কে হাতে চালানো dig @10.8.0.53 files.corp.example-এর সঙ্গে তুলনা করলে বোঝা যায় দুটির মধ্যে কোনটি ঘটেছে।

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

পরের মেশিনের জন্য ছোট তালিকা: নামটি টানেলের রিজলভার দিয়ে সমাধান হয়, প্রত্যয়টি সীমিত, বিশ্বব্যাপী নয়, রিজলভারের ঠিকানা অনুমোদিত উপসর্গের ভেতরে, উত্তরের হোস্ট পরিষেবার পোর্টে উত্তর দেয়, এবং সার্টিফিকেট ব্যবহারকারীর লেখা নামটি ঢেকে রাখে।