VPN কি আমার DNS বদলে দিয়েছে? আগে ও পরে তুলনা করুন
একটি প্রোফাইল ইচ্ছাকৃতভাবে আপনার লুকআপ সরাতে পারে। VPN সংযোগের আগে ও পরে রিজলভার নীতি এবং প্রকৃত উত্তর তুলনা করুন, একটি চলক স্থির রেখে।
আপনি টানেল সংযোগ করেন, একটি ব্যক্তিগত ড্যাশবোর্ড খোলেন, আর নামটি এমন ঠিকানায় সমাধান হয় যা আপনি আগে কখনো দেখেননি। অথবা উল্টোটা ঘটে: ব্রাউজার কাজ করতে থাকে, অথচ একটি কমান্ড-লাইন টুল হঠাৎ কিছুই সমাধান করে না। দুই ফলই একই পরিবর্তন থেকে আসে, এবং মানুষ সাধারণত এটি VPN "নিজের DNS ব্যবহার করে" বলে এক বাক্যে ব্যাখ্যা করে, যা ডিবাগ বা যাচাইয়ের জন্য যথেষ্ট নির্ভুল নয়। ওই বাক্যে দুটি প্রশ্ন লুকিয়ে আছে: এই প্রোফাইলটি কোন লুকআপগুলো নেওয়ার কথা, এবং আপনার মেশিন কি সত্যিই সেগুলো তাকে দেওয়া রিজলভারের কাছে পাঠিয়েছে? এগুলো আলাদা রাখাই পুরো পদ্ধতি, কারণ যে পরীক্ষা এগুলো মেশায় তা দুই দিকেই আত্মবিশ্বাসী ভুল উত্তর দেয়।
প্রোফাইল কেন আদৌ একটি রিজলভার দেয়
টানেলের ভিতরে, দূর প্রান্তের পেছনের নাম সাধারণত কেবল সেই নেটওয়ার্কে থাকা ঠিকানায় সমাধান হয়। corp.internal-এর মতো একটি ব্যক্তিগত জোনের কোনো পাবলিক ডেলিগেশন নেই, তাই যে রিজলভার এটির উত্তর দেয় সেটি টানেলের ভিতর থেকে পৌঁছানোযোগ্য হতে হবে। একই ব্যবস্থা দ্বিতীয় একটি উদ্দেশ্যও পূরণ করে: যখন লুকআপ অন্যথায় আপনার ISP-এর মধ্য দিয়ে বেরিয়ে যেত, তখন দূর প্রান্তের রিজলভার কোয়েরিটিকে এনক্রিপ্টেড পথের ভিতরে রাখে। এই কারণেই DNS সার্ভারের ঠিকানা সংযোগের নীতির অংশ হিসেবে আসে, মেশিনের জন্য একবার বেছে নেওয়া বৈশ্বিক সেটিং হিসেবে নয়।
ঠিকানা নিজে থেকে কিছুই নির্ধারণ করে না। রিজলভার কেবল তখনই উত্তর দিতে পারে যখন তার দিকে একটি রুট থাকে, এবং সবচেয়ে সাধারণ ব্যর্থতা হলো এমন রিজলভার যা কেবল টানেল চালু থাকার সময় পৌঁছানো যায়। টানেল পড়ে গেলে এবং নীতি থেকে গেলে, লুকআপ এমন ঠিকানায় যায় যার কোনো পথ নেই, আর লক্ষণটি পরিষ্কার ত্রুটি নয়, টাইমআউট। পরের পরীক্ষার ফল পড়ার সময় এই পার্থক্যটি গুরুত্বপূর্ণ, কারণ টাইমআউট মানুষকে এমন ট্রান্সপোর্ট সেটিংসে নিয়ে যায় যা কখনো জড়িত ছিল না।
উত্তর তুলনা করার আগে দুই ডিজাইন তুলনা করুন
সম্পূর্ণ টানেল ও বিভক্ত DNS বিপরীত প্রত্যাশা তৈরি করে, এবং কোনোটিই ত্রুটি নয়। সম্পূর্ণ টানেলের অধীনে প্রতিটি লুকআপ প্রদানকারী বা কর্পোরেট রিজলভারের কাছে যেতে পারে, তাই সংযোগের পরে পাবলিক নাম ভিন্নভাবে উত্তর দিলে তা প্রত্যাশিত। বিভক্ত DNS-এর অধীনে কেবল তালিকাভুক্ত ডোমেইন ব্যক্তিগত রিজলভারে যায়, বাকি সব স্থানীয় থাকে; Windows-এ ডোমেইন তালিকা থাকে Name Resolution Policy Table-এ, macOS-এ DNS সেটিংসের ম্যাচ ডোমেইনে, আর systemd-resolved হোস্টে প্রতি-লিঙ্ক রাউটিং ডোমেইনে।
এই তুলনাটিই আগে করতে হবে, কারণ এটি নির্ধারণ করে কী ত্রুটি হিসেবে গণ্য। বিভক্ত DNS-এ, নতুন রিজলভার থেকে উত্তর দেওয়া একটি পাবলিক নামই তদন্তের যোগ্য, আর সঠিকভাবে উত্তর দেওয়া অভ্যন্তরীণ নাম হলো সিস্টেম তার কাজ করছে। সম্পূর্ণ টানেলে, যে পাবলিক নাম এখনো আপনার ISP রিজলভার থেকে উত্তর দেয় সেটিই অস্বাভাবিক। Microsoft-এর VPN নাম সমাধান সম্পর্কিত ডকুমেন্টেশন Windows-এ এই নিয়মগুলোর ক্রম বর্ণনা করে, যার মধ্যে রয়েছে কীভাবে মিলে যাওয়া নীতি এন্ট্রি অ্যাডাপ্টারের নিজস্ব সার্ভারের আগে বিবেচিত হয়।
ঘরে তৃতীয় একটি রিজলভার আছে যা ভুলে যাওয়া সহজ। ব্রাউজারের সুরক্ষিত DNS নিজেই নাম সমাধান করে এবং টানেল অপারেটিং সিস্টেমের নীতি বদলানোর পরেও উত্তর দিতে পারে, তাই যে পৃষ্ঠা লোড হয় তা প্রমাণ করে ব্রাউজারের রিজলভার কাজ করেছে, প্রোফাইল প্রয়োগ হয়েছে তা নয়। আপনি যদি কেবল ব্রাউজার যা দেখায় তা তুলনা করেন, তবে অর্ধেক সময় আপনি ভুল স্তর পরীক্ষা করছেন।
কেবল একটি চলক দিয়ে ভিত্তিরেখা রেকর্ড করুন
টানেল বদলান। একই ধাপে নাম, টুল বা অনুসন্ধান প্রসর্গও বদলাবেন না। এমন একটি নাম বাছুন যেটি জিজ্ঞাসা করার অনুমতি আপনার আছে, কোন অ্যাপ্লিকেশন ব্যবহার করেছেন তা টুকে রাখুন, এবং হয় ফিরে আসা ঠিকানাটি নয়তো সঠিক ত্রুটিটি লিখে রাখুন। Windows-এ Get-DnsClientServerAddress -AddressFamily IPv4 প্রতি-অ্যাডাপ্টার সার্ভার প্রিন্ট করে এবং Get-DnsClientNrptPolicy নীতি এন্ট্রি প্রিন্ট করে; systemd-resolved সহ Linux-এ resolvectl status প্রতি-লিঙ্ক DNS সার্ভার ও রাউটিং ডোমেইন দেখায়; macOS-এ scutil --dns সিস্টেম যে রিজলভার ক্রম সত্যিই অনুসরণ করবে তা প্রিন্ট করে।
তারপর ক্লায়েন্টের স্বাভাবিক নিয়ন্ত্রণ দিয়ে সংযোগ করুন এবং ঠিক একই কমান্ড পুনরাবৃত্তি করুন। প্রথম আউটপুটটি মনে রাখার বদলে রেখে দিন, কারণ তুলনাটাই পুরো বিষয়, আর ক্যাশ পরিষ্কারের পরে নেওয়া দ্বিতীয় পাঠ ইতিমধ্যেই ভিন্ন মাপ। যদি ভিত্তিরেখা ব্রাউজার সামনে রেখে নেওয়া হয় এবং সংযোগ-পরবর্তী চালনা টার্মিনালে ঘটে, তবে আপনি দুই রিজলভার তুলনা করছেন, এক রিজলভারের দুই অবস্থা নয়।
স্পষ্ট কোয়েরি ও অ্যাপ্লিকেশন লুকআপ ভিন্ন পরীক্ষা
একটি নির্দিষ্ট সার্ভারকে জিজ্ঞাসা করা, nslookup name 10.20.0.1 বা dig @10.20.0.1 name দিয়ে, একটি বিষয়ই প্রমাণ করে: আপনি যে সার্ভারের নাম দিয়েছেন সেটি উত্তর দেয় যখন আপনি তার কাছে পৌঁছাতে পারেন। এটি নির্বাচন লজিক সম্পূর্ণ এড়িয়ে যায়, তাই সিস্টেম এই নামের জন্য ওই সার্ভার বেছে নিত কি না তা এটি বলতে পারে না। নির্ধারিত রিজলভার পৌঁছানোযোগ্য কি না তা পরীক্ষা করতে এটি ব্যবহার করুন, আর নীতি পরীক্ষা করতে এটি ব্যবহার করবেন না।
স্থানীয় রিজলভারের মধ্য দিয়ে লুকআপ নির্বাচন সত্যিই প্রয়োগ করে। resolvectl query name একই রাউটিং-ডোমেইন নিয়ম হাঁটে এবং কোন প্রোটোকল উত্তর দিয়েছে তা জানায়, Windows-এ Resolve-DnsName নীতি তালিকা ও ক্লায়েন্ট ক্যাশের মধ্য দিয়ে যায়, আর scutil --dns লুকআপ যে ক্রম অনুসরণ করবে তা দেখায়। দুই ধরনেরই চালান এবং আপনার টীকায় আলাদা কলামে রাখুন। সফল স্পষ্ট কোয়েরির পাশে ব্যর্থ অ্যাপ্লিকেশন লুকআপ রাউটিং বা নির্বাচনের সমস্যা, কাজ করতে অস্বীকার করা রিজলভার নয়।
ক্যাশিং আপনার ও উত্তরের মাঝে দাঁড়িয়ে থাকে। অপারেটিং সিস্টেম, স্থানীয় স্টাব রিজলভার, ব্রাউজার এবং নেতিবাচক ক্যাশিং সবই ফল ধরে রাখে, তাই একটি প্যাকেটও মেশিন ছাড়াই একটি লুকআপ সফল হতে পারে। কিছু পরিষ্কার করার আগে ফলটি লিখে রাখুন: ipconfig /flushdns, resolvectl flush-caches, বা macOS-এ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder। এই পর্যায়ে বিস্তৃত নেটওয়ার্ক রিসেট বাদ দিন, কারণ এটি আপনার এখনো সংগ্রহ করা প্রমাণ নষ্ট করে।
পার্থক্যটি কী বোঝায়
আপনি যে দুই সারি রেকর্ড করেছেন তা তুলনা করুন এবং একটি সেটিংও স্পর্শ করার আগে পরিবর্তনটিকে শ্রেণিবদ্ধ করুন।
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
একটি সারি বিশেষ জোর পাওয়ার যোগ্য। যে নাম সমাধান হয় তা কাজ করা সেবা নয়, আর DNS-এর সাফল্য কেবল বলে যে একটি ঠিকানা পাওয়া গেছে। এটি ফরওয়ার্ডিং, ফায়ারওয়াল নিয়ম, বা আপনার অ্যাকাউন্ট আদৌ সেবাটি ব্যবহার করতে পারে কি না সে সম্পর্কে কিছুই বলে না, তাই ব্যর্থতা নিজে থেকে সরে গেছে ধরে নেওয়ার বদলে প্রকৃত অ্যাপ্লিকেশন পরীক্ষা করে শেষ করুন।
ভিত্তিরেখা ফিরিয়ে আনুন এবং যাচাই করুন
প্রসেসটি মেরে ফেলার বদলে ক্লায়েন্টের নিজস্ব নিয়ন্ত্রণ দিয়ে সংযোগ বিচ্ছিন্ন করুন, তারপর একই তিনটি কমান্ড আবার পড়ুন। প্রতি-লিঙ্ক সার্ভার, নীতি এন্ট্রি এবং আপনার পরীক্ষার নামের উত্তর আগে লেখা ভিত্তিরেখায় ফিরে আসা উচিত। পরিষ্কার বিচ্ছিন্নতার পরে অবশিষ্ট নীতি এন্ট্রি একটি প্রকৃত ত্রুটি যা নথিভুক্ত করার যোগ্য, এবং এ কারণেই জেনারেট করা রিজলভার ফাইলে হাতে সম্পাদনা খারাপ অভ্যাস: ফাইলটি আবার লেখা হয় ও সম্পাদনা উধাও হয়, বা সম্পাদনা টিকে থাকে এবং এমন রিজলভার পিন করে যার আর কোনো রুট নেই।
এই তালিকাটি একবার, ক্রম অনুযায়ী কাজ করুন। কোনো ফল বিচার করার আগে প্রোফাইলটি কোন ডিজাইন বাস্তবায়ন করে তা ঠিক করুন। দুই চালনায় নাম, টুল ও প্রসর্গ স্থির রাখুন। স্পষ্ট কোয়েরিকে অ্যাপ্লিকেশন লুকআপ থেকে আলাদা করুন। কেবল উত্তর নয়, কার্যকর নীতি পড়ুন। তুলনা লেখা হয়ে যাওয়ার পরে সবশেষে ক্যাশ পরিষ্কার করুন। প্রকৃত অ্যাপ্লিকেশন দিয়ে যাচাই করুন, তারপর একবার রিবুট করে নিশ্চিত করুন যে বিচ্ছিন্ন অবস্থাটি এখনো পরিষ্কার।