কেন হটস্পট VPN সংযোগের আগেই DNS রিডাইরেক্ট করে?
হটস্পট নিজের নেটওয়ার্কে লুকআপ পুনর্লিখন করে, আর হোস্টনেম এন্ডপয়েন্ট যেকোনো টানেল তৈরির আগেই রিজলভ হয়। কোন রিজলভার কোন কোয়েরির উত্তর দিয়েছে তা অনুসরণ করুন।
হোটেল নেটওয়ার্কে যোগ দেওয়া আপনার সামনে ভিন্ন ভিন্ন সময়ে দুটি DNS সিদ্ধান্ত রাখে: সাইন ইন করার সময় ডিভাইস যেসব লুকআপ করে, এবং টানেল চালু হওয়ার পর যেসব লুকআপ করা হয়। হটস্পট যে নেটওয়ার্ক নিয়ন্ত্রণ করে তার মাধ্যমে প্রথমটিকে প্রভাবিত করতে পারে। দ্বিতীয়টি ক্লায়েন্টের নিজের নীতির উপর নির্ভর করে, যা পরীক্ষা করার আলাদা বিষয়।
সংযোগটি ক্রমে অনুসরণ করুন, প্রথম DHCP লিজ থেকে সেই কোয়েরি পর্যন্ত যা একটি প্রাইভেট নাম রিজলভ করেছে। তখন সাপোর্ট টিকিটে একই রকম দেখানো দুটি ব্যর্থতা পরিষ্কারভাবে আলাদা হয়: একটি ঘটেছিল টানেল তৈরির আগে, আর অন্যটি ঘটেছিল তার ভিতরে।
হটস্পট কী স্পর্শ করতে পারে আর কী পারে না
অ্যাক্সেস নেটওয়ার্ক DHCP-তে একটি রিজলভার ঠিকানা দেয় এবং সেই ঠিকানার দিকে পোর্ট 53 আটকে ধরতে পারে। এটি প্রতিটি অরক্ষিত লুকআপকে পোর্টাল ঠিকানা বা ব্লক পেজ দিয়ে উত্তর দেওয়ার জন্য যথেষ্ট। এটি এমন একটি VPN ক্লায়েন্ট ভাঙার জন্যও যথেষ্ট যার এন্ডপয়েন্ট হোস্টনেম হিসেবে লেখা।
হটস্পট যা করতে পারে না তা হল, একটি প্রতিষ্ঠিত টানেলের ভিতরে কোয়েরি চলার পর তা পড়া বা পুনর্লিখন করা, যদি ধরে নিই টানেল সত্যিই তা বহন করে। আটকানো নির্ভর করে প্লেইনটেক্সট প্রশ্নটি দেখার উপর।
কোয়েরিগুলো হটস্পটের সঙ্গে সম্পর্কহীন কারণে যেভাবেই হোক টানেল ছেড়ে যায়: ব্রাউজারের সিকিউর DNS সেটিং, একটি split-DNS নিয়ম যা কর্পোরেট সাফিক্স লোকাল রিজলভারে রাখে, বা এমন ক্লায়েন্ট যা DNS-কে টানেল থেকে বাদ দিতে কনফিগার করা। প্রতিটি ক্লায়েন্টের দিকের পছন্দ, এবং বাইরে থেকে দেখলে প্রতিটিই হটস্পটের হস্তক্ষেপের মতো দেখায়।
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
বুটস্ট্র্যাপ লুকআপ টানেল তৈরির আগেই ঘটে
হোস্টনেম দেওয়া একটি ক্লায়েন্টকে আগে তা রিজলভ করতে হয়, এবং সেই মুহূর্তে কোনো টানেল কোয়েরিকে রক্ষা করে না। হটস্পট যদি পোর্টাল ঠিকানা দিয়ে উত্তর দেয়, নেগোশিয়েশন ব্যর্থ হয় বা ঝুলে যায়। যদি কিছুই না দিয়ে উত্তর দেয়, ক্লায়েন্ট নাম ত্রুটি জানায় এবং টানেল কখনোই শুরু হয় না। দুই ফলাফলের যেকোনোটি এমন একটি খালি টানেল লগ ব্যাখ্যা করে যা অন্যথায় নিরীহ দেখায়।
অপারেটিং সিস্টেমও নিজেদের সংযোগ পরীক্ষা ও পোর্টাল আবিষ্কার চালায়, যা RFC 8910 এবং RFC 8952-তে বর্ণিত, এবং সেই অনুরোধগুলো যেকোনো VPN চালু হওয়ার আগেই বেরিয়ে যায়। প্রক্সি লগে সেগুলো দেখা লিকের প্রমাণ নয়, প্রত্যাশিত আচরণ।
ব্যবহারিক সমাধান হল ক্লায়েন্টকে এমন একটি এন্ডপয়েন্ট দেওয়া যার কোনো লুকআপ দরকার নেই। যখন তা অসম্ভব, আগে সাইন ইন শেষ করুন তারপর সংযোগ করুন।
কোন রিজলভার উত্তর দিয়েছে তা খুঁজে বের করুন
ব্রাউজার নয়, সিস্টেমকে জিজ্ঞাসা করুন এবং কোয়েরিটি দুইবার চালান: একবার ডিভাইস এখন যে রিজলভার ব্যবহার করে তার মাধ্যমে, একবার একটি নির্দিষ্ট ঠিকানার বিরুদ্ধে।
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
প্রথম কমান্ডের উত্তর যদি তৃতীয়টির থেকে আলাদা হয়, তা বলে দেয় লোকাল রিজলভার অন্য কিছু ফেরত দিচ্ছে, আর রিডাইরেক্টিং হটস্পট ঠিক এটাই করে। তৃতীয়টির ব্যর্থতা প্রথমটির সাফল্যের সঙ্গে থাকলে তা পোর্টালের দিকে ইঙ্গিত করে: লোকাল রিজলভার সাইন-ইন ঠিকানা সরবরাহ করেছে যখন আউটবাউন্ড পোর্ট 53 বাদ পড়েছে। দুইটিতেই টাইমআউট মানে নেটওয়ার্ক প্রমাণীকরণ শেষ না হওয়া পর্যন্ত DNS বাতিল করে।
সংযোগের পর পুনরাবৃত্তি করুন ও তুলনা করুন। ক্যাশ করা উত্তর রূপান্তরটি টিকে যায়, তাই ক্যাশ ফ্লাশ করুন বা দ্বিতীয় পর্যবেক্ষণের জন্য নতুন নামে কোয়েরি করুন।
পরবর্তী লুকআপগুলো আপনার ইচ্ছাকৃত পথেই রাখুন
যে ফুল-টানেল প্রোফাইল DNS-ও ধরে, সেটিই সবচেয়ে সরল ব্যবস্থা: প্রতিটি অ্যাপ্লিকেশনের প্রতিটি কোয়েরি টানেল যে রিজলভার ঠেলে দেয় সেখানে যায়, আর লোকাল নেটওয়ার্ক শুধু এনক্রিপ্টেড ট্রাফিক দেখে। সংযোগের পর একটি অভ্যন্তরীণ ও একটি পাবলিক নাম রিজলভ করে এবং উভয় উত্তর টানেল রিজলভার একা যা ফেরত দেয় তার সঙ্গে তুলনা করে এটি প্রমাণ করুন।
Split-DNS-এর জন্য উদ্দেশ্য নিয়ে লেখা একটি ডোমেইন তালিকা দরকার: কর্পোরেট সাফিক্স টানেলের মাধ্যমে, বাকি সব লোকালি, এবং দুইয়ের মধ্যে কোনো ওভারল্যাপ নেই।
ব্রাউজারের সিকিউর DNS সেই নীতির বাইরে থাকে, তাই প্রোফাইলটি পূর্বানুমেয়ভাবে চলার জন্য যদি এটি বন্ধ থাকা দরকার হয়, তবে মেশিনের জন্য নয়, ওই প্রোফাইলের জন্য বন্ধ করুন। এটি সিস্টেম রিজলভার সম্পাদনা করে নয়, ব্রাউজার সেটিংসে করুন, যাতে পরিবর্তনটি পরের বার দৃশ্যমান হয়। প্রতিটি পরীক্ষার জন্য এক লাইনে উত্তর, রিজলভার ও সংযোগের পর্যায় লিখুন। যে প্রতিবেদন বলে হোটেল Wi-Fi-তে DNS ব্যর্থ হয়েছে, তা অন্তত তিনটি ভিন্ন কারণসহ একটি উপসর্গ বর্ণনা করে।