আপনার VPN কি DNS এনক্রিপ্ট করে, নাকি শুধু পরের হপ?

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

কনফিগারেশন ফাইলে হাত দেওয়ার আগে প্রতিটি ধাপে কে কোয়েরি পায় তা লিখে রাখুন।

দুটি বিন্যাস সেটিংস পাতায় একই রকম দেখায়

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

পার্থক্যটি দার্শনিক নয়, মাপা যায়। ক্লায়েন্টে TLS সেশন খুঁজুন, নয়তো সার্ভারে খুঁজুন, আর আপনি জেনে যাবেন আপনার কাছে আসলে কোন বিন্যাস আছে।

পরিবর্তনের আগে রিজলভার শৃঙ্খলটি ম্যাপ করুন

পথের রিজলভারগুলো গণনা করুন এবং প্রতিটির ভূমিকা নাম দিন। একটি ফরওয়ার্ডিং উপাদান অনুরোধ অন্য রিজলভারের কাছে হস্তান্তর করে, আর একটি রিকার্সিভ রিজলভার উত্তর খোঁজার কাজটি করে এবং সরাসরি কর্তৃত্বশীল সার্ভারের সঙ্গে কথা বলতে পারে। এই ভূমিকাগুলো ঠিক এই কারণেই আলাদাভাবে সংজ্ঞায়িত, এবং RFC 9076-এর রিজলভার সংজ্ঞা একটিমাত্র আপস্ট্রিম গন্তব্য আছে ধরে নেওয়ার আগে পড়ার মতো। যে হোস্ট নিজের রিকার্সিভ রিজলভার চালায় তার এনক্রিপ্ট করার মতো কোনো একক "আপস্ট্রিম" নেই, আর তাতে গোটা পরিকল্পনা অর্থহীন হয়ে যায়।

তারপর জিজ্ঞাসা করুন ক্লায়েন্টকে কোন উপাদান ব্যবহারের জন্য কনফিগার করা হয়েছে। VPN প্রোফাইল যে DNS ঠিকানা পাঠায় তা বলে কোয়েরিগুলো কোথায় যায়, কোন প্রক্রিয়া উত্তর দেয় তা নয়।

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

কোন হপ এনক্রিপ্টেড তা যাচাই করুন

ক্লায়েন্ট থেকে শুরু করুন এবং দেখুন তার 853 পোর্টে TLS সেশন আছে কি না। 53 পোর্ট দিয়ে সঠিকভাবে রিজলভ হওয়া কোয়েরি এনক্রিপশন সম্পর্কে কিছুই প্রমাণ করে না।

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

তারপর VPN হোস্টে যান এবং ফরওয়ার্ডার যে বহির্গামী এনক্রিপ্টেড সংযোগ খুলেছে তা খুঁজুন। সকেট টেবিল বলে দেয় আপস্ট্রিমে TLS সেশন আছে কি নেই, আর কোন প্রক্রিয়া সেটির মালিক:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

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

মালিক ও ব্যর্থতার আচরণ লিখে রাখুন

মালিকানা ঠিক করে দেয় আপনি কী প্রতিশ্রুতি দিতে পারেন। ডিভাইসের মালিক ক্লায়েন্ট-সাইড এনক্রিপ্টেড সংযোগ নিয়ন্ত্রণ করেন, আর VPN প্রশাসক তার ফরওয়ার্ডার যে পরবর্তী সংযোগ তৈরি করে তা নিয়ন্ত্রণ করেন। যিনি কোনোটিই পরিচালনা করেন না, তিনি কেবল পথটি বর্ণনা করতে পারেন।

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

শেষ করুন প্রতি হপে একটি বাক্য লিখে: কোন উপাদান কোয়েরিটি পেয়েছে, সেই হপ এনক্রিপ্টেড ছিল কি না, আর কে নামটি পড়তে পারে। VPN হোস্টের বাক্যটি যদি এখনও বলে যে সে কোয়েরি পড়তে পারে, তাহলে ডকুমেন্টেশন তা-ই বলা উচিত, কারণ বিপরীত দাবি করা কোনো ডায়াগ্রামকে সেই ব্যক্তি বিশ্বাস করবেন যিনি কখনো কমান্ডগুলো চালাননি।