VPN DNS বনাম ব্রাউজার DoH: লিক পরীক্ষা যা আপনাকে বলতে পারে না
একটি লিক-পরীক্ষার ঠিকানা কেবল দেখায় কোন রিজলভার উত্তর দিয়েছে। এনক্রিপ্টেড কোয়েরি, বিভক্ত DNS এবং ব্রাউজার নীতি ঠিক করে ব্যক্তিগত নামগুলো আদৌ রিজলভ হয় কি না।
লিক-পরীক্ষার পাতা বলে আপনার DNS ঠিক আছে, ব্রাউজারের ব্যাজ বলে এটি নিরাপদ, অথচ অভ্যন্তরীণ উইকি তবুও লোড হয় না। তিনটিই একসঙ্গে সত্য হতে পারে, কারণ একটি রিজলভারের ঠিকানা আর যে নীতি সেটি বেছে নিয়েছে বা কোয়েরি যে পথে গেছে তা এক জিনিস নয়। মানুষ যা DNS লিক বলে, তা আসলে একটি প্রশ্ন: নামটি কোন রিজলভার পেয়েছে, আর সেই পছন্দ কি ইচ্ছাকৃত ছিল? এটি গুছিয়ে ফেলতে তিনটি পরীক্ষা লাগে, এবং কেবল শেষটিতেই একটি সেটিং বদলাতে হয়।
প্রথম ভ্রম: ব্যাজ আপনার রিজলভারের নাম বলে
একটি লিক পরীক্ষা একটি প্রোব নাম রিজলভ করে এবং যে ঠিকানাটি উত্তর দিয়েছে তা জানায়। এটি সেই নীতি জানায় না যা ওই রিজলভার বেছেছিল, আর যখন কোয়েরিটি DNS over HTTPS-এ মোড়া থাকে, পথের মধ্যস্থ বাক্স নামটি একেবারেই দেখতে পায় না। দুই সম্পূর্ণ ভিন্ন মেশিন একই আশ্বস্তকারী ব্যাজ দেয়: একটিতে VPN 10.8.0.1 পাঠিয়েছে এবং ব্রাউজার সেটিই ব্যবহার করছে, অন্যটিতে ব্রাউজার সিস্টেম তালিকা উপেক্ষা করে নামটি টানেলের ভেতর দিয়ে নিজের এনক্রিপ্টেড প্রদানকারীর কাছে পাঠিয়েছে।
পার্থক্যটি তখনই গুরুত্বপূর্ণ যখন একটি ব্যক্তিগত নাম ব্যর্থ হয়। প্রথম ব্যবস্থায় VPN রিজলভার কর্পোরেট জোনের জন্য উত্তর দেয়; দ্বিতীয়টিতে ব্রাউজার তাকে কখনো জিজ্ঞাসাই করেনি, তাই ছোট হোস্টনামটি রিজলভ হয় না এবং ব্যর্থতাটি ভাঙা VPN-এর মতো দেখায়। পরীক্ষাটি আরেকটি লিক পরীক্ষা নয়, এটি এমন একটি নামের সন্ধান যা কেবল একটি রিজলভার জানে।
দ্বিতীয় ভ্রম: ব্রাউজার টানেল ছেড়ে যায়
DNS একটি ঠিকানা বেছে নেয়, রাউটিং সংযোগ বহন করে, আর এ দুটি আলাদা স্তর। একটি সর্বজনীন DoH প্রদানকারীর কাছে পাঠানো কোয়েরি এখনও রাউটযোগ্য ঠিকানার TCP পোর্ট 443। যদি আপনার রুট টেবিল ডিফল্ট রুটটিকে টানেলে পাঠায়, তবে সেই কোয়েরিও টানেলের ভেতর দিয়ে যায়। রিজলভারের ব্র্যান্ড পথ নির্ধারণ করে না।
ব্রাউজার DoH যা বদলায় তা হলো নামগুলোর প্রাপক। এটি সত্যিকারের গোপনীয়তা সিদ্ধান্ত এবং সত্যিকারের নীতি সিদ্ধান্ত, কিন্তু এটি রাউটিং বাইপাস নয়। যদি আপনার দাবি হয় নামগুলো VPN অপারেটরের কাছে থাকবে, তবে অন্য কারও কাছে এনক্রিপ্টেড কোয়েরি সেই দাবি ব্যর্থ করে, যদিও এটি বাস্তব সংযোগের জন্য এখনও টানেল ব্যবহার করে।
তৃতীয় ভ্রম: প্রতিটি VPN প্রতিটি ব্রাউজারকে ছাড়িয়ে যায়
ব্রাউজারে সুরক্ষিত DNS-এর মোড থাকে, সুইচ নয়: বন্ধ, ফলব্যাকসহ ডিফল্ট প্রদানকারী, কাস্টম টেমপ্লেট, বা অপারেটিং সিস্টেম বা প্রতিষ্ঠানের আরোপিত নীতি। ফলব্যাক ক্ষেত্রটিই মাঝে মাঝে রিপোর্ট তৈরি করে। যখন এনক্রিপ্টেড এন্ডপয়েন্টে পৌঁছানো যায় না, ব্রাউজার সিস্টেম রিজলভারে ফিরে যেতে পারে, তাই একই ল্যাপটপ সোমবার ব্যক্তিগত নাম সঠিকভাবে রিজলভ করে, মঙ্গলবার করে না।
একই সময়ে, অধিকাংশ VPN ক্লায়েন্ট সংযোগ ওঠার সময় সিস্টেম রিজলভার সেট করে এবং সংযোগ নামলে আগেরটি ফিরিয়ে দেয়। কাস্টম এনক্রিপ্টেড রিজলভার ধরে রাখা ব্রাউজার সেই পুনরুদ্ধার একেবারেই দেখতে পায় না। এ কারণেই একই প্রোফাইল দুটি ল্যাপটপে ভিন্নভাবে আচরণ করে এবং এ কারণেই resolv.conf ঠিক দেখায়, অথচ ব্রাউজার তখনও অন্য কাউকে জিজ্ঞাসা করছে।
resolvectl status # per-link DNS servers and split-DNS domains
scutil --dns | head -30 # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1 # ask the VPN resolver directlyসংযুক্ত থাকার সময় ওগুলো চালান, প্রতিটি রিজলভার কোন ডোমেইনের দাবি করে তা লক্ষ করুন, এবং ব্রাউজার তার নিজের মোড সম্পর্কে যা জানায় তার সঙ্গে তুলনা করুন। Mozilla-র DoH ডকুমেন্টেশন ব্রাউজারের ডিফল্ট ও ফলব্যাক আচরণ কেমন হওয়া উচিত তার যুক্তিসঙ্গত বর্ণনা।
সিদ্ধান্তের তিনটি ইনপুট, একটি নয়
ব্যক্তিগত নাম, অপারেটরের প্রতি আস্থা এবং পৌঁছানোর ক্ষমতা সঠিক ব্যবস্থা নির্ধারণ করে। যে নাম কেবল VPN রিজলভার জানে তা বিভক্ত DNS বাধ্যতামূলক করে: ব্যক্তিগত প্রত্যয়টি পাঠানো রিজলভারের কাছে যায়, বাকি সবকিছু সর্বজনীন নামের জন্য আপনার বেছে নেওয়া নীতি অনুসরণ করে। অপারেটরের প্রতি আস্থা ঠিক করে সর্বজনীন নামগুলোও সেই রিজলভারের কাছে যাবে কি না, নাকি আলাদা সেবার কাছে। পৌঁছানোর ক্ষমতা ঠিক করে আপনার বেছে নেওয়া এনক্রিপ্টেড রিজলভার এই নেটওয়ার্কে আদৌ ব্যবহারযোগ্য কি না।
| Condition | What it forces |
|---|---|
| Internal names must resolve | Split DNS: private suffixes to the VPN resolver, the rest to your chosen default |
| Queries must stay with one operator | Pin both the system resolver and the browser mode, and disable fallback |
| Resolver only reachable through the tunnel | Keep the pushed resolver; do not point DoH at an endpoint your routes exclude |
এই সারিগুলোর কোনোটিই সর্বজনীন সুপারিশ নয়। VPN-পরিচালিত রিজলভার পর্যবেক্ষণগুলো সেই অপারেটরের কাছে কেন্দ্রীভূত করে; আলাদা সেবা কোয়েরি করা নামের আরেকটি প্রাপক যোগ করে। কোনোটিই ধরে রাখার বিষয়ে কিছু প্রমাণ করে না, যদি না আপনি নীতিটি পড়েন।
প্রতিটি প্রোফাইলের জন্য সিদ্ধান্তটি লিখে রাখুন, কারণ এই সেটিংসগুলো সরে যায়। গত মাসে যে প্রোফাইল একটি রিজলভার পাঠিয়েছিল, আজ সে কিছুই না-ও পাঠাতে পারে, আর ব্রাউজার সানন্দে পুরোনো কাস্টম এন্ডপয়েন্ট ধরে রাখবে যা এখনও উত্তর দেয়। নোটে থাকা উচিত রিজলভারের ঠিকানা, তার মালিকানা করা প্রত্যয় এবং ব্রাউজার মোড, সেবার ব্র্যান্ড নয়।
আপনি যে নীতি কনফিগার করেছেন বলে মনে করেন, সেটিই পরীক্ষা করুন
ব্যাজ দিয়ে নয়, নাম দিয়ে পরীক্ষা করুন। সিস্টেম রিজলভারের মাধ্যমে একটি সর্বজনীন নাম ও একটি ব্যক্তিগত নাম রিজলভ করুন, তারপর আপনি যে মোড ব্যবহার করতে চান সেই মোডে ব্রাউজারের নিজের সুরক্ষিত DNS সেটিং দিয়ে পুনরাবৃত্তি করুন। যদি ব্যক্তিগত নামটি কেবল ব্রাউজারেই ব্যর্থ হয়, তবে একটি VPN সেটিংও না ছুঁয়ে আপনি প্রাপকের অমিল খুঁজে পেয়েছেন।
তারপর আবার সংযোগ করুন এবং পুনরুদ্ধার যাচাই করুন, কারণ হ্যান্ডঅফ বাগগুলো ওখানেই থাকে: সংযোগ বিচ্ছিন্ন করুন, নিশ্চিত করুন আগের রিজলভার ফিরে এসেছে, আবার সংযোগ করুন, নিশ্চিত করুন পাঠানো রিজলভার ফিরে এসেছে। শেষে, যদি থাকে তবে ম্যানেজড নীতি সহ একটি ব্রাউজার পরীক্ষা করুন, কারণ সেই মোড আপনার পরিবর্তন পুরোপুরি প্রত্যাখ্যান করে চুপচাপ আগের রিজলভার ধরে রাখতে পারে।
নেমস্পেস প্রশ্ন দিয়ে শুরু করুন এবং এর বেশিরভাগটাই এড়িয়ে যাবেন। যদি মেশিনটিকে অভ্যন্তরীণ নামে পৌঁছাতে হয়, তবে ব্রাউজারের এনক্রিপ্টেড রিজলভার কেবল সর্বজনীন অর্ধেক নিয়ে সিদ্ধান্ত, আর ব্যক্তিগত অর্ধেক VPN যা পাঠিয়েছে তার কাছেই থাকে।