OpenVPN একটি DNS সার্ভার পাঠায়, কিন্তু Linux তা উপেক্ষা করে

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

পরীক্ষা এক: সংযোগটি কীভাবে শুরু হয়

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

কমান্ড-লাইন প্রসেস স্বয়ংক্রিয়ভাবে NetworkManager সংযোগ নয়, আর NetworkManager সংযোগ স্বয়ংক্রিয়ভাবে সেই জিনিস নয় যা resolv.conf লিখেছে। এই দুটি অনুমানই এই তদন্তে নষ্ট হওয়া বেশিরভাগ সময়ের ব্যাখ্যা দেয়। আপনি যে ইন্টারফেস সত্যিই দেখছেন তার জন্য কোন উপাদান DNS প্রকাশ করবে তা জিজ্ঞাসা করুন।

এগিয়ে যাওয়ার আগে মালিকটি লিখে রাখুন। পরবর্তী প্রতিটি পরীক্ষা এর উপর নির্ভর করে।

পরীক্ষা দুই: রিজলভার লিঙ্কটি আসলে কী ধরে রাখে

একটি systemd-resolved হোস্টে resolvectl status প্রতিটি লিঙ্ক তার DNS সার্ভার ও ডোমেইনসহ তালিকাভুক্ত করে। টানেল লিঙ্কটি খুঁজে তার এন্ট্রিগুলো পড়ুন, আর ইন্টারফেসটির নাম tun0 ধরে নেবেন না, কারণ নম্বরায়ন তৈরি হওয়ার ক্রম অনুসরণ করে। লিঙ্কে পাঠানো ঠিকানাটি না থাকলে হস্তান্তর ব্যর্থ হয়েছে, কুয়েরি নয়।

ঠিকানাটি থাকলে পরের প্রশ্ন হলো সেই লিঙ্কটি কোন ডোমেইন দাবি করে। ডোমেইন তালিকা ছাড়া একটি লিঙ্ক কেবল সেই নামগুলোর উত্তর দেয় যেগুলো সরাসরি জিজ্ঞাসা করা হয়, আর split-DNS স্থাপনা খুব কমই তা চায়। শুধু ঠিকানাই প্রয়োজনীয়, কিন্তু যথেষ্ট নয়।

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

পরীক্ষা তিন: নামস্থানটি কি সেই লিঙ্ক নির্বাচন করে

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

ডোমেইন বরাদ্দ পরীক্ষা করুন, শুধু সার্ভার ঠিকানা নয়। ~corp.example হিসেবে লেখা ডোমেইন একটি রাউটিং ডোমেইন, আর টিল্ড চিহ্নটি নাম মেলানোর পদ্ধতি বদলে দেয়।

অ্যাপ্লিকেশনের নিজস্ব রিজলভার থাকলে সিস্টেম টুল নয়, সে যে পদ্ধতি ব্যবহার করে সেই পদ্ধতিতেই পরীক্ষা করুন। সিস্টেম রিজলভার এড়িয়ে যাওয়া একটি কুয়েরি টুল লিঙ্কের অবস্থা নির্বিশেষে সফল হবে।

পরীক্ষা চার: একজন মালিক, দুইজন নয়

NetworkManager যদি ইতিমধ্যে VPN ও রিজলভার অবস্থা পরিচালনা করে, তাহলে একটি অসম্পর্কিত হুক স্ক্রিপ্ট যোগ করলে প্রতিদ্বন্দ্বী লেখক তৈরি হয়। প্যাকেজের দেওয়া systemd-resolved হুকটি একটি সমর্থিত ইন্টিগ্রেশন, এবং এটি নির্দিষ্ট জীবনচক্র আশা করে: script-security 2, একটি up পথ, up-restart, একটি down পথ এবং down-pre। ওই অপশনগুলো নিবন্ধন ও অপসারণকে কেবল প্রথম সংযোগে নয়, সঠিক মুহূর্তে ঘটায়।

গাইড থেকে কপি করা একটি উদাহরণ নয়, প্যাকেজ থেকে ইনস্টল করা পথটি ব্যবহার করুন। অনুমতিও গুরুত্বপূর্ণ, কারণ হুকটি বিশেষাধিকার নামার পরে চলে।

এর আউটপুট লক্ষ্য বদলাতে কোনো ডিস্ট্রিবিউশন রিজলভার স্ক্রিপ্ট সম্পাদনা করা এক হোস্টের সমাধান লিপিবদ্ধ করে। এটি সাধারণ মেরামত নয়।

পরীক্ষা পাঁচ: পুনঃসংযোগের পরে একই ফলাফল

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

পুনঃসংযোগে পাঁচটি পরীক্ষাই পাস হলেই আপনি বলতে পারেন পাঠানো সেটিংগুলো ব্যবহৃত হচ্ছে। এর আগের সবকিছু একটি সৌভাগ্যময় মুহূর্তের স্ন্যাপশট।