OpenVPN-এর ঠেলে দেওয়া DNS উপেক্ষিত: কোন উপাদান তা প্রয়োগ করে

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

ঠেলে দেওয়া অপশন একটি প্রস্তাব, ইনস্টলেশন নয়

সার্ভারে দুটি নির্দেশনা প্রভাব নয়, উদ্দেশ্য বর্ণনা করে:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

ক্লায়েন্ট কনফিগার করা কোনো রেজলভার পায় না। সে পায় এনভায়রনমেন্ট ভেরিয়েবল, foreign_option_1 এবং তার পরেরগুলো, প্রতিটি ঠেলে দেওয়া লাইনের জন্য একটি, আর স্থানীয় কিছুকে সেগুলো পড়ে অপারেটিং সিস্টেমের রেজলভার অবস্থা পুনর্লিখন করতে হয়। Linux-এ ডিফল্টভাবে কিছুই তা করে না, তাই সঠিক সার্ভার ও সংযুক্ত ক্লায়েন্টও LAN দিয়ে রিজলভ করতে পারে।

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

পুশ পৌঁছেছে কি না নিশ্চিত করুন এবং মালিক খুঁজুন

শুরু করুন লঞ্চারটির নাম বলে: একটি খালি openvpn কমান্ড, একটি systemd ইনস্ট্যান্স, NetworkManager, বা কোনো ভেন্ডর ক্লায়েন্ট। এটাই ঠিক করে হুক কোথায় থাকতে পারে। systemd-resolved হোস্টে resolvectl status প্রতিটি লিংককে তার প্রকৃত ব্যবহৃত DNS সার্ভার ও সার্চ ডোমেইনসহ তালিকাভুক্ত করে, আর টানেল লিংকের নাম সবসময় tun0।

যদি ঠেলে দেওয়া ঠিকানাটি লগে দেখা যায় কিন্তু কোনো লিংকে না থাকে, তাহলে ইন্টিগ্রেশনটাই নেই। যদি তা লিংকে থাকে আর কোয়েরিগুলো তবু অন্যত্র যায়, সমস্যা হলো কোন কোয়েরিগুলো সেই লিংক বেছে নেয়। NetworkManager dns=dnsmasq ফাইলে /etc/NetworkManager/NetworkManager.conf একটি স্থানীয় ফরওয়ার্ডার চালায় যা উদ্দেশ্যমূলকভাবে স্প্লিট DNS প্রয়োগ করে: VPN ডোমেইনের ভেতরের নামগুলো VPN রেজলভারে যায়, বাকি সব আগের পথেই থাকে। এই আচরণ ত্রুটির মতো দেখায় যখন আপনি ভেবেছিলেন সব ট্রাফিক সরে যাবে; ডিভাইস যা রিপোর্ট করে তার পেছনের মানগুলো দেখতে সংযোগভিত্তিক সেটিংস পরীক্ষা করুন nmcli connection show "My VPN" এর মাধ্যমে, যেখানে ipv4.dns এবং ipv4.dns-search মানগুলো ধরে রাখে, একে ভাঙা বলার আগে। যদি প্রতিটি কোয়েরি সত্যিই VPN রেজলভারে পৌঁছানো উচিত, তাহলে সরিয়ে দিন dns=dnsmasq থেকে NetworkManager.conf এবং NetworkManager পুনরায় চালু করুন, যা রিজলিউশন সংযোগ সেটিংসে ফিরিয়ে দেয়; নাহলে স্প্লিট DNS রাখুন আর ঠেলে দেওয়া ডোমেইন তালিকাটি ঠিক করুন।

Linux: অপশনগুলো রেজলভারকে দিন

ডিস্ট্রিবিউশন প্যাকেজ এজন্য একটি হুক দেয়, আর ক্লায়েন্টকে তা চালানোর অনুমতি দিতে হয়। systemd-resolved ছাড়া হোস্টে সাধারণ বিন্যাস:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved-এর সঙ্গে পুরোনো resolv.conf স্ক্রিপ্ট হয়তো গুরুত্বপূর্ণ কিছুই বদলাবে না, কারণ stub রেজলভার প্রতিটি লিংকের অবস্থা ধরে রাখে। update-systemd-resolved হেল্পারটি এমন একটি হুক ফর্ম নথিভুক্ত করে যা ব্যবহার করে up-restart এবং down-pre, যা গুরুত্বপূর্ণ যখন কোনো ইন্টারফেস একক সংযোগ প্রচেষ্টার চেয়ে বেশি টিকে থাকে। যা-ই বেছে নিন, একটি উপাদানকে অবস্থার মালিক হতে হবে। NetworkManager-এর পাশে অসম্পর্কিত হুক যোগ করলে একই লিংকে দুই লেখক হয়, আর ফলাফল তখন আপনার কনফিগারেশনের বদলে ক্রমের ওপর নির্ভর করে।

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

Windows ও macOS ভিন্ন অংশ প্রয়োগ করে

Windows ক্লায়েন্ট সত্যিই VPN অ্যাডাপ্টারের DNS সার্ভার সেট করে, কিন্তু Windows তবু মেট্রিক দিয়ে ইন্টারফেস বেছে নেয় এবং সংক্ষিপ্ত নাম প্রসারিত করতে এখনো সাফিক্স দরকার। প্রোফাইল নয়, অ্যাডাপ্টারের অবস্থা নিশ্চিত করুন:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

ঠিকানাটি না থাকলে এটি দিয়ে সেট করুন Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, তারপর অ্যাডাপ্টারের IPv4 বৈশিষ্ট্যে সাফিক্স যোগ করুন যাতে fileserver হয়ে যায় fileserver.corp.example। মেশিন-ব্যাপী SearchList মানটি Tcpip\Parameters এর অধীনে একই কাজ করে। যেখানে লম্বা নাম রিজলভ হয় কিন্তু খালি নাম হয় না, সেখানে রেজলভার ইতিমধ্যে সঠিক এবং দোষ সার্চ তালিকার। সমাধানগুলো ক্রমানুসারে: ঠেলে দিন একটি DOMAIN যাতে ক্লায়েন্ট সাফিক্স শেখে, সেই সাফিক্স অ্যাডাপ্টার বা সংযোগের সার্চ তালিকায় যোগ করুন, এবং সাময়িক ব্যবস্থা হিসেবে নামটি পিন করুন hosts এ, বা LMHOSTS Windows-এ; NetBIOS ব্রাউজিং রাউটার পার হয় না, তাই অফিস LAN-এ সংক্ষিপ্ত নাম খুঁজে পাওয়া ব্রডকাস্ট কখনো টানেল ক্লায়েন্টে পৌঁছায় না।

block-outside-dns block-outside-dns হলো Windows ক্লায়েন্টের আচরণ, পোর্টেবল প্রোফাইল লাইন নয়, এবং এটি Linux বা macOS প্রোফাইলে কপি করলে সেখানে তা পুনরুৎপাদিত হয় না। Windows-এ পাবলিক নাম কাজ করলে আর অভ্যন্তরীণ নাম ব্যর্থ হলে, Advanced settings-এর অধীনে অ্যাডাপ্টার ক্রম তুলনা করুন ipconfig /all এর সঙ্গে। macOS-এ পরিষেবাভিত্তিক রেজলভার ক্রম সিস্টেমের, তাই ব্যবহার করুন scutil --dns কোন ডোমেইনের জন্য কোন রেজলভার জিজ্ঞাসিত হয় তা দেখতে, এবং রিপোর্ট করা যেকোনো একক প্রোফাইল সমাধানকে সাধারণ নয়, ক্লায়েন্ট-নির্ভর হিসেবে ধরুন।

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

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

কোয়েরি কোথায় গেছে তা প্রমাণ করুন

একটি লুকআপ চলাকালীন ক্যাপচার বিতর্ক মেটায়: tcpdump -ni eth0 port 53 ভৌত ইন্টারফেসে কোয়েরি দেখায়, অর্থাৎ সেগুলো টানেলের বাইরে যাচ্ছে এবং রেজলভার কখনো বদলায়নি। dig @10.8.0.1 name.corp.example তারপর বাকি দুটি ক্ষেত্র আলাদা করে। সরাসরি কোয়েরি উত্তর দিলে রেজলভার কাজ করছে আর ক্লায়েন্ট তা ব্যবহার করছে না; টাইমআউট হলে টানেল দিয়ে রেজলভার নাগালের বাইরে এবং কোনো স্থানীয় পরিবর্তন কাজে আসবে না।

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

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

একজন মালিক রাখুন এবং ক্রমানুসারে যাচাই করুন

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

চারটি পরীক্ষায় চক্রটি বন্ধ করুন: ঠেলে দেওয়া ঠিকানা টানেল লিংকে উপস্থিত, অভ্যন্তরীণ নামটি পূর্ণযোগ্য নাম হিসেবে রিজলভ হচ্ছে, একই নাম সাফিক্স ছাড়া রিজলভ হচ্ছে, এবং একবার পুনঃসংযোগের পরও দুটোই সত্য। একটি ক্যাপচারই বলে দেয় চারটির কোনটি ব্যর্থ হয়েছে। OpenVPN 2.6 ম্যানুয়াল তালিকাভুক্ত করে dhcp-option এবং স্ক্রিপ্ট নির্দেশনাগুলো তাদের প্ল্যাটফর্ম নোটসহ।