resolvectl আউটপুট থেকে প্রতি-লিঙ্ক VPN DNS রাউটিং কীভাবে পড়বেন
resolvectl status প্রতি লিঙ্কে সার্ভার, ডোমেইন ও ডিফল্ট রুট দেখায়। এগুলি একসাথে পড়ুন, তারপর নামটি জিজ্ঞাসা করুন এবং কোন লিঙ্ক উত্তর দিয়েছে তা লক্ষ্য করুন।
resolvectl status চালালে প্রতি লিঙ্কের ব্লকের একটি দেয়াল পাবেন, প্রতিটির নিজস্ব সার্ভার ও নিজস্ব ডোমেইন লাইন থাকে। রাউটিং নির্ধারণ করে ডোমেইন তালিকা, নেমসার্ভার ঠিকানা নয়, কারণ স্থানীয় স্টাব প্রতিটি প্রশ্ন সেই লিঙ্কে পাঠায় যে নামটির দাবি করে। উত্তর পড়ার আগে ওই দাবিগুলি পড়ুন, তারপর নামটি জিজ্ঞাসা করুন এবং কোন লিঙ্ক তা তৈরি করেছে দেখুন। সঠিক লিঙ্ক থেকে ভুল উত্তর আর ভুল লিঙ্ক থেকে সঠিক উত্তর সম্পূর্ণ ভিন্ন সমস্যা।
প্রতিটি প্রতি-লিঙ্ক ব্লক আপনাকে কী বলে
প্রতিটি ব্লক সেই সার্ভারগুলি তালিকাবদ্ধ করে যা রিজলভার ওই ইন্টারফেসের জন্য ব্যবহার করবে, ডোমেইন তালিকা এবং লিঙ্কটি ডিফল্ট রুট কি না। ডোমেইন তালিকা একগুচ্ছ দাবি, আর রিজলভার দীর্ঘতম-প্রত্যয় মিলন প্রয়োগ করে: host.corp.example-এর প্রশ্ন corp.example বহনকারী লিঙ্ক আগে দাবি করে, কেবল ডিফল্ট রুট বহনকারী লিঙ্কের চেয়ে। একই প্রত্যয় দাবি করা দুই লিঙ্ক ফলাফলকে অগ্রাধিকার ও ক্রমের উপর ছেড়ে দেয়, তাই ডুপ্লিকেটগুলিই আগে মনোযোগ দাবি করে। বর্তমান সার্ভার লাইন দেখায় তালিকাভুক্ত কোন সার্ভারটি সেই মুহূর্তে ব্যবহৃত হচ্ছে।
/etc/resolv.conf-এ 127.0.0.53-এর মতো স্টাব ঠিকানা কেবল বলে স্টাবটি সামনে আছে। এটি কোন আপস্ট্রিম উত্তর দিয়েছে তা নামায় না, তাই কেবল resolv.conf-ভিত্তিক রোগনির্ণয় আটকে যায়।
তিন ধরনের ডোমেইন এন্ট্রি সঠিকভাবে পড়ুন
| এন্ট্রি | কী দাবি করে | সাধারণ ভুল |
|---|---|---|
| corp.example | রাউটিং ডোমেইন ও সার্চ প্রত্যয়: এর অধীনের নাম এই লিঙ্কে যায়, এবং স্ট্রিংটি খালি নামের সাথে যোগ হয় | সরিয়ে ফেলা হয়েছে কারণ রাউটিং তবুও কাজ করছে বলে মনে হয় |
| ~corp.example | শুধু রুট: এর অধীনের নাম এই লিঙ্কে যায়, কিন্তু প্রত্যয় যোগ হয় না | রাউটিংয়ের জন্য প্রয়োজনীয় ধরে নেওয়া হয়েছে |
| ~. | ডিফল্ট রুট: অন্য কোনও লিঙ্ক না মেলা প্রশ্নের দাবি করে | বিভক্ত প্রোফাইলে সক্রিয় রাখা হয়েছে, ফলে পাবলিক নামগুলি টানেল ধরে চলে |
টিল্ডা সার্চ আচরণ বদলায়, রাউটিং নয়। টিল্ডা ছাড়া এন্ট্রি একইসাথে রাউটিং ডোমেইন ও সার্চ ডোমেইন, তাই এর অধীনের নাম ওই লিঙ্কে পাঠানো হয় এবং এক-লেবেল নামের সাথে প্রত্যয় যোগ হয়। টিল্ডাযুক্ত এন্ট্রি একই প্রত্যয় রাউট করে কিন্তু তা সার্চ তালিকার বাইরে রাখে। তাই টিল্ডা সরালে কোন খালি নামগুলি রিজলভ হয় তা বদলায়, আর তাই টিল্ডা না থাকা বিভক্ত-DNS ব্যর্থতা নয়, সার্চ সমস্যা।
ডিফল্ট রুট এন্ট্রি অন্য কোনও লিঙ্ক না মেলা সবকিছুর দাবি করে। পূর্ণ-টানেল প্রোফাইল সাধারণত এটি চায় আর বিভক্ত প্রোফাইল সাধারণত চায় না, কারণ তখন পাবলিক নামগুলি ব্যক্তিগত রিজলভারে যায় এবং সেখানে ব্যর্থ হতে পারে। প্রোফাইলের অভিপ্রায়ের বিপরীতে তালিকাটি পড়ুন, প্রোফাইলের মধ্যে ফ্ল্যাগ কপি করবেন না। দুই লিঙ্ক একই প্রত্যয় দাবি করলে অন্য কিছু সম্পাদনার আগে অগ্রাধিকারের প্রশ্নটি নিষ্পত্তি করুন।
একটি নাম জিজ্ঞাসা করুন এবং দেখুন কোন লিঙ্ক উত্তর দিয়েছে
query উপকমাণ্ড ঠিকানা, প্রোটোকল এবং যে লিঙ্ক বা স্কোপ উত্তরটি তৈরি করেছে তা ছাপে। ব্যক্তিগত প্রত্যয়ের দাবি করা উচিত এমন একটি নাম এবং একটি সাধারণ পাবলিক নাম পরীক্ষা করুন, তারপর জানানো উৎসগুলি তুলনা করুন। ব্যক্তিগত নাম যদি ওয়্যারলেস লিঙ্ক থেকে উত্তর দেয়, তবে দাবিটি নেই বা টানেল বন্ধ; আর বিভক্ত প্রোফাইলে পাবলিক নাম যদি টানেল থেকে উত্তর দেয়, তবে ডিফল্ট রুট খুব প্রশস্ত। এই দুটি ব্যর্থতা ব্রাউজারে একই রকম দেখায় আর এই আউটপুটে বিপরীত।
resolvectl status
resolvectl query host.corp.example
জানানো প্রোটোকলও লক্ষ্য করুন, কারণ ক্যাশ বা হোস্ট-ফাইল থেকে আসা উত্তর কোনও আপস্ট্রিম না জিজ্ঞাসা করেই আসতে পারে। ক্যাশ থেকে উত্তর প্রমাণ করে নামটি কোনও সময়ে রিজলভ হয়েছিল, এই নয় যে বর্তমান নীতি এটি সঠিকভাবে রাউট করে।
নাম রাউটিংকে প্যাকেট রাউটিং থেকে আলাদা রাখুন
রিজলভারের সিদ্ধান্ত পথ তৈরি করে না। নির্বাচিত সার্ভারের এখনও নিজের ঠিকানায় রুট দরকার, আর ফেরত আসা ঠিকানারও ব্যক্তিগত নেটওয়ার্কে রুট দরকার, তাই সঠিক DNS নীতি এমন সংযোগের সাথে সহাবস্থান করতে পারে যা কখনও খোলে না। নাম রিজলভ হয় কিন্তু অ্যাপ্লিকেশন ব্যর্থ হলে, আবার DNS বদলানোর বদলে ঠিকানা ও রুট দেখুন। নাম রিজলভ করা আর পৌঁছানো দুটি আলাদা মালিকের দুটি প্রশ্ন।
অ্যাপ্লিকেশনগুলি নিজেদের সুরক্ষিত DNS সেটিং বা অন্তর্নির্মিত রিজলভারের মাধ্যমে সিস্টেম রিজলভারকে সম্পূর্ণ এড়িয়ে যেতে পারে। resolvectl ফলাফল সিস্টেম পথ বর্ণনা করে, আর যে ব্রাউজার তা উপেক্ষা করে সে আপনার প্রতিটি পরীক্ষার সাথে অমিল দেখাবে। নীতি ভাঙা বলে সিদ্ধান্তে আসার আগে ওই সেটিংটি যাচাই করুন।
নামটি যে ঠিকানায় রিজলভ হয়েছে তা লিঙ্কের পাশে লিখে রাখুন। ভুল ঠিকানায় নির্দেশ করা সঠিক নাম রাউটিং নয়, রেকর্ডের সমস্যা।
লিঙ্ক বদলানোর পরে আবার যাচাই করুন
পুনরায় সংযোগ বা ওয়্যারলেস বদল লিঙ্কের অবস্থা নতুন করে গড়ে, আর নেটওয়ার্ক ম্যানেজার হাতে দেওয়া সবকিছুর উপরে নিজের ডোমেইন ও সার্ভার আবার বসাতে পারে। এরপর একই দুই নাম জিজ্ঞাসা করুন এবং লিপিবদ্ধ ভিত্তিরেখার সাথে তুলনা করুন। হাতে করা সম্পাদনা মুছে গেলে, সমাধান সংযোগ প্রোফাইলে রাখতে হবে শেল কমান্ডে নয়। আগে ও পরে লিখে রাখাই এটি দৃশ্যমান করে।
প্রতিবেদনের যা দরকার কেবল সেই নাম ও সার্ভার প্রসঙ্গ শেয়ার করুন, কারণ ভিতরের প্রত্যয় টপোলজি প্রকাশ করে। systemd-resolved-এর ডোমেইন রাউটিং ডকুমেন্টেশন দীর্ঘতম-মিলন নিয়ম ও টিল্ডার আচরণ কভার করে, এবং একবার পড়লে উপরের বেশিরভাগ তালিকা-ভুল ঠেকানো যায়: systemd-resolved প্রশ্ন রাউটিং।