Windows VPN-এ ভুল DNS সার্ভার: মেট্রিক, বাইন্ড ক্রম বা সাফিক্স
Windows-এর তিনটি প্রক্রিয়া DNS রিজলভার বেছে নেয়, আর তারা আলাদা ভাবে ব্যর্থ হয়। নেমস্পেস পরিধি, বৈশ্বিক ক্রম, বা সমাধান পুনঃসংযোগের পরেও টেকে কি না তা দিয়ে সিদ্ধান্ত নিন।
Windows ক্লায়েন্টের একটি কাজ করা টানেল থাকতে পারে, কর্পোরেট রিজলভার বহন করতে পারে, তবুও অভ্যন্তরীণ নাম বাড়ির রাউটারে পাঠাতে পারে। কোন সার্ভার উত্তর দেবে তা তিনটি আলাদা প্রক্রিয়া নির্ধারণ করে, আর সেগুলো আলাদা ভাবে ব্যর্থ হয়। তিনটিই ঠিক করতে হবে না: লক্ষণই বলে দেয় কোনটি কাজে আছে। নিচের সিদ্ধান্ত-বৃক্ষ কয়েক মিনিট নেয় এবং চিরচেনা পরিণতি আটকায়, যেখানে মেট্রিক পরিবর্তন, রেজিস্ট্রি পুনর্বিন্যাস আর NRPT নিয়ম একসাথে নামে আর কেউ জানে না কোনটি কী করল।
তিনটি প্রক্রিয়া সিদ্ধান্ত নেয়, আর সাধারণত একটি ভুল
ইন্টারফেস মেট্রিক নির্দিষ্ট ঠিকানা-পরিবারের জন্য অ্যাডাপ্টারগুলোকে সাজায়। Tcpip\Linkage এর অধীন বাইন্ডিং ক্রম হলো মেশিন-ব্যাপী ইন্টারফেস শনাক্তকারীর তালিকা, যা পুরোনো কোড পথ এখনও দেখে। নেম রিজলিউশন পলিসি টেবিল (NRPT) একটি নেমস্পেসকে নির্দিষ্ট সার্ভারের সাথে বাঁধে, আর সাফিক্স তালিকা ঠিক করে সংক্ষিপ্ত নাম আদৌ প্রসারিত হবে কি না। এগুলো স্বাধীন, তাই VPN অ্যাডাপ্টারের সঠিক রিজলভার অন্যত্রের পুরোনো পছন্দের কাছে হেরে যায়।
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
এই প্রক্রিয়াগুলোর কোনোটিই টানেলের ওপার নয়। VPN যে সার্ভার ঠেলে দেয় সেটি নামটি সমাধান করতে না পারলে, ক্লায়েন্টের দিকের প্রতিটি সেটিং কেবল সাজসজ্জা, তাই প্রথম সিদ্ধান্ত হলো রিজলভার নিজে সরাসরি জিজ্ঞাসা করা হলে উত্তর দিতে পারে কি না।
সিদ্ধান্ত এক: ঠেলে দেওয়া রিজলভার আদৌ উত্তর দিতে পারে?
সার্ভারকে স্পষ্টভাবে জিজ্ঞাসা করুন এবং সাধারণ লুকআপের সাথে তুলনা করুন। উত্তর দুটির ফাঁক নির্বাচন-সমস্যাকে পৌঁছানোর সমস্যা থেকে আলাদা করে, আর এখানে এটিই দ্রুততম শাখা:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type Aপ্রথমটি সফল হয়ে দ্বিতীয়টি ব্যর্থ হলে রিজলভার পৌঁছানোর মতো জায়গায় আছে আর Windows খারাপ বাছাই করছে; নিচের নেমস্পেস ও ক্রম-সংক্রান্ত সিদ্ধান্তে যান। প্রথমটিও ব্যর্থ হলে ক্লায়েন্টে কিছুই কাজে আসবে না: দেখুন UDP ও TCP 53 টানেল দিয়ে সার্ভারে পৌঁছায় কি না, সার্ভারের হোস্ট ফায়ারওয়াল পুলটি ফেলে দিচ্ছে কি না, আর সার্ভারের নিজের ফরওয়ার্ডারগুলো সুস্থ কি না।
এই শাখাতেই থামুন। যে রিজলভারে পৌঁছানো যায় না সেখানে NRPT নিয়ম প্রয়োগ করলে একই ব্যর্থতা আসে, কিন্তু ফিরিয়ে নেওয়ার মতো বেশি কনফিগারেশন নিয়ে, আর এটি আসল ত্রুটিকে কর্তৃত্বপূর্ণ দেখতে একটি নিয়মের আড়ালে ঢেকে দেয়।
সিদ্ধান্ত দুই: একটি নেমস্পেস, না প্রতিটি কোয়েরি?
পরিধিই যন্ত্র ঠিক করে। কেবল কর্পোরেট নাম ব্যর্থ হলে মেশিন পুনর্বিন্যাস না করে নেমস্পেস বেঁধে দিন: একটি NRPT নিয়ম ওই সাফিক্সকে টানেল রিজলভারে পাঠায় আর বাকি সব অপরিবর্তিত রাখে। প্রতিটি লুকআপ আক্রান্ত হলে সমস্যাটি বৈশ্বিক অ্যাডাপ্টার পছন্দ, আর মেট্রিকই শুরু করার জায়গা, কারণ এটি সার্ভারের কোনো সেটিং বদলায় না।
প্রতিটি ঠিকানা-পরিবারের জন্য, দুই ইন্টারফেসেই মেট্রিক সেট করুন, তারপর ক্রমটি যাচাই করুন:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6উপরের লাইন থেকে টানেল অ্যাডাপ্টারের ifIndex দিয়ে 11 প্রতিস্থাপন করুন; 11 যদি LAN অ্যাডাপ্টার হয়, একই কমান্ড ভুল পথ নামিয়ে দেয়। বরং LAN অ্যাডাপ্টার বাড়ালে অন্য দিক থেকেই একই ক্রমে পৌঁছায়: netsh int ip set interface interface="Ethernet" metric=15, আর দ্বিতীয় পরিবারের জন্য netsh int ipv6 set interface interface="Ethernet" metric=15, কারণ int ip কেবল IPv4-এ হাত দেয়।
বাইন্ডিং ক্রম প্রথম পদক্ষেপ নয়, শেষ উপায়। HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage ডিভাইস শনাক্তকারীর একটি Bind তালিকা রাখে, আর টানেল শনাক্তকারীকে সামনে আনা সত্যিই বদলায় কোন অ্যাডাপ্টার আগে জিজ্ঞাসিত হবে, কিন্তু এটি মেশিন-ব্যাপী রেজিস্ট্রি মান, প্রতিটি নেমস্পেসের জন্য আলাদা পরিধি নেই। সম্পাদনার আগে এটি এক্সপোর্ট করুন, তারপর টানেল আবার সংযোগ করুন যাতে ক্রমটি ক্লায়েন্টের প্রত্যাশিত অবস্থায় প্রযোজ্য হয়।
একটি নেমস্পেসের জন্য সংকীর্ণ যন্ত্রটিকেই বেছে নিন:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersসিদ্ধান্ত তিন: পুনরায় সংযোগের পরেও সমাধান টেকে?
যে মেট্রিক পরের ডায়াল-আপ পুনঃসংযোগ পর্যন্ত চলে সেটি কখনো সংরক্ষিত হয়নি। L2TP/IPsec ও অন্যান্য সংযোগ প্রোফাইল সংযোগ শুরু হলে আবার তৈরি হয়, তাই সংরক্ষিত মান ফোন-বুক এন্ট্রিতে IpInterfaceMetric হিসেবে থাকে, কেবল জীবন্ত ইন্টারফেসে নয়। কিছু পরিবেশ ঠিক এই কারণেই ওই ফিল্ডটি স্ক্রিপ্ট করে; অন্যরা ব্যবস্থাপনা নীতি থেকে পছন্দ ঠেলে দেয় আর প্রান্তটি একা রাখে।
ক্যাশ ও নিবন্ধন আলাদা স্তর। টানেল ওঠার পর এগুলো চালালে পুরোনো এন্ট্রি ঠিক হয় আর ক্লায়েন্ট আবার নিবন্ধিত হয়, কিন্তু কোনোটিই অ্যাডাপ্টার পুনর্বিন্যাস করে না:
ipconfig /registerdns
ipconfig /flushdnsএকই স্তরে একটি অফ সুইচ আছে। ভৌত অ্যাডাপ্টারে গতিশীল নিবন্ধন বন্ধ করলে ক্লায়েন্ট VPN-দিকের ঠিকানা ভুল নামে ঘোষণা করা থেকে বিরত থাকে, আর এটি উপরের রিফ্রেশ থেকে আলাদা মেরামত।
IPv6 সিদ্ধান্তে নিজের জন্য একটি লাইন দাবি করে। ভৌত অ্যাডাপ্টারে বৈশ্বিক IPv6 ঠিকানা থাকে আর টানেল কেবল IPv4 বহন করে, তাহলে Windows নাম সমাধানের জন্য টানেলবিহীন পথ পছন্দ করতে পারে। ওই পরিবারটি আলাদাভাবে দেখুন, কারণ IPv4-এর জন্য দেওয়া মেট্রিক তার সম্পর্কে কিছুই বলে না:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricLAN অ্যাডাপ্টারে IPv6 বন্ধ করলে ওই পথটি এবং তার সাথে প্রোটোকলটিও চলে যায়; IPv6 ইন্টারফেসে মেট্রিক বদলানো, বা কর্পোরেট নেমস্পেসের জন্য NRPT নিয়ম, পরিবারটি রেখে পছন্দ ঠিক করে। সংকীর্ণটিই বেছে নিন, যদি না আপনি ঠিক করেন যে ওই লিংকে IPv6 থাকা উচিত নয়।
উৎসের নাম নিয়ে যাচাই করুন, আর একজন মালিক রাখুন
যে যন্ত্রগুলো বলে কোন উৎসটি কার্যকর, শুধু পৃষ্ঠা লোড হয় কি না তা নয়, সেগুলো দিয়ে যাচাই করুন:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type Aতারপর ফিল্টারিংকে নির্বাচন থেকে আলাদা করুন, কারণ অ্যাপ্লিকেশনের ভেতর থেকে দুটো একই দেখায়। OpenVPN-এর block-outside-dns অন্য অ্যাডাপ্টারে পোর্ট 53 ব্লক করে; এটি রিজলভার বাছাই করে না। এখন প্রতিটি কোয়েরি ব্যর্থ হলে একটি ফিল্টার একমাত্র পৌঁছানোর মতো সার্ভারটিকেই ব্লক করতে পারে; কনফিগার করা রিজলভার উপেক্ষিত হলে ক্রম বা নেমস্পেস নিয়ম ভুল। দুটো একসাথে বদলালে ব্লক করা কোয়েরি আর উপেক্ষিত কোয়েরি আলাদা করা যায় না।
DNS নীতির জন্য একজন মালিক রাখুন: VPN প্রোফাইল, ব্যবস্থাপনা নীতি, বা NRPT নিয়ম, দুটো নয়। শেষ করার আগে:
- ঠেলে দেওয়া রিজলভার স্পষ্টভাবে নাম বলা হলে উত্তর দেয়, আর সাধারণ লুকআপ সেটিই ব্যবহার করে।
- আপনি যে নিয়ম বা মেট্রিক বদলেছেন তা সেই ঠিকানা-পরিবারকে ঢাকে যা সত্যিই কোয়েরি বহন করে।
- সেটিংটি সংযোগ বিচ্ছিন্ন ও পুনঃসংযোগের পরেও টেকে, নয়তো আপনি এটি সংরক্ষিত প্রোফাইলে সরিয়েছেন।
- ঠিক একটি প্রক্রিয়াই কর্তৃত্বপূর্ণ, বাকিগুলো আগের মতোই রাখা হয়েছে।
ক্রমটিকে শেষ করে ফেলার মতো কিছু নয়, পরিবেশগত অবস্থা হিসেবে দেখুন। পুনঃসংযোগের পরে এবং নেটওয়ার্ক স্ট্যাক স্পর্শ করে এমন Windows হালনাগাদের পরে আবার যাচাই করুন, কারণ দুটোর যেকোনোটি ভৌত অ্যাডাপ্টারকে আবার সামনে আনতে পারে।