Mac-এ Azure VPN Client: DNS সার্ভার প্রোফাইলে রাখুন

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

আপনি কোন ক্লায়েন্ট কনফিগার করছেন তা নিশ্চিত করুন

এটি Microsoft-এর Azure VPN Client, যা পয়েন্ট-টু-সাইট অ্যাক্সেসের জন্য OpenVPN ব্যবহার করে। এর XML macOS-এর নেটিভ IKEv2 প্রোফাইল নয়, এবং এটি প্রতিটি তৃতীয় পক্ষের OpenVPN ক্লায়েন্টের কনফিগারেশন ফাইলও নয়।

যদি Macটি বিল্ট-ইন সিস্টেম ডায়ালগ দিয়ে সংযোগ করে, তাহলে আপনি ভুল নথিতে আছেন।

DNS থাকে প্রোফাইল XML-এর ভিতরে

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

ঐচ্ছিক সেটিংস নির্দেশিকা DNS এন্ট্রিগুলো clientconfig এলিমেন্টের ভিতরে রাখে। একটি ন্যূনতম অংশ এমন দেখায়, আপনার প্রতিষ্ঠান সত্যিই যে ঠিকানা চালায় তা দিয়ে।

<clientconfig>
    <dnsservers>
        <dnsserver>10.20.2.4</dnsserver>
    </dnsservers>
</clientconfig>

এই ঠিকানাটি উদাহরণমাত্র, Azure-প্রদত্ত রিজলভার নয়। দ্বিতীয় clientconfig এলিমেন্ট পেস্ট করার বদলে এন্ট্রিগুলো বিদ্যমান কনফিগারেশনে সংযুক্ত করুন, কারণ Microsoft জানায় macOS-এ ডুপ্লিকেট এলিমেন্ট সমর্থিত নয়। জেনারেট করা প্রোফাইলে যেখানে আসল কনফিগারেশন থাকার কথা সেখানে nil প্লেসহোল্ডারও থাকতে পারে, আর nil এলিমেন্টের পাশে সেটিংস যোগ করা কোনো মেরামত নয়।

ইমপোর্টই হলো পরিবর্তন

ফাইল সেভ করা নিজে থেকে কিছুই বদলায় না। Azure VPN Client খুলুন, Import নির্বাচন করুন, সংশোধিত XML নির্বাচন করুন, প্রয়োজনীয় ঘরগুলো পূরণ করুন এবং সংযোগটি সেভ করুন।

তারপর সেই ইমপোর্ট করা সংযোগ দিয়ে আবার সংযোগ দিন। ডিস্কে প্রোফাইল থাকা অবস্থায় পুরোনো সংযোগ সক্রিয় থাকাই হলো সঠিক সম্পাদনা কিছুই করছে না বলে মনে হওয়ার সবচেয়ে সাধারণ কারণ।

সাফিক্স সীমাবদ্ধতাই আপনার প্রথম পরীক্ষা ঠিক করে

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

প্রথমে একটি সম্পূর্ণ যোগ্যতাসম্পন্ন প্রাইভেট হোস্টনাম দিয়ে পরীক্ষা করুন। যদি FQDN রিজলভ হয় আর ছোট নাম না হয়, আপনি নির্দিষ্ট কিছু শিখেছেন: রিজলভার পৌঁছানোর মতো এবং ছোট-নাম সম্প্রসারণ অনুপস্থিত। এটি অপ্রাপ্য DNS সার্ভার থেকে আলাদা ত্রুটি, এবং এর জন্য আলাদা মালিক দরকার।

রিজলভারের এখনো একটি পথ দরকার

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

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

তিনটি আলাদা ফলাফল হস্তান্তর করুন

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

প্রতি ফলাফলে এক লাইনই যথেষ্ট, আর এটি পরের ব্যক্তিকে ইতিমধ্যে সঠিক ছিল এমন প্রোফাইল আবার সম্পাদনা করা থেকে বিরত রাখে।