বিভক্ত DNS ও VPN: ডোমেন নিয়ম কোনো IP রুট নয়
বিভক্ত DNS নাম অনুযায়ী একটি রিজলভার বেছে নেয়, আর উত্তরটির তখনও একটি রুট দরকার। ডোমেন নিয়ম ও পথ আলাদা করে পরীক্ষা করুন, যে প্ল্যাটফর্মে আপনি সত্যিই চালান সেখানেই।
আপনার ল্যাপটপ intranet.corp টানেলের মাধ্যমে রিজলভ করে, অন্যদিকে gitlab.com আইএসপি রিজলভারেই যেতে থাকে, এবং এটিই নকশা অনুযায়ী কাজ করা ব্যবস্থা। দুটি আলাদা সিদ্ধান্ত এটি তৈরি করেছে: নাম-মেলানোর নিয়ম রিজলভার বেছে নিয়েছে, আর একটি রুট উত্তরটি ফিরিয়ে এনেছে। যেকোনোটি ভাঙুন, ব্রাউজার এমন একটি ব্যর্থতা দেখাবে যা বাইরে থেকে একই রকম দেখায়। বিভক্ত DNS-এর অধিকাংশ প্রতিবেদন দ্বিতীয় ব্যর্থতাটি বর্ণনা করে, অথচ প্রথমটি সম্পর্কে প্রমাণ উদ্ধৃত করে।
দুই অর্ধাংশ থাকে ভিন্ন জায়গায় এবং সাধারণত ভিন্ন মানুষ সম্পাদনা করে। একটি হলো VPN প্রোফাইলে সংযুক্ত DNS নীতি, অন্যটি হলো টানেল যে রুটটি বসায় বা আটকে রাখে। কেউ যদি নির্ধারণ না করে কোন অর্ধাংশটি সত্যিই সরেছে, ডিবাগিং থেমে যায়।
একটি অনুরোধে লুকানো দুই সিদ্ধান্ত
নামের অর্ধাংশ একটি নীতি অবজেক্ট, রুট নয়। Windows-এ এটি VPN প্রোফাইলে নাম-সমাধান নীতি; Apple প্ল্যাটফর্মে DNS সেটিংস অবজেক্টে মিলে যাওয়া ডোমেনের সেট; Linux-এ রাউটিং ডোমেন, বিভক্ত রিজলভার লাইন বা নাম পরিষেবা সুইচের ক্রম। পথের অর্ধাংশ সাধারণ রাউটিং, টানেল বা হাতে বসানো, এবং হোস্টনাম কী তা এটি জানে না। যে প্রোফাইল একটি সাফিক্স গ্রহণ করে সে শুধু ঠিক করে কে উত্তর দেবে; উত্তরটিকে এটি কখনো পৌঁছানোর যোগ্য করে না।
একটি দ্রুত লক্ষণ পরীক্ষা দুটিকে আলাদা করে: নামের জায়গায় একটি ঠিকানা বসান। ঠিকানাটি কাজ করলে পথ ঠিক আছে এবং নিয়ম ভুল। ঠিকানাও ব্যর্থ হলে নিয়ম সঠিক হতে পারে এবং পথ অনুপস্থিত।
প্রতিটি প্ল্যাটফর্ম একই নাম নিয়ম কীভাবে প্রকাশ করে
উদ্দেশ্য অভিন্ন, ক্ষেত্রের নাম নয়। এক ক্লায়েন্ট থেকে অন্য ক্লায়েন্টে অনুলিপি করা উদাহরণ পরিষ্কারভাবে পার্স হয় এবং কখনো মেলে না। তিনটি আকার এমন দেখায়:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
একটি মিল বা রাউটিং ডোমেন হলো সাফিক্স পরীক্ষা, তাই intranet.corp git.intranet.corp কভার করে এবং corp.intranet কভার করে না, আর এটিকে উল্টে দেওয়া পুরো ব্যবস্থার সবচেয়ে সাধারণ ভুল। Windows ম্যাপিংটি প্রোফাইলে সংযুক্ত নাম-সমাধান নীতি হিসেবে বহন করে, ইন্টারফেসের আগে থেকেই থাকা সাফিক্স তালিকার বিপরীতে নিজস্ব অগ্রাধিকার ক্রমসহ। Apple প্ল্যাটফর্ম নেটওয়ার্ক এক্সটেনশনের DNS সেটিংস অবজেক্টে মিলে যাওয়া ডোমেন সংযুক্ত করে, এবং সিস্টেম সেগুলো প্রতিটি সীমিত রিজলভারে প্রয়োগ করে। এই রূপগুলোর কোনোটিই রুট নয়, এবং কোনোটিই অগম্য ঠিকানাকে গম্য করতে পারে না। Windows নাম-সমাধান নীতি রেফারেন্সটি সেই প্ল্যাটফর্মের ক্ষেত্রের নাম ও অগ্রাধিকার নিয়ম তালিকাভুক্ত করে, এবং সেগুলো Apple বা systemd নথিতে ব্যবহৃত নিয়ম নয়।
সঠিক উত্তরেও পথ দরকার
রিজলভারের উত্তর কেবল একটি ঠিকানা, এবং অ্যাপ্লিকেশনকে তখনও সেখানে পৌঁছাতে হয়। বিভক্ত-টানেল নকশা সাধারণত 10.20.0.0/16 পুশ করে এবং ডিফল্ট রুট আটকে রাখে, তাই অভ্যন্তরীণ নাম রিজলভ হয় এবং সংযোগটি পরে আটকে যায়। বিপরীত ঘটনাটিও সমান সাধারণ: রুট আছে, একটি পাবলিক রিজলভার ব্যক্তিগত নামে NXDOMAIN উত্তর দেয়, আর ব্যর্থতাটি রাউটিং সমস্যা হিসেবে নথিভুক্ত হয়। আগে পথ পরীক্ষা করলে আপনি এমন নামের জন্য রুটের দিকে তাকিয়ে থাকেন যা কখনোই রিজলভ হওয়ার কথা নয়।
একটি তৃতীয় গেটও আছে যা কোনো অর্ধাংশই কভার করে না। গেটওয়েতে একটি ACL, ফায়ারওয়াল নিয়ম বা ক্লায়েন্ট-সাইড নীতি উভয় সিদ্ধান্ত সঠিক হওয়ার পরেও সংযোগ ফেলে দিতে পারে। নাম রিজলভ হয়, রুট আছে, আর সংযোগ এখনও সময় শেষ করে, DNS পরীক্ষা করা বন্ধ করুন।
নির্দিষ্ট ক্রমে নাম ও পথ পরীক্ষা
একটি ক্রম বেছে নিন এবং তা ধরে রাখুন, নইলে সর্বশেষ ব্যর্থ ধাপটির পিছনে ছুটবেন। নথিভুক্ত পূর্ণ অভ্যন্তরীণ নাম রিজলভ করুন, উত্তরটি এমন ঠিকানা কিনা নিশ্চিত করুন যা রুট টেবিল বহন করতে পারে, তারপর পাবলিক নাম দিয়ে পুনরাবৃত্তি করুন যাতে প্রমাণ হয় টানেল সবকিছু ধরে নেয়নি। systemd হোস্টে কুয়েরি ও রিজলভারের রাউটিং ডোমেন এক কমান্ড দূরত্বে:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows ক্লায়েন্ট একই দুটি প্রশ্ন ভিন্ন cmdlet দিয়ে করে। দ্বিতীয়টি জানায় সিস্টেম আসলে কোন ইন্টারফেস ব্যবহার করবে:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10লুকআপ ঠিকানা ফেরালে এবং পথ পরীক্ষা ভৌত ইন্টারফেসের নাম দিলে, নাম নিয়ম কাজ করেছে আর রুট করেনি। সংক্ষিপ্ত নাম ব্যর্থ হয়ে পূর্ণ নাম রিজলভ হলে, ভুলটি রিজলভারে নয়, সাফিক্স তালিকায়।
তুলনাটি সাধারণত কোথায় ভুল হয়
প্রথম ভুল হলো অপ্রাসঙ্গিক পাবলিক রিজলভারকে ব্যক্তিগত নাম সম্পর্কে জিজ্ঞাসা করা এবং প্রত্যাখ্যানকে VPN সম্পর্কে প্রমাণ হিসেবে পড়া। দ্বিতীয়টি হলো ধরে নেওয়া যে কার্যকর পাবলিক লুকআপ টানেলের রিজলভার পথ প্রমাণ করে। তৃতীয়টি হলো বিভক্ত টানেলিং ও বিভক্ত DNS-কে এক নকশা সিদ্ধান্ত হিসেবে গণ্য করা, অথচ একটি স্থাপনা একটিতে সঠিক ও অন্যটিতে ভাঙা হতে পারে। প্রতিটি ভুল এমন পরীক্ষা থেকে আত্মবিশ্বাসী সিদ্ধান্ত দেয় যা অভিযুক্ত অংশটি কখনো চালায়নি।
নিজস্ব সুরক্ষিত DNS থাকা ব্রাউজারও সিস্টেম নিয়ম উপেক্ষা করতে পারে, তাই একটি ব্রাউজার ব্যর্থ হয়ে অন্যটি সফল হওয়া কোনো বিরোধ নয়। যে রিজলভার উত্তর দিয়েছে তার সাথে তুলনা করুন, যে ব্রাউজার অভিযোগ করেছে তার সাথে নয়।
উভয় অর্ধাংশ দৃশ্যমান হলে অবশিষ্ট প্রশ্নটি কারিগরি নয়, নীতি সংক্রান্ত: কোন নামস্পেস প্রতিষ্ঠানের, প্রতিটি উত্তরের মালিক কে, এবং কোনগুলো আদৌ মেশিন ছেড়ে যাওয়া উচিত। এটি প্রোফাইলের পাশে লিখে রাখুন, কারণ নিয়মে হাত দেওয়া পরবর্তী ব্যক্তির এটি দরকার হবে।