dnsmasq-এ আপনার VPN ডোমেইন জোন ট্রান্সফার নয়

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

ক্লায়েন্ট যা গ্রহণ করেছে তা গেটওয়ে যা প্রস্তাব করেছে তা নয়

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

এই পার্থক্যই কখনও না আসা ডোমেইনের বেশিরভাগ প্রতিবেদন ব্যাখ্যা করে। এটি প্রস্তাব করা হয়েছিল, এবং প্রয়োগ করা হয়নি।

ডোমেইন এন্ট্রির দুই ধরন

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

ব্যক্তিগত নেমস্পেসের জন্য সাধারণত শুধু-রুট রূপটিই চান। এটি কর্পোরেট সফিক্সকে কর্পোরেট resolver-এর দিকে রাখে এবং বাকি সবকিছুকে একা রাখে।

resolv.conf-এ localhost কোনো বাগ নয়

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

সেই এন্ট্রি পাবলিক resolver দিয়ে প্রতিস্থাপন করা ক্লাসিক ভুল সংশোধন। এটি পাবলিক নাম সমাধান পুনরুদ্ধার করে এবং একই সম্পাদনায় শর্তসাপেক্ষ নীতি বাতিল করে।

ব্যাকএন্ডগুলো মিশাবেন না

পরিচালিত dnsmasq ইনস্ট্যান্স এবং সিস্টেম resolver আলাদা কনফিগারেশন ও আলাদা অবস্থা দৃশ্যযুক্ত আলাদা প্রোগ্রাম। একটির জন্য অবস্থা কমান্ড অন্যটি সম্পর্কে কিছুই উপকারী বলে না।

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

নেমস্পেস পরীক্ষা করুন, শুধু উত্তর নয়

অ্যাপ্লিকেশনের স্বাভাবিক পথে একটি অনুমোদিত ব্যক্তিগত নাম এবং একটি পাবলিক নিয়ন্ত্রণ নাম জিজ্ঞাসা করুন। কর্পোরেট সার্ভারে সরাসরি ক্যোয়ারি প্রমাণ করে রেকর্ডটি বিদ্যমান; এটি প্রমাণ করে না যে ক্লায়েন্ট সেই সার্ভার বেছে নিয়েছে। দ্বিতীয় ক্যোয়ারিই নীতি পরীক্ষা করে।

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