আপনার VPN তিনটি DNS সার্ভার পাঠায়: কোনটি উত্তর দেয়?
অতিরিক্ত এন্ট্রি ফলব্যাক, প্রতি-ডোমেইন রুট বা ফিজিক্যাল লিঙ্কের অবশিষ্টাংশ হতে পারে। তালিকাটিকে লিক বলার আগে প্রতিটিকে একটি স্কোপের সাথে মিলিয়ে নিন।
সংযোগ করার পর সেটিংস পৃষ্ঠা খুলুন এবং তিনটি DNS ঠিকানা তালিকাভুক্ত দেখবেন; অডিটের প্রশ্ন হলো কোনটি আপনার শেষ কোয়েরি সামলেছে। শুধু সংখ্যা কোনো উত্তর দেয় না, কারণ ক্লায়েন্ট পুশ, একটি ফিজিক্যাল ইন্টারফেস এবং প্রতি-ডোমেইন নীতি সবাই একই ভিউতে লেখে। এই এন্ট্রিগুলো ভিন্ন স্কোপ বহন করে, এবং উত্তর কে দেবে তা অবস্থান নয়, স্কোপই ঠিক করে। প্রথমে উৎসগুলো আলাদা করুন, তারপর যে নামটি আপনার কাছে গুরুত্বপূর্ণ সেই নামের মালিক উৎসটি পরীক্ষা করুন।
কেন তালিকা আপনার প্রোফাইলের চেয়ে লম্বা
একটি VPN ক্লায়েন্ট টানেল লিঙ্কের জন্য রিজলভার ঠিকানা পুশ করে, আর অপারেটিং সিস্টেম সেগুলো ফিজিক্যাল ইন্টারফেসের আগে থেকেই থাকা ঠিকানার পাশে রাখে। রাউটার, কর্পোরেট DHCP লিজ, দ্বিতীয় একটি VPN এবং প্রতি-ডোমেইন নীতি—প্রত্যেকে নিজের একটি এন্ট্রি যোগ করে। তাই পৃষ্ঠায় তিনটি ঠিকানা মানে এক কাজের জন্য তিনটি প্রার্থী নয়, বরং তিনটি স্কোপ হতে পারে। সংখ্যাটিকে লিকের প্রমাণ হিসেবে পড়া এই অডিটের প্রথম ভুল।
একটি ইন্টারফেসের ভেতরে ক্লায়েন্ট সত্যিই তার সার্ভারগুলো ক্রম অনুসারে চেষ্টা করে, তাই ক্রমবদ্ধ তালিকা অর্থহীন নয়। কিন্তু সারি নয় যা মিলিত ভিউ, যেখানে প্রোফাইল, ফিজিক্যাল লিঙ্ক এবং প্রতি-ডোমেইন নিয়মের এন্ট্রিগুলো একক ক্রমবিন্যাস ছাড়াই পাশাপাশি বসে। এই পার্থক্যই ঠিক করে আপনি কী পরীক্ষা করবেন: ক্রম এক স্কোপের ভেতরের আচরণ ব্যাখ্যা করে, আর স্কোপ বাকি সবকিছু ব্যাখ্যা করে।
এনক্রিপ্টেড DNS অ্যাপ্লিকেশনের ভেতর থেকে ছবিটা ভেঙে দেয়। নিজস্ব DNS-over-HTTPS রিজলভারসহ একটি ব্রাউজার বা চ্যাট ক্লায়েন্ট অপারেটিং সিস্টেমের তালিকা সম্পূর্ণ পাশ কাটিয়ে কোয়েরি পাঠায়, তাই সেটিংস পৃষ্ঠার ঠিকানাগুলো এমন ট্রাফিক বর্ণনা করে যা অ্যাপ কখনো তৈরি করেনি। নাম ভুল আসার জন্য প্রোফাইলকে দোষ দেওয়ার আগে অ্যাপের নিজের রিজলভার সেটিং দেখুন।
তিনটি পরীক্ষার প্রতিটি কী বলে
প্রতিটি উৎস আলাদা জায়গায় নিজের ছাপ রাখে, এবং কোনো একক কমান্ড সবগুলো দেখায় না। সেটিংস পৃষ্ঠার পাশে রাখার মতো ম্যাপিং এই:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved ব্যবহার করা সিস্টেমে resolvectl status কর্তৃত্বপূর্ণ, কারণ এটি রাউটিং ডোমেইনসহ প্রতি লিঙ্কের DNS রিপোর্ট করে। macOS উত্তর দেয় scutil --dns-এর মাধ্যমে, যা স্কোপড রিজলভারগুলো চেষ্টার ক্রমে তালিকা করে। Windows দুই অর্ধেক ভাগ করে: প্রতি-ইন্টারফেস সার্ভারের জন্য Get-DnsClientServerAddress এবং সাফিক্স নিয়মের জন্য Get-DnsClientNrptPolicy। যে রিজলভার বাস্তবে ব্যবহৃত হচ্ছে তার কমান্ডটি চালান, কারণ কনটেইনার রানটাইম ও ডেস্কটপ রিজলভার থাকা মেশিনে একাধিক ইনস্টল থাকতে পারে।
একটি ব্যাকআপ রিজলভার যা আপনার জোনের উত্তর দিতে পারে না
দ্বিতীয় এন্ট্রি সাধারণত প্রাপ্যতার জন্য থাকে, আর প্রাপ্যতা তখনই কাজ করে যখন ব্যাকআপ নামগুলো জানে। একটি পাবলিক রিজলভারকে অভ্যন্তরীণ হোস্টনেম জিজ্ঞাসা করুন, সে NXDOMAIN ফেরায়, অথবা আপনার সাথে সম্পর্কহীন সার্চ ডোমেইন থেকে ওয়াইল্ডকার্ড উত্তর দেয়। কেউ না পরীক্ষা করা ফেইলওভার তখন ঠিক যেই মুহূর্তে দরকার ঠিক তখনই আউটেজ তৈরি করে।
Split DNS এটা ঠেকানোর জন্যই আছে: কোম্পানির সাফিক্স যায় জোন ধরে রাখা রিজলভারে, আর পাবলিক নাম থাকে ডিফল্ট পথে। নকশাটি যথার্থ, এবং এটি নির্ভর করে সাফিক্স তালিকা সম্পূর্ণ হওয়ার উপর। Microsoft ডকুমেন্ট করে প্রতি-সাফিক্স রিজলভার নীতিটি যা Windows-এ এটি চালায়, এবং একই ধারণা systemd-resolved-এ রাউটিং ডোমেইন হিসেবে ও macOS-এ স্কোপড রিজলভার হিসেবে দেখা যায়।
ব্যাকআপ যে জোনগুলোর উত্তর দিতে পারে সেগুলো নীতিতে থাকা সাফিক্সগুলোর সাথে তুলনা করুন। এই তুলনাটি ব্যবহারকারী টানেল পরিবর্তনের পর একটি অভ্যন্তরীণ সাইট কেন রিজলভ হওয়া বন্ধ করেছে জানানোর আগেই ফাঁকটা খুঁজে বের করে।
নীতির ভেতর দিয়ে কোয়েরি করুন, পাশ কাটিয়ে নয়
অপারেটিং সিস্টেমের রিজলভারের মাধ্যমে কোয়েরি করুন, কারণ সার্ভারে সরাসরি কোয়েরি নীতি পাশ কাটায় এবং কেবল সেই সার্ভার যা বলবে তাই রিপোর্ট করে। দুই উত্তরের মধ্যকার ফাঁকটাই আসল কথা:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53সিস্টেম কোয়েরি যদি প্রাইভেট ঠিকানা ফেরায় আর সরাসরি কোয়েরি NXDOMAIN ফেরায়, তবে নীতি কাজ করছে এবং ব্যাকআপই দুর্বল জায়গা। যদি দুটোই একই পাবলিক উত্তর ফেরায়, নামটি আপনার উদ্দিষ্ট স্কোপের বাইরে রিজলভ হচ্ছে, আর সাফিক্স তালিকাই খোঁজার জায়গা। দুই আউটপুটই রেখে দিন, কারণ সেটিংস পৃষ্ঠার স্ক্রিনশটের চেয়ে দুই লাইন দিয়ে রিজলভার বিতর্ক দ্রুত মিটে যায়।
তারপর ব্যর্থতার পথটি অনুশীলন করুন, কারণ কেউ না পরীক্ষা করা ফলব্যাক একটি অনুমান। একটি কোয়েরির জন্য পছন্দের রিজলভারকে ব্ল্যাকহোল করুন এবং দেখুন কোন ঠিকানা ফিরে আসে:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32কোয়েরি শেষ হওয়ামাত্র সেই রুটটি মুছে ফেলুন, নইলে পরের ব্যক্তি একটি রহস্য উত্তরাধিকার পায়। ওই সময়ে অভ্যন্তরীণ নামগুলো যদি এখনো রিজলভ হয়, তবে উদ্দিষ্ট স্কোপের বাইরের কিছু তাদের উত্তর দিয়েছে। যদি বরং সময় শেষ হয়ে যায়, তবে ফলব্যাকটি অনুপস্থিত বা সঠিকভাবে স্কোপড, এবং রিজলভারের নিজের লগই বলে দেবে দুটোর কোনটি ছিল।
সিদ্ধান্ত নিন: রাখুন, স্কোপ করুন বা সরান
দ্বিতীয় রিজলভার রাখুন যখন এটি আপনার দরকারি নেমস্পেসের উত্তর দেয় এবং প্রোফাইলের অধীনে পৌঁছানোযোগ্য থাকে। এটিকে স্কোপ করুন যখন এর কেবল একটি সাফিক্স দেখা উচিত আর কিছু নয়, এবং সরিয়ে দিন যখন এর কোনো স্কোপ নেই কোনো নথিভুক্ত উদ্দেশ্যও নেই। কাজহীন এন্ট্রি হলো লাভহীন ভবিষ্যৎ লিক, আর ভেন্ডরের ডিফল্ট কোনো উদ্দেশ্য নয়।
ফলাফলটি চারটি কলামে লিখুন: সাফিক্স, রিজলভার, ইন্টারফেস ও মালিক। ওই লাইনটি যেকোনো স্ক্রিনশটের চেয়ে দ্রুত পরের অডিট প্রশ্নের উত্তর দেয়, এবং তালিকাটিকে নিঃশব্দে পুনর্বিন্যাস করা ক্লায়েন্ট আপডেটও টিকে যায়।