OpenVPN DNS পাঠায়, কিন্তু রিজলভার হয়তো তা কখনো দেখে না

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

লক্ষণ: লগ DNS দেখায়, কিন্তু নামগুলো এখনও ব্যর্থ

OpenVPN dhcp-option DNS ও ডোমেইন তথ্য বহন করে, এবং ক্লায়েন্ট যা পেয়েছে তা লিপিবদ্ধ করে। কিছু বাস্তবায়নে ক্লায়েন্ট সেই সেটিংস অভ্যন্তরীণভাবে প্রয়োগ করে; অন্যগুলোতে এটি সেগুলো একটি ইন্টিগ্রেশন স্ক্রিপ্ট বা নেটওয়ার্কিং সার্ভিসের ব্যবহারের জন্য রপ্তানি করে। লগ লাইনটি কাহিনির কেবল প্রথম অর্ধেক বর্ণনা করে। দ্বিতীয় অর্ধেক ঘটে এমন জায়গায় যা ক্লায়েন্ট নিয়ন্ত্রণ করে না। সাধারণত ব্যর্থতা সেখানেই থাকে।

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

গ্রহণ করা মানে প্রয়োগ নয়

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

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

প্রতিটি প্ল্যাটফর্মে রিজলভারের মালিক খুঁজুন

Windows-এ নেম রিজলিউশন পলিসি টেবিল নির্দিষ্ট সাফিক্সকে নির্দিষ্ট সার্ভারে পাঠাতে পারে, এবং VPN ক্লায়েন্ট সেখানে নিয়ম ইনস্টল করতে পারে। শুধু অ্যাডাপ্টারের DNS তালিকা নয়, পলিসি যাচাই করুন। Linux-এ NetworkManager বা systemd-resolved কনফিগারেশনের মালিক হতে পারে, এবং কে মালিক তা নির্ধারণ করে পুনঃসংযোগে কী সংরক্ষিত থাকবে।

প্রকৃত অবস্থা এমন টুল দিয়ে পড়ুন যা সত্যিই কোয়েরির উত্তর দেয়: systemd-resolved হোস্টে resolvectl query internal.example.net, অথবা প্ল্যাটফর্মের সমতুল্য। তারপর সেই উত্তরটি ক্লায়েন্ট লগ যে DNS সার্ভার পাঠানোর দাবি করে তার সাথে মেলান।

সমন্বয় ছাড়া রিজলভার সেটিংস উপরে লেখে এমন একাধিক সার্ভিস চালানো এড়ান। দুই মালিক এমন ফল দেয় যা বিক্ষিপ্ত দেখায়, এবং প্রতিটি পুনঃসংযোগ এলোমেলোভাবে তা ঠিক বা ভাঙছে বলে মনে হয়।

স্ক্রিপ্ট ও foreign_option

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

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

লগ নয়, নাম পরীক্ষা করুন

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

নাম রিজলভ হলে কিন্তু সার্ভিস ব্যর্থ হলে, আবার DNS পরিবর্তনের বদলে রাউটিং ও অ্যাপ্লিকেশন অ্যাক্সেস-এ এগিয়ে যান। OpenVPN ম্যানুয়াল dhcp-option ও স্ক্রিপ্ট পরিবেশ নথিভুক্ত করে; আরেকটি রিজলভার ফাইল সম্পাদনার আগে আপনার ক্লায়েন্ট কী প্রয়োগ করবে তা নিশ্চিত করতে এটি ব্যবহার করুন।