Windows-এ OpenConnect-এর DNS সেটিংস আসলে কে প্রয়োগ করে?
Windows তিনটি জায়গায় রিজলভার অবস্থা রাখে। অ্যাডাপ্টার DNS হাতে সম্পাদনার বা নেমস্পেস নিয়ম যোগ করার আগে সেই হেল্পারটি খুঁজুন যার কাছে সংযোগটি আছে।
টানেল তোলা আর তার DNS মান ইনস্টল করা এক কথা নয়। OpenConnect আলোচনা করে, আর Windows-এর দিকের একটি হেল্পার প্রয়োগ করে। এই দুই ধাপের ফাঁকই এই ক্লায়েন্টে বেশিরভাগ প্রাইভেট-নাম ব্যর্থতার ব্যাখ্যা দেয়, আর হেল্পারটি প্রায় কখনোই Windows VPN সেটিংস পেজ নয়।
গেটওয়ে যা দিয়েছে তা Windows যা ইনস্টল করেছে থেকে আলাদা করুন
ক্লায়েন্ট সংযোগের ডেটা একটি স্ক্রিপ্ট ইন্টারফেসে দেয়, আর Unix ও Windows সংস্করণ দুটি আলাদা প্রোগ্রাম। Windows-এ বাস্তবায়ন সাধারণত একটি JavaScript হেল্পার, যা অভ্যন্তরীণ DNS সার্ভার ও অভ্যন্তরীণ ডোমেইনের মতো ভেরিয়েবল পড়ে তারপর কোনো অ্যাডাপ্টার স্পর্শ করে। টানেলের ভিতরে কিছুই রিজলভার অবস্থা লেখে না।
এই বিভাজনটি গুরুত্বপূর্ণ, কারণ একটি মান আলোচনায় থাকতে পারে এবং কখনো অ্যাডাপ্টারে না পৌঁছাতে পারে। যে হেল্পার অনুপস্থিত, মাঝপথে ব্যর্থ হয়, বা GUI মোড়কের ভিতরে বাঁধা পুরোনো কপি, সেটি Windows-কে ঠিক যেমন ছিল তেমনই রেখে দেয়। সেশন সংযুক্ত দেখায়, প্রাইভেট নামটি এখনো স্থানীয় প্রদানকারীর মাধ্যমে সমাধান হয়, আর ক্লায়েন্ট উইন্ডোতে কিছুই পার্থক্যটি নির্দেশ করে না। হেল্পারের নিজের আউটপুট পড়াই কোন ধাপে ভেঙেছে তা জানার একমাত্র নির্ভরযোগ্য উপায়।
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
একটি GUI মোড়ক ক্লায়েন্ট ও হেল্পারের নিজস্ব কপি সরবরাহ করতে পারে, তাই ডিস্কের অন্য জায়গায় দ্বিতীয় openconnect.exe থাকা কিছুই প্রমাণ করে না। এর কনফিগারেশন বিচার করার আগে যে এক্সিকিউটেবল সেশনটি শুরু করেছিল তা খুঁজুন।
রিজলভার অবস্থা না বদলে পড়ুন
তিনটি শুধু-পড়ার কোয়েরি স্বাভাবিক বিভ্রান্তি ঢেকে দেয়, আর প্রতিটি ভিন্ন প্রশ্নের উত্তর দেয়:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effectiveঅ্যাডাপ্টার-স্তরের সার্ভারই বেশিরভাগ মানুষের কাছে VPN DNS বলতে বোঝায়। সংযোগ-নির্দিষ্ট সাফিক্স ঠিক করে সংক্ষিপ্ত নাম আদৌ প্রসারিত হবে কি না। নেমস্পেস নীতি তালিকা অ্যাডাপ্টারের ক্রম নির্বিশেষে মিলে যাওয়া নামগুলিতে প্রযোজ্য, আর সেখানে খালি ফলাফল কোনো ত্রুটি নয় যখন হেল্পার কখনো একটি তৈরির উদ্দেশ্য করেনি। সম্পাদনার আগে তিনটিই পড়া সেটাই যা এমন একটি সমাধান ঠেকায় যা কেবল উপসর্গটি অন্য জায়গায় সরিয়ে নেয়।
সম্পূর্ণ যোগ্য নাম দিয়ে শুরু করুন। যদি FQDN সমাধান হয় আর সংক্ষিপ্ত নাম না হয়, তবে ফাঁকটি সাফিক্স বা অনুসন্ধান তালিকা, সার্ভার ঠিকানা নয়।
দ্বিতীয় ধাপ হিসেবে উদ্দিষ্ট সার্ভারকে সরাসরি জিজ্ঞাসা করুন, ইতিমধ্যে ইনস্টল থাকা যেকোনো রিজলভার টুল দিয়ে। সরাসরি উত্তর প্রমাণ করে সার্ভারটি পৌঁছানোর যোগ্য এবং জোনের জন্য কর্তৃত্বসম্পন্ন। অ্যাপ্লিকেশন ডিফল্টভাবে কোন সার্ভারকে জিজ্ঞাসা করে সে সম্পর্কে এটি কিছুই প্রমাণ করে না।
সংযোগের মালিক যে উপাদান তার নাম দিন
দুটি বিন্যাস সাধারণ। টার্মিনাল থেকে শুরু করা ক্লায়েন্ট তার স্ক্রিপ্ট পাথ স্পষ্টভাবে দেয়, তাই মালিক যে কমান্ড চালানো হয়েছে তাতে দৃশ্যমান। প্যাকেজড অ্যাপ্লিকেশন আপনার জন্য ক্লায়েন্ট শুরু করে এবং হেল্পারটিকে নিজের ডিরেক্টরিতে রাখে, মানে কখন এটি বদলাবে তা ভেন্ডর ঠিক করে।
কিছু বদলানোর আগে ইনস্টলের মধ্যে হেল্পার সংস্করণ তুলনা করুন। ফাইলের নাম পরিচিত দেখায় বলে মিরর থেকে আনা হেল্পারকে উন্নীত অধিকার দিয়ে চালানো DNS-এর ফাঁককে নিরাপত্তা ঘটনায় পরিণত করে।
মালিক জানা হয়ে গেলে মেরামতের লক্ষ্য স্পষ্ট হয়: লঞ্চারে একটি সমর্থিত স্ক্রিপ্ট পাথ, একটি প্যাকেজ আপডেট, বা গেটওয়েতে সংশোধিত প্রোফাইল। এর কোনোটিরই অ্যাডাপ্টারের বৈশিষ্ট্য হাতে সম্পাদনা করা লাগে না।
মালিককে ঠিক করুন, অ্যাডাপ্টারকে নয়
হাতে সেট করা অ্যাডাপ্টার DNS প্রায়ই সংযোগ বিচ্ছেদের পরেও টিকে থাকে, তাই মনে হয় এটি কাজ করছে আর পরে পরের নেটওয়ার্কে সমস্যা করে। প্রতিটি ইন্টারফেসে জোড়া লাগানো একটি পাবলিক রিজলভার প্রাইভেট নেমস্পেস সমস্যাটি সমাধান না করে লুকিয়ে রাখে। যখন হেল্পার কখনো DNS মান পায়নি, তখন গেটওয়ে প্রোফাইলই দেখার জায়গা। যখন এটি পেয়েছে আর অ্যাডাপ্টার এখনো পুরোনো সার্ভার দেখায়, তখন হেল্পার সংযোগের সময় ব্যর্থ হয়েছে এবং ক্লায়েন্ট লগ সাধারণত টানেল সেটআপের লাইনের কাছে তা লিপিবদ্ধ করে।
সমর্থিত পথে অবস্থাটি আবার তৈরি করুন, তারপর একটি পূর্ণ চক্র যাচাই করুন: সংযোগ করুন, প্রাইভেট FQDN সমাধান করুন, সেবাটি খুলুন, সংযোগ বিচ্ছিন্ন করুন, এবং নিশ্চিত করুন অ্যাডাপ্টার তার আগের সার্ভারসহ ফিরে এসেছে।
যে অ্যাপ্লিকেশনটি আসলে ব্যর্থ হচ্ছে তা পরীক্ষা করুন
নিজস্ব এনক্রিপ্টেড-DNS সেটিংসহ একটি ব্রাউজার উপরের সবকিছু উপেক্ষা করে এবং পাবলিক রিজলভার থেকেই উত্তর দিতে থাকে। টানেল ওঠার আগের ক্যাশ করা ঋণাত্মক উত্তর ধরে রাখা একটি অ্যাপ্লিকেশনও একইভাবে আচরণ করে। রিজলভার ঠিকানা আবার বদলানোর আগে একই মেশিনে একটি সাধারণ সিস্টেম কোয়েরির সঙ্গে এটি তুলনা করুন।
সিস্টেম কোয়েরি ঠিক থাকলে আর অ্যাপ্লিকেশন ভুল হলে, বাকি ত্রুটিটি ওই অ্যাপ্লিকেশনের DNS কনফিগারেশনে থাকে, VPN পথে নয়।