কোন লিঙ্ক উত্তর দেয়: স্প্লিট-টানেল VPN DNS-এর জন্য রাউটিং ডোমেইন
ডিফল্ট রুট আর DNS রাউটিং ডোমেইন আলাদা সেটিং। কোম্পানির সাফিক্সে টিল্ডা যোগ করুন, তারপর resolvectl-কে জিজ্ঞাসা করুন কোন লিঙ্ক আসলে উত্তর দিয়েছে।
সাধারণ ব্রাউজিং স্থানীয় লিঙ্কে রাখুন, আর কোম্পানির নাম টানেল যে DNS সার্ভার দেয় তার মাধ্যমে রিজলভ হোক। VPN-এর ডিফল্ট রুট বন্ধ করলে প্রথম অর্ধেক পাবেন, দ্বিতীয় অর্ধেক অসম্পূর্ণ থেকে যাবে। এরপর আসছে অনুপস্থিত সেটিং, যে বিরামচিহ্ন এর অর্থ বদলে দেয়, এবং একমাত্র কমান্ড যা দেখায় কোন লিঙ্ক আসলে উত্তর দিয়েছে। পুরো লেখায় NetworkManager ও systemd-resolved ধরে নেওয়া হয়েছে, কারণ এই জোড়াটাই সাধারণত বিভ্রান্তির শুরু।
ধাপ এক: রুট আর রিজলভার আলাদা করুন
ipv4.never-default একটি রাউটিং প্রশ্নের উত্তর দেয়, NetworkManager-কে এই সংযোগটি সব IPv4 ট্রাফিকের পথ হিসেবে বসানো থেকে বিরত রাখে। DNS রাউটিং ডোমেইন অন্য প্রশ্নের উত্তর দেয়: মিলে যাওয়া সাফিক্সের কোয়েরি কোন লিঙ্কের নেম সার্ভার পায়। একটির থেকে অন্যটি বোঝা যায় না, আর একটি প্রোফাইল বছরের পর বছর একটি বহন করে অন্যটি ছাড়াই থাকতে পারে। শুধু-রুট মানে টানেল কোম্পানির সাবনেট বহন করে এবং তার রিজলভার কোম্পানির নামের উত্তর দেয়, বাকি সবকিছু অপরিবর্তিত থাকে।
শুধু রুট প্রপার্টি সেট করুন তো ভেতরের নাম ব্যর্থ হয়, সাধারণত একটি টাইমআউট দিয়ে যা ভাঙা টানেলের মতো শোনায়। শুধু ডোমেইন সেট করুন তো চুপচাপ মেশিনের প্রতিটি ছোট নামে একটি সার্চ সাফিক্স যোগ করে ফেলেছেন। দুটি ভুলই টিকিটটিকে VPN সার্ভারের দিকে পাঠায়, যা খুব কমই আসল ভুলের জায়গা।
ধাপ দুই: প্রোফাইলে শুধু-রাউটিং ডোমেইন যোগ করুন
ধরুন সংযোগটির নাম corp-vpn, কোম্পানির সাফিক্স internal.example, আর টানেলের রিজলভার ইতিমধ্যে পৌঁছানোর মতো। আগে বর্তমান মানগুলো পড়ুন, কারণ নিচের কমান্ডগুলো এমন প্রপার্টি বদলায় যেগুলোতে আগেই এন্ট্রি থাকতে পারে।
nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yesনিজের সংযোগ-নাম ও সাফিক্স বসান, কারণ উপরের মানগুলো কেবল উদাহরণ। প্লাস চিহ্নটি দেখতে যতটা সহজ, তার চেয়ে বেশি গুরুত্বপূর্ণ: এটি থাকলে মানটি বিদ্যমান তালিকায় যোগ হয়, আর না থাকলে প্রপার্টিটি প্রতিস্থাপিত হয় এবং গতকাল কাজ করা প্রোফাইল থেকে অসম্পর্কিত ডোমেইন হারিয়ে যায়। টিল্ডা শৈলী নয়, আচরণ বদলায়, এবং নিচের অনুচ্ছেদে তা কী নির্বাচন করে তা বলা হয়েছে। লেখার আগে পড়াটা রাখুন, যাতে প্রতিস্থাপন-রূপ আপনাকে কখনো চমকে না দেয়।
শুরুতে থাকা টিল্ডা একটি শুধু-রাউটিং ডোমেইন চিহ্নিত করে, তাই মিলে যাওয়া কোয়েরি এই লিঙ্কের সার্ভারে যায় এবং সাফিক্সটি ছোট নামে যোগ হয় না। টিল্ডা বাদ দিলে একই স্ট্রিং একটি সার্চ সাফিক্সও হয়ে যায়, যা ভিন্ন ফলাফল এবং মানুষ খুব কমই তা চায়। উপরের দুটি সেটিংই IPv4, তাই ডুয়াল-স্ট্যাক প্রোফাইলে ipv6.never-default এবং ipv6.dns-search-এ একই রাউটিং ডোমেইন দরকার, নইলে IPv6 দিকটি ডিফল্ট রুট ব্যবহার করতে থাকে এবং সেখানে ভেতরের নাম ব্যর্থ হয়।
ধাপ তিন: resolvectl-কে জিজ্ঞাসা করুন কোন লিঙ্ক উত্তর দিয়েছে
resolvectl status চালান এবং প্রতিটি লিঙ্কের DNS সার্ভার ও ডোমেইন পড়ুন, তারপর একটি বাস্তব ভেতরের নামে resolvectl query host.internal.example চালান যেটি কুয়েরি করার অনুমতি আপনার আছে। দ্বিতীয় কমান্ডটিই একমাত্র সরাসরি প্রমাণ যে রাউটিং ডোমেইন তার কাজ করছে, কারণ এটি উত্তর দেওয়া লিঙ্কটির নাম বলে। কেবল স্ট্যাটাস তালিকা কনফিগারেশন প্রমাণ করে; কুয়েরি রিজলিউশন প্রমাণ করে।
systemd-resolved সবচেয়ে ভালো মেলা রাউটিং ডোমেইন বেছে নেয়, তাই অন্য লিঙ্কের আরও নির্দিষ্ট ডোমেইন দৌড়ে জিততে পারে। কুয়েরি যদি এমন লিঙ্ক থেকে ফেরে যা আপনি প্রত্যাশা করেননি, VPN-এর DNS সার্ভারে হাত দেওয়ার আগে ডোমেইন তালিকাগুলো পড়ুন। ~. রুট ডোমেইন সবকিছুর সাথে মেলে, আর যদি তা আগেই থাকে, আপনার নির্দিষ্ট ডোমেইন নিজের নামের জন্য তবু জেতে, অথচ লিঙ্কটি আপনার চাওয়ার চেয়ে অনেক বেশি উত্তর দেয়। উদ্দেশ্য যদি শুধু কোম্পানির নাম হয়, তবে ওই রুট এন্ট্রিটি সরান বা সংকুচিত করুন।
VPN লিঙ্ক যদি একেবারেই কোনো DNS সার্ভার না দেখায়, ক্লায়েন্ট কখনো একটিও নিবন্ধন করেনি। পেছনে সার্ভার ছাড়া রাউটিং ডোমেইন অনুপস্থিত ডোমেইনের চেয়ে ভিন্নভাবে ব্যর্থ হয়, তাই আগে নিবন্ধন ঠিক করুন।
ধাপ চার: যখন নাম রিজলভ হয় কিন্তু সার্ভিস নয়
সঠিক উত্তর কেবল প্রমাণ করে রিজলিউশন কাজ করেছে, আর অ্যাপ্লিকেশনটির এখনো যে ঠিকানাটি পেয়েছে সেখানে যাওয়ার রুট দরকার। সেই রুটটিকে আপনি এইমাত্র কনফিগার করা বিভক্ত ডিফল্টের মধ্য দিয়ে টিকে থাকতে হবে, তাই আবার DNS-কে দোষ দেওয়ার আগে তা যাচাই করুন। তারপর সার্ভিসের পোর্টে পৌঁছানো যায় কি না দেখুন, কারণ ফাইল শেয়ার বা ডিরেক্টরি সার্ভিস রিজলিউশন, রাউটিং বা প্রমাণীকরণে ব্যর্থ হয় এবং প্রতিটি ক্ষেত্রেই প্রায় একই রকম বার্তা দেয়। ফলাফল জানানোর সময় এই তিন স্তর আলাদা রাখুন, নইলে পরের মানুষ এমন DNS আবার যাচাই করে যা আগেই ঠিক ছিল।
এই প্রশ্নের সঙ্গে যে Samba পরিবর্তন ঘোরে, তা অ্যাক্সেস স্তরের বিষয়, DNS পছন্দের নয়। নাম-রিজলিউশনের ত্রুটিতে তা প্রয়োগ করাই ছোট সমস্যাকে দ্বিতীয় একটি সমস্যা বানানোর উপায়।
ধাপ পাঁচ: অনুপস্থিত ডোমেইন সারাতে রিজলভার বদলাবেন না
রিজলভার ফাইল উপরে লিখে ফেলা বা ভিন্ন রিজলভার ম্যানেজার ইনস্টল করার পরামর্শ অন্য সমস্যার সমাধান করে। ওগুলো সিস্টেম-ইন্টিগ্রেশনের পরিবর্তন, যাদের নিজস্ব ব্যর্থতার ধরন আছে, এবং কোনোটিই এমন রাউটিং ডোমেইন যোগ করে না যা কখনো কনফিগার হয়নি। মেশিনে নাম-রিজলিউশন কোন কম্পোনেন্টের, তা বদলানোর আগে নিশ্চিত করুন, কারণ systemd-resolved-সহ NetworkManager ডেস্কটপে সেই মালিকানা আগেই নির্ধারিত। তার সঙ্গে লড়াই করাই কাজ করা সেটআপকে এমন কিছুতে পরিণত করে যা কেউ পুনরুৎপাদন করতে পারে না।
কাজের ক্রম: টানেল একটি রিজলভার দেয় কি না নিশ্চিত করুন, শুধু-রাউটিং ডোমেইন যোগ করুন, প্রোফাইল নিয়ন্ত্রণের মাধ্যমে আবার সংযোগ করুন, উত্তর দেওয়া লিঙ্ক যাচাই করুন, তারপর সার্ভিসটিকে তার পোর্টে পরীক্ষা করুন। এই ক্রমটি এমন ফলাফল রেখে যায় যা দ্বিতীয় সাক্ষাৎকার ছাড়াই পরের মানুষের কাছে হস্তান্তর করা যায়।