VPN সংযুক্ত, কিন্তু নাম ব্যর্থ: DNS আসলে কোথায় ভাঙে

টানেল চালু, আইকন সবুজ, আর ব্রাউজারের প্রতিটি ট্যাব নাম-রেজলিউশনের ব্যর্থতা জানাচ্ছে। তিনটি ভিন্ন প্রক্রিয়া এই ছবি তৈরি করে: রিজলভার পৌঁছানোর বাইরে থাকতে পারে, ক্লায়েন্ট এমন রিজলভারকে জিজ্ঞাসা করতে পারে যা আপনি আশা করেননি, অথবা কেবল প্রাইভেট নামগুলো ব্যর্থ হতে পারে। টানেল প্রোটোকলে কিছু বদলানোর আগে এগুলো আলাদা করুন, কারণ প্রতিটি আলাদা জায়গায় মেরামত হয়। নিচের ক্রমটি সেই পর্যবেক্ষণ দিয়ে শুরু যেগুলো তিনটিকে আলাদা করে।

একটি লুকআপের আসলে কী দরকার

একটি লুকআপের তিনটি জিনিস দরকার: একটি রিজলভার ঠিকানা, সেই ঠিকানার পথ এবং প্রশ্নের সঙ্গে মেলে এমন উত্তর। প্রতিটি আলাদাভাবে ব্যর্থ হতে পারে, আর দৃশ্যমান উপসর্গ একই—যে পৃষ্ঠাটি লোড হয় না। তাই তিনটির মধ্যে কোনটি ভেঙেছে তা জানার আগে ত্রুটি পৃষ্ঠা আপনাকে প্রায় কিছুই বলে না।

ক্লায়েন্ট তার রিজলভার জানতে পারে VPN প্রোফাইল থেকে, টানেলের DHCP থেকে বা নিজের কনফিগারেশন থেকে, আর কোন উৎস জিতবে তা প্ল্যাটফর্মের উপর নির্ভর করে। Windows-এ ipconfig /all প্রতিটি অ্যাডাপ্টারের DNS সার্ভার দেখায়, তাই পাঠানো মানটি সত্যিই পৌঁছেছে কি না তা দেখতে পারেন। যে মান কখনও অপারেটিং সিস্টেমে পৌঁছায়নি সেটি একটি নীরব ও সাধারণ ব্যর্থতা। প্রোফাইল স্পর্শ করার আগে কনফিগার করা মানটি পড়ুন।

Linux ও macOS একই প্রশ্নের উত্তর দেয় ভিন্ন কমান্ডে, আর উত্তরটিও একইভাবে পড়া দরকার: resolvectl status এবং scutil --dns দুটোই প্রতি ইন্টারফেসের সার্ভার তালিকা করে। সেই তালিকাটি প্রোফাইল যে ঠিকানা পাঠানোর দাবি করে তার সঙ্গে মেলান। এখানে অমিল হলে পরের সবকিছু ব্যাখ্যা হয়ে যায়, তাই নাম পরীক্ষার আগে এটি মিটিয়ে নিন।

একটি পাবলিক ও একটি প্রাইভেট নাম পরীক্ষা করুন

একই মেশিন থেকে একটি সাধারণ পাবলিক হোস্টনেম ও নথিভুক্ত প্রাইভেট হোস্টনেম জিজ্ঞাসা করুন এবং কোন সার্ভার কোনটির উত্তর দিল তা লিখে রাখুন। দুটোই ব্যর্থ হলে রিজলভার বা তার রুট ভাঙা। কেবল প্রাইভেট নাম ব্যর্থ হলে রিজলভার উত্তর দিয়েছে, আর প্রশ্নটি হয়ে যায় জোন বা রাউটিং। দুই প্রশ্ন এক মিনিটের মধ্যে চালান, যাতে রুট বদল পার্থক্যের ব্যাখ্যা না হতে পারে।

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

nslookup যে সার্ভারকে জিজ্ঞাসা করেছে ও যে উত্তর পেয়েছে দুটোই দেখায়, আর এটিই আপনার দরকারি জোড়া। একই শেল থেকে এটি দুবার চালান এবং প্রতিটি উত্তরের পাশে উত্তরদাতা ঠিকানাটি লিখুন।

nslookup example.com
nslookup host.corp.example 10.20.30.53

ক্লায়েন্ট সত্যিই সেই সার্ভারে পৌঁছাতে পারে কি না নিশ্চিত করুন

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

প্রতিটি প্ল্যাটফর্ম এক লাইনে তার উত্তর দেয়, আর আউটপুটে উল্লিখিত ইন্টারফেসই পুরো উত্তর। যদি এটি ফিজিক্যাল অ্যাডাপ্টারের দিকে দেখায় অথচ রিজলভার টানেলের পিছনে বসে, তবে প্রোফাইল এমন প্রিফিক্স পাঠাচ্ছে না যা তাকে ঢাকে।

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

স্প্লিট-টানেল প্রোফাইলে রিজলভার পাঠানো রুটগুলোর বাইরে থাকতে পারে, যা সার্ভার নয়, প্রোফাইলের সমস্যা। রিজলভার ঠিকানাটি পাঠানো প্রিফিক্সগুলোর সঙ্গে মেলান এবং তাদের একটি তাকে ঢাকে কিনা নিশ্চিত করুন। একই অমিল ব্যাখ্যা করে কেন DNS একটি নেটওয়ার্কে কাজ করে আর অভিন্ন প্রোফাইলে অন্যটিতে ব্যর্থ হয়।

মনে রাখুন ব্রাউজার সিস্টেম রিজলভারকে এড়িয়ে যেতে পারে

সুরক্ষিত DNS চালু থাকা ব্রাউজার নিজের পছন্দের প্রোভাইডারের কাছে HTTPS-এ প্রশ্ন পাঠিয়ে অপারেটিং সিস্টেমের রিজলভার পুরোপুরি উপেক্ষা করতে পারে। তখন সিস্টেম ঠিক দেখায় অথচ ব্রাউজার ব্যর্থ হয়, বা উল্টোটা। এটি টানেলের নয়, ব্রাউজারের নীতিগত প্রশ্ন।

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

ক্যাশ মুছুন ও আসল কাজটি আবার পরীক্ষা করুন

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

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

তারপর কৃত্রিম লুকআপের বদলে মূল কাজটি পুনরাবৃত্তি করুন, কারণ ব্যবহারকারীর কাছে কাজটিই গুরুত্বপূর্ণ। একবার আবার সংযোগ করুন, যাতে পুনঃপরীক্ষা সেই অবস্থা ঢাকে যেখানে ব্যবহারকারী সত্যিই থাকবেন। Microsoft-এর nslookup রেফারেন্স প্রশ্নের আর্গুমেন্টের জন্য রাখার মতো পৃষ্ঠা।

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