Windows VPN DNS লিক: কেন মেট্রিক রুটের চেয়ে গুরুত্বপূর্ণ

একটি কোয়েরি মেশিন ছেড়ে হোম রাউটারে পৌঁছায়, অথচ প্রতিটি প্যাকেট টানেলের ভেতর দিয়ে যাচ্ছে। স্বাভাবিক সিদ্ধান্ত হলো রুট নেই, অথচ রুট সাধারণত ঠিকই থাকে। Windows ইন্টারফেস মেট্রিক দিয়ে ঠিক করে কোন ইন্টারফেসের রিজলভারকে জিজ্ঞাসা করবে, আর টানেল অ্যাডাপ্টার ওই তুলনায় প্রায়ই ওয়্যারলেসের কাছে হেরে যায়।

একটি লিকের দুই ব্যাখ্যা

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

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

মেট্রিক ও রিজলভার একসাথে মেলান

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

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

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

কোনো রিজলভারই কনফিগার না করা টানেল অ্যাডাপ্টার সমানভাবে সাধারণ একটি রূপ। ক্লায়েন্ট DNS না পাঠিয়েই ইন্টারফেস চালু করে, তাই ক্রমের প্রশ্নটাই ওঠে না।

টানেলকে উপরে রাখুন ও আবার যাচাই করুন

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

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

তারপর একটি অভ্যন্তরীণ ও একটি পাবলিক নাম জিজ্ঞাসা করুন এবং কোন সার্ভার উত্তর দিল দেখুন। Microsoft-এর স্বয়ংক্রিয় মেট্রিক সম্পর্কিত রেফারেন্স ব্যাখ্যা করে কেন সবচেয়ে কম মান অগ্রাধিকার পায় এবং স্বয়ংক্রিয় বণ্টন কীভাবে নির্ধারিত হয়।

পুনঃসংযোগের পরেও টিকিয়ে রাখুন

প্রতিটি সংযোগে নতুন করে তৈরি হয় এমন অ্যাডাপ্টারে হাতে দেওয়া মেট্রিক হারিয়ে যাওয়া সেটিং। ক্লায়েন্ট ইন্টারফেস নতুন করে বানালে ওই ওভাররাইডের জন্য সংযোগ-পরবর্তী স্ক্রিপ্ট, পলিসি বা এমন ক্লায়েন্ট কনফিগ দরকার যা সংযোগকালে DNS-এর মালিক থাকে।

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