VPN DNS রিপোর্ট: পুনরুৎপাদনযোগ্য করতে কী রাখবেন

«DNS ভাঙা» একটি সিদ্ধান্ত, আর সহায়তাকারী এর ভিত্তিতে কিছু করতে পারে না। রিপোর্টের উপকারী অংশ হলো ব্যর্থতার আকার: কোন নাম, কোন রেজলভারের মধ্য দিয়ে, কোন প্রতিক্রিয়া নিয়ে। তিনটি বিবরণ অভিযোগকে পুনরুৎপাদনযোগ্য কিছুতে পরিণত করে, আর ব্যক্তিগত অংশগুলোর নাম বদলানোর পরে তিনটিই নিরাপদে ভাগ করা যায়। নিচে যা আছে তা হলো কেউ সাহায্য করার আগে একটি VPN DNS রিপোর্টের যে ন্যূনতম বিষয় দরকার।

নামের শ্রেণি, রায় নয়

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

ব্যর্থতার জন্য টানেল চালু থাকা দরকার কি না, নাকি তা বিচ্ছিন্ন হওয়ার পরে ঘটে, তা বলুন। যে নাম কেবল VPN সক্রিয় থাকাকালীন ভাঙে তা প্রতি-লিঙ্ক কনফিগারেশনকে জড়িত করে, আর যা বিচ্ছিন্ন হওয়ার পরে ভাঙে তা অবশিষ্ট অবস্থাকে জড়িত করে। রিপোর্ট সাধারণত এটি বাদ দেয় এবং পরে ভাবে প্রথম পরামর্শটি কেন কাজ করে না।

রেজলভার পথ লিপিবদ্ধ করুন

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

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

স্ট্যাটাস আউটপুট প্রতি-লিঙ্ক সার্ভার এবং রাউটিং ডোমেইনের নাম দেয়, যা হলো যেখানে স্প্লিট DNS নির্ধারিত হয়। getent আহ্বান অ্যাপ্লিকেশন যে পথে যায় সেই একই পথ অনুসরণ করে, nsswitch ক্রমসহ। সরাসরি কোয়েরি দুটিই এড়িয়ে একটি সার্ভারকে আলাদাভাবে পরীক্ষা করে। তিনটির মধ্যে কোনটি ব্যর্থ আর কোনটি সফল হয়েছে তা জানান, তাহলে পাঠককে আর পথ অনুমান করতে হবে না।

নিয়ন্ত্রিত তুলনাটি উল্লেখ করুন

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

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

নেমস্পেস লুকান, সম্পর্কগুলো রাখুন

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

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