আপনার Mac VPN-এ যে DNS রিজলভার ব্যবহার করে তা কীভাবে যাচাই করবেন

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

ঠিকানার আগে ব্লকের ক্রম পড়ুন

প্রতিটি এন্ট্রি resolver #N দিয়ে শুরু হয় এবং nameserver[0], মাঝে মাঝে if_index, একটি flags লাইন, reach, আর ব্লকটি সাধারণ ডিফল্ট না হলে domain ও একটি search domain তালিকা দেখায়। ডোমেইন ছাড়া 1 নম্বর রিজলভারই ডিফল্ট, যা পাবলিক নাম সামলায়। ফ্ল্যাগে Scoped থাকা যেকোনো কিছু if_index-এ নামকৃত ইন্টারফেসের সঙ্গে বাঁধা, এবং Supplemental চিহ্নিত যেকোনো কিছু কেবল তার নিচে তালিকাভুক্ত ডোমেইনে প্রযোজ্য।

নির্বাচন হলো প্রত্যয় মেলানো। intranet.corp.example-এর মতো নামের জন্য macOS সেই রিজলভারকে প্রাধান্য দেয় যার domain এন্ট্রি সবচেয়ে দীর্ঘ মিলে যাওয়া প্রত্যয়, তাই domain : corp.example থাকা ব্লক আউটপুটে অনেক নিচে থাকলেও ডিফল্টকে হারায়। একই দৈর্ঘ্যের ডোমেইনগুলোর মধ্যে সমতা ভাঙে order। প্রথম ঝলকে এর বেশি খুব কমই দরকার: একটি ব্লক শুরু থেকে শেষ পর্যন্ত পড়তে চাইলে পুরো আউটপুট, ব্লকের ক্রম জানতে শুরুর লাইনগুলো, আর একটি ফিল্টার করা পাস যা ফিল্ডের লাইনের পাশে ব্লকের শিরোনাম দেখায়। স্কোপড ব্লক নিজের শিরোনামের নিচে আসে এবং উপরের তালিকার ধারাবাহিকতা মনে হয়, তাই আউটপুট উদ্ধৃত করার সময় শিরোনামটি চোখের সামনে রাখুন।

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index-কে টানেল ইন্টারফেসের সঙ্গে মেলান

ইনডেক্স কেবল তখনই কাজে লাগে যখন তার পেছনের ইন্টারফেসের নাম বলতে পারেন। scutil --nwi সিস্টেমের রাখা নেটওয়ার্ক তথ্য দেখায়, প্রাথমিক ইন্টারফেস ও পৌঁছানোর ক্ষমতাসহ, আর ifconfig -l আপনাকে নামগুলো দেয়, যেখানে utun0 থেকে utun9 হলো টানেলের প্রার্থী, যা একটি ক্লায়েন্ট সাধারণত তৈরি করে। Apple নিজের পরিদর্শন উদাহরণ হিসেবে scutil --dns ব্যবহার করে — স্থাপনার নির্দেশিকা — এবং নথিভুক্ত করে কীভাবে Network Extension নির্বাচিত ডোমেইনকে নির্বাচিত রিজলভারে পাঠাতে পারে; স্কোপড ব্লকগুলো ঠিক সেই কৌশলই দেখায়।

যে পরীক্ষা প্রশ্নটির মীমাংসা করে তা হলো, রিজলভারটি টানেল যে পথ বসিয়েছে তার উপরেই আছে কি না:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

route -n get যদি এমন গেটওয়ে ও ইন্টারফেস ফেরত দেয় যা রিজলভার এন্ট্রির সঙ্গে মেলে না, তবে ঠিকানাটি সম্পূর্ণ সঠিক হয়েও পৌঁছানো যায় না। শুধু কর্পোরেট সাবনেট বহন করা একটি স্প্লিট টানেল তাদের বাইরের DNS সার্ভারের দিকে যাওয়া কোয়েরি ফেলে দেয়, আর ব্যর্থতাটি টাইমআউট হিসেবে দেখা যায়, তাই কনফিগারেশন আউটপুট সবসময় পরিষ্কার দেখায়।

সিস্টেম রিজলভারকে জিজ্ঞাসা করুন, তারপর সার্ভারকে

তিনটি টুল তিনটি ভিন্ন প্রশ্নের উত্তর দেয়, আর এগুলো গুলিয়ে ফেললে এই ক্ষেত্রে বেশিরভাগ ভুল সিদ্ধান্ত আসে। dscacheutil -q host -a name সাধারণ অ্যাপ্লিকেশন যে সিস্টেম রিজলভার ব্যবহার করে তার মধ্য দিয়েই যায়, তাই স্কোপড ও সম্পূরক ব্লক প্রযোজ্য। সার্ভার আর্গুমেন্ট ছাড়া dig /etc/resolv.conf পড়ে, যা macOS-এ স্কোপড রিজলভিংয়ের সত্যের উৎস নয়, এবং এটি প্রতি-ডোমেইন নিয়ম সম্পূর্ণ এড়িয়ে যায়। dig @address ঠিক একটি সার্ভারে পৌঁছায় এবং নির্বাচন সম্পর্কে কিছুই বলে না।

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

প্রথম কমান্ড উত্তর দিলে আর দ্বিতীয়টি NXDOMAIN ফেরত দিলে, আপনি যে বিভাজন খুঁজছিলেন তা পেয়ে গেছেন এবং কিছুই ভাঙা নেই। প্রথমটি সময় শেষ করলে অথচ dig @10.20.0.53 উত্তর দেয়, রিজলভার কাজ করে কিন্তু টানেল যে পথ বেছেছে সেখানে পৌঁছানো যায় না, তাই পরের ধাপ route -n get, DNS সেটিংস বদলানো নয়। প্রাইভেট নামগুলো টিকিট বা শেয়ার করা নোটে যা কিছু পেস্ট করেন তার বাইরে রাখুন।

আউটপুট আপনাকে যা দেখাতে পারে না

রিজলভার তালিকার উপরে বা পাশে কয়েকটি স্তর থাকে, আর প্রত্যেকটি কোয়েরি এমন জায়গায় পাঠাতে পারে যা আউটপুটে কখনো উল্লেখ থাকে না। সিকিউর DNS চালু থাকা ব্রাউজার নিজের এনক্রিপ্টেড চ্যানেলে রিজলভ করতে পারে, তাই dscacheutil সময় শেষ করার সময় একটি পাতা লোড হলে তা বিরোধ নয়। নিরাপত্তা সফটওয়্যার যে DNS প্রক্সি বসায় তা Network Extension প্রদানকারী হিসেবে চলে এবং নিজেই কোয়েরি ফরওয়ার্ড করে, আর scutil --dns দেখায় কী কনফিগার করা হয়েছিল, প্রক্সি শেষে যে আপস্ট্রিম ঠিকানা ব্যবহার করেছে তা নয়। সার্চ ডোমেইন তৃতীয় জটিলতা যোগ করে: অযোগ্য নামের সঙ্গে তালিকাভুক্ত প্রতিটি প্রত্যয় ক্রমে যোগ হয়, তাই যে ব্লক উত্তর দিয়েছে তা এমন হতে পারে যা আপনি কখনো সন্দেহ করেননি।

পুরনো উত্তর সবচেয়ে সস্তায় বাদ দেওয়া যায় আর সবচেয়ে বেশি বাদ পড়ে:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

ফ্লাশের পরে আউটপুট বদলালে, অবস্থাটি ক্যাশে ছিল এবং আগের আউটপুট এমন টানেল বর্ণনা করেছিল যা আর নেই। না বদলালে, কনফিগারেশন যা আছে তাই আছে, আর প্রশ্নটি রুট ও অ্যাপ্লিকেশন নীতির দিকে সরে যায়।

আগে ও পরের জন্য সংক্ষিপ্ত রানবুক

নীতি যেখানে অনুমতি দেয় কেবল সেখানেই বেসলাইন নিন, আর ফাইলগুলো যেকোনো সিঙ্ক করা ফোল্ডারের বাইরে রাখুন। নিচের ক্রমটাই আমি ক্লায়েন্ট মেশিনে চালাই: বেসলাইন নিন, সংযোগ করুন, আবার নিন, তারপর তুলনা করুন ও খুঁজুন।

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

পার্থক্যটি লাইন ধরে নয়, ব্লক ধরে পড়ুন। টানেল ইন্টারফেস ইনডেক্স ও প্রাইভেট প্রত্যয়ের জন্য domain এন্ট্রি বহন করা নতুন স্কোপড রিজলভারই প্রত্যাশিত রূপ। পাবলিক ঠিকানার দিকে দেখা নতুন ডিফল্ট রিজলভার এমন একটি আবিষ্কার যা ক্লায়েন্ট প্রোফাইলের মালিকের কাছে তোলা উচিত। তারপর যে অ্যাপ্লিকেশনটি সত্যিই ব্যর্থ হয়েছিল তার ভেতরে লুকআপটি পুনরাবৃত্তি করুন, কেবল শেলে নয়, আর ফলাফলের পাশে route -n get থেকে ইন্টারফেসটি লিখে রাখুন।

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

এই ক্রমে চারটি পরীক্ষা: কোনো রিজলভার ব্লক নামের সবচেয়ে দীর্ঘ প্রত্যয়ের সঙ্গে মেলে কি; ব্লকটি টানেল যে ইন্টারফেস বসিয়েছে তার সঙ্গে বাঁধা কি; তার নেমসার্ভারের রুট টানেল ব্যবহার করে কি; আর সিস্টেম রিজলভার, dig নয়, উত্তর দেয় কি। যে পরীক্ষাটি প্রথমে ব্যর্থ হয় তা বলে দেয় DNS নীতি, টানেলের রুট, নাকি অ্যাপ্লিকেশন বদলাবেন। চারটিই পাস করলে আর নাম এখনো ব্যর্থ হলে সমস্যাটি DNS-এর উপরে, আর পরের দেখার বিষয় হলো এর সামনে পোর্ট 53-এ যা উত্তর দেয়।