আপনার VPN-এর DNS কি সত্যিই ব্যবহৃত হচ্ছে? পোর্ট 53 ধরে দেখুন
পুশ করা DNS অপশন কোনো কোয়েরি পথ নয়। ইন্টারফেসে কী আছে দেখুন, কোয়েরি বেরোনো লক্ষ্য করুন, আর প্রমাণ হিসেবে লিক-টেস্ট পেজে ভরসা করা বন্ধ করুন।
বেশিরভাগ মানুষকে জিজ্ঞাসা করুন একটি VPN ক্লায়েন্ট DNS নিয়ে কী করে, তাঁরা বলবেন এটি রিজলভার সেট করে, তাই কোয়েরিগুলো টানেলের ভিতরে ভ্রমণ করে। পুশটি সত্যি; কিন্তু এটি একটি কোয়েরিতে পরিণত হয়—এই ধারণাটি নয়। একটি পুশ করা অপশন আর তারের উপর একটি প্যাকেটের মাঝে তিনটি স্তর রয়েছে, এবং প্রতিটি স্বাধীনভাবে এমনভাবে ব্যর্থ হয় যে সবই ভাঙা DNS সার্ভারের মতো দেখায়। এজন্যই একটি লিক-টেস্ট পেজ আর একটি কাজ করা ব্রাউজার একই মুহূর্তে একই মেশিন নিয়ে ভিন্ন মত দিতে পারে।
পুশ করা অপশন কোনো কোয়েরি নয়
প্রথম স্তর হলো সার্ভারের সেটিংস দেওয়া, যেমন টানেলের ভিতরের একটি রিজলভার উল্লেখ করা পুশ করা DNS অপশন। দ্বিতীয় স্তর হলো ক্লায়েন্টের সেই সেটিংস একটি ইন্টারফেসে প্রয়োগ করা। তৃতীয় স্তর হলো কোনো অ্যাপ্লিকেশনের সত্যিই সেই ঠিকানায় কোয়েরি পাঠানো। দ্বিতীয় স্তরে ব্যর্থতা অপশনটি সংযোগ লগে দৃশ্যমান রেখে দেয় অথচ রিজলভার তালিকা অপরিবর্তিত থাকে, আর তৃতীয় স্তরে ব্যর্থতা নিখুঁতভাবে সঠিক রিজলভার তালিকাকে অব্যবহৃত রেখে দেয়।
বেশিরভাগ সমস্যা-অনুসন্ধান ওই তিনটিকে এক করে ফেলে এবং VPN সার্ভারকে দোষ দেয়, অথচ সাধারণত একমাত্র সেই পক্ষই প্রমাণ করতে পারে যে সে তার অংশ করেছে। বরং ক্লায়েন্টের প্রকৃত রিজলভার অবস্থা পড়ুন, তারপর একটি কোয়েরি বেরোনো দেখুন। এই দুটি পর্যবেক্ষণ কনফিগারেশনকে রাউটিং থেকে এবং রাউটিংকে নীতি থেকে আলাদা করে, আর এতে লাগে মাত্র পাঁচ মিনিটের মতো। ক্যাপচারগুলো রেখে দিন, কারণ পরের ইঞ্জিনিয়ার তাদের বর্ণনা নয়, আগে ও পরে চান।
ইন্টারফেসে আসলে কী আছে তা দেখুন
Linux-এ সিস্টেম রিজলভার সাধারণ ফাইল, NetworkManager বা systemd-resolved হতে পারে, এবং এর মধ্যে কোনটি এটি মালিকানায় রাখে তা ঠিক করে একটি পুশ করা সার্ভার কোথায় পৌঁছাবে। কমান্ড-লাইনের একটি OpenVPN প্রক্রিয়া নিজে থেকে সিস্টেম রিজলভার হালনাগাদ করে না, তাই নথিভুক্ত ইন্টিগ্রেশন হলো একটি up/down স্ক্রিপ্ট বা এমন একটি সংযোগ ব্যবস্থাপক যা ইতিমধ্যেই সেটিংস প্রয়োগ করতে জানে। দুটোই একসাথে চালানো রেস তৈরি করার একটি দক্ষ উপায়।
resolvectl status
cat /etc/resolv.conf
Windows-এ তালিকাটি প্রতিটি অ্যাডাপ্টারের জন্য আলাদা, তাই টানেল অ্যাডাপ্টার অভ্যন্তরীণ সার্ভার ধরে রাখতে পারে আর ফিজিক্যাল অ্যাডাপ্টার স্থানীয়গুলো ধরে রেখে কিছু নামের জন্য জিতে যায়। আপনি সক্রিয় মনে করেন এমনটির বদলে দুই অ্যাডাপ্টারই তুলনা করুন।
একটি কোয়েরিকে মেশিনের বাইরে অনুসরণ করুন
দুই ইন্টারফেস একসাথে ক্যাপচার করুন, তারপর এমন একটি নাম রিজলভ করুন যা অভ্যন্তরীণ রিজলভার ব্যবহার করা উচিত। ওই জোড়া ক্যাপচারই তার উত্তর দেয় যা কোনো কনফিগারেশন আউটপুট দিতে পারে না।
sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53
যে কোয়েরি ফিজিক্যাল ইন্টারফেসে দেখা যায় এবং টানেলে কখনোই দেখা যায় না, তার মানে ক্লায়েন্ট ভুল রিজলভার বেছেছে। যে কোয়েরি কোনোটিতেই দেখা যায় না, তার মানে অ্যাপ্লিকেশন ক্যাশ থেকে উত্তর দিয়েছে, loopback-এ শোনা কোনো স্টাবকে জিজ্ঞাসা করেছে, অথবা এনক্রিপ্টেড রিজলভার ব্যবহার করেছে যার ট্রাফিক কখনোই পোর্ট 53 হিসেবে দেখা যায় না। কোয়েরির সাথে উত্তরও ক্যাপচার করুন, কারণ টানেল দিয়ে বেরোনো কোয়েরির পাবলিক ঠিকানা থেকে আসা উত্তর আর কোনো উত্তর না আসা—এ দুটি আলাদা ত্রুটি।
যে ফায়ারওয়াল কেবল নিজের DNS গ্রহণ করে
বাণিজ্যিক ক্লায়েন্ট কখনো কখনো নিজেদের ফিল্টার চেইন ইনস্টল করে। একটি নথিভুক্ত প্যাটার্ন ক্লায়েন্টের নিজের রিজলভার পর্যন্ত DNS অনুমোদন করে এবং non-loopback ইন্টারফেস ছাড়ার চেষ্টা করা বাকি সব UDP পোর্ট 53 ট্রাফিক বাতিল করে, এমনকি ব্যবহারকারীর ইচ্ছাকৃতভাবে অন্যত্র পাঠানো ট্রাফিকও। ডেমন কোয়েরি কোনো চিহ্ন ছাড়াই উধাও হয়, যা ফিল্টার নয় বরং রিজলভার বিকল হিসেবে পড়া হয়।
sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'
যদি আপনার ব্যতিক্রমের আগেই কোনো বাতিল করার নিয়ম মূল্যায়িত হয়, তবে পরে যোগ করা নিয়ম কখনোই পৌঁছায় না, তাই প্রথম অবস্থানে ঢোকান এবং গন্তব্যটি সীমাবদ্ধ করুন সেই রিজলভারে যা আপনি সত্যিই চান।
sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT
সেই ব্যতিক্রম নীতি নয়, রোগনির্ণয়। যদি ভেন্ডরের নিয়মটি ইচ্ছাকৃত হয়, তবে সমর্থিত সমাধান হলো ক্লায়েন্টকে সেই রিজলভার অনুমোদন করতে কনফিগার করা এবং সিদ্ধান্তটি লিপিবদ্ধ করা, কারণ ঢোকানো নিয়ম পরের ক্লায়েন্ট আপগ্রেড পর্যন্ত টিকবে না।
লিক পেজ কেন যতটা মনে হয় তার চেয়ে কম প্রমাণ করে
একটি লিক-টেস্ট পেজ যা দেখায় তা হলো সেই রিজলভার যা পরীক্ষা পরিচালকের সাথে কথা বলেছে, আপনার মেশিন যাকে জিজ্ঞাসা করেছে তা নয়। বাইরে রিকার্স করা একটি স্থানীয় ফরওয়ার্ডার তার নিজের ইগ্রেস ঠিকানা ওই পেজে বসিয়ে দেয়, আর এনক্রিপ্টেড কোয়েরি পেজটি পুরোপুরি ফাঁকা রেখে যেতে পারে। দুটি ফলাফলই ভুলভাবে পড়া হয়, একটি লিক আর অন্যটি নিশ্চয়তা হিসেবে, এবং কোনও পাঠই পর্যবেক্ষণ থেকে আসে না।
রক্ষণযোগ্য প্রমাণ হলো ক্যাপচার: ইন্টারফেস, গন্তব্য ঠিকানা, উত্তর এবং টাইমস্ট্যাম্প। টানেল ওঠার আগে একটি এবং পরে একটি নিন, আর পরের বার কোনো নাম ব্যর্থ হলে সেগুলো তুলনা করুন। ওই জোড়া পরের মানুষটিকেও বলে দেয় ত্রুটি ছিল রিজলিউশনে, রাউটিংয়ে নাকি রিজলভারের নিজের অ্যাক্সেস নীতিতে।