ব্যক্তিগত DNS নাম, নাকি শুধু একটি IP? শেয়ার করার আগে সিদ্ধান্ত নিন

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

শর্ত এক: ক্লায়েন্টদের কোন রিজলভার পথ আছে?

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

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

পাবলিক রিজলভার ব্যক্তিগত জোন শিখবে না, কারণ ল্যাপটপটি একটি VPN-এ সংযুক্ত হয়েছে।

সাফিক্সটিও সমান মনোযোগ দাবি করে। সংস্থা যে ডোমেইন নিয়ন্ত্রণ করে তার একটি সাবডোমেইন ব্যবহার করুন, যাতে মালিকানা ও সার্টিফিকেট পরিকল্পনা স্পষ্ট থাকে। .local এড়িয়ে চলুন: মাল্টিকাস্ট DNS স্পেসিফিকেশন ওই সাফিক্সকে লিংক-লোকাল রিজলিউশনের সঙ্গে বাঁধে, এবং রাউটেড টানেল সেই আচরণ আপনার জন্য পুনরুৎপাদন করে না।

শর্ত দুই: সার্ভিস কোন উৎস পায়?

অ্যাডমিশন নিয়ম ঠিকানার বিপরীতে লেখা হয়, তাই কাজের প্রশ্ন হলো রাউটিং ও অনুবাদের পরে সার্ভিস কোন ঠিকানা দেখে। 10.20.30.40-এ একটি উদাহরণ সার্ভিসের জন্য অফিস ক্লায়েন্টরা 10.20.30.0/24 থেকে আসে এবং দূরবর্তী ক্লায়েন্টরা আসে আলাদা পুল থেকে, যেমন 10.99.0.0/24।

যদি একটি গেটওয়ে দূরবর্তী পুলটি অনুবাদ করে, সার্ভিস অনুবাদককে দেখে, এবং 10.99.0.0/24-এর জন্য লেখা নিয়ম মিলবে না।

এটি ক্লায়েন্টের দিক থেকে নয়, সার্ভিসের দিক থেকে পড়ুন। সার্ভিস হোস্টে একটি লিসেনার লগ বা প্যাকেট ক্যাপচার দেখায় সত্যিই কোন উৎস এসেছে; ক্লায়েন্টের নিজের ঠিকানা কেবল একটি অনুমান যে পথ ধরে কী টিকে গেছে।

শর্ত তিন: নামটি কি সার্ভিসের সঙ্গে বাঁধা, নাকি হোস্টের সঙ্গে?

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

একটি একক অভ্যন্তরীণ সার্ভিসের জন্য সরাসরি রেকর্ড সাধারণত ভালো এবং ভাবতে সহজ।

যে কোনো কিছু যা প্রতিস্থাপিত, পুনর্নির্মিত বা স্কেল করা হবে, তার জন্য স্থিতিশীল ফ্রন্ট এন্ড অতিরিক্ত কনফিগারেশনের যোগ্য। পরীক্ষাটি সহজ: আপনি যদি ব্যবহারকারীদের না বলে ব্যাকএন্ড প্রতিস্থাপন করতে পারেন, নামটি সার্ভিসের সঙ্গে যুক্ত; না পারলে এটি হোস্টের সঙ্গে যুক্ত।

দুটি সিদ্ধান্ত আলাদাভাবে পরীক্ষা করুন

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

curl -sv --max-time 5 https://files.corp.example/health

তারপর একবার একটি নিষিদ্ধ উৎস পরীক্ষা করুন, এবং ফলাফল লিখে রাখুন।

আপনার ডকুমেন্টেশনে দুটি রেকর্ড আলাদা রাখুন: নাম ও তার জোন, গৃহীত উৎস ও নিয়মের মালিক। যখন একটি বদলায়, অন্যটিকে বদলাতে হয় না।

সিদ্ধান্ত সাধারণত কোথায় ভুল হয়

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

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

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