VPN ক্লায়েন্টের জন্য ডোমেইন কন্ট্রোলার পিন করার তুলনায় AD সাইট ম্যাপিং
VPN ক্লায়েন্টকে উপযুক্ত কন্ট্রোলারের দিকে নেওয়ার দুটি উপায়: পুলটিকে AD সাবনেট হিসেবে ম্যাপ করা, বা প্রতি অ্যাপ্লিকেশনের জন্য একটি পিন করা। দুটিই ভিন্ন ভিন্ন জায়গায় ব্যর্থ হয়।
VPN পুলের রিমোট-অ্যাক্সেস ক্লায়েন্টরা শেষ পর্যন্ত পৃথিবীর অন্য প্রান্তের একটি ডোমেইন কন্ট্রোলারের সঙ্গে কথা বলতে পারে, এবং এটি ঠিক করার দুটি উপায় আছে: পুলটিকে সঠিক কন্ট্রোলার থাকা সাইটের সঙ্গে যুক্ত Active Directory সাবনেট হিসেবে বর্ণনা করা, অথবা ক্লায়েন্ট বা অ্যাপ্লিকেশনটিকে একটি নির্দিষ্ট কন্ট্রোলারে পিন করা। প্রথমটি একটি টপোলজি বিবৃতি যা DC Locator কাজে লাগাতে পারে। দ্বিতীয়টি প্রতি-অ্যাপ্লিকেশন ওভাররাইড যা টপোলজিকে সম্পূর্ণ উপেক্ষা করে। দুটির খরচ আলাদা, আর আজ দ্রুততরটি বেছে নেওয়াই একটি ডিরেক্টরি দলকে শেষ পর্যন্ত দুটিই রক্ষণাবেক্ষণ করতে বাধ্য করে।
প্রতিটি পদ্ধতি আসলে কী বদলায়
সাবনেট অবজেক্ট হলো ডিরেক্টরির একটি রেকর্ড যা বলে কোন অ্যাড্রেস পরিসর কোন সাইটের অন্তর্গত। Active Directory মডিউল ও একটি বিদ্যমান সাইট থাকলে কাজটি আগে থেকে দেখার মতো যথেষ্ট ছোট:
New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site
-WhatIf ডিরেক্টরি লেখা আগে থেকে দেখায়। এটি অবজেক্ট তৈরি করে না এবং সেই পরিসরের কোনো ক্লায়েন্ট কিছুতে পৌঁছাতে পারে কি না তা পরীক্ষা করে না, আর মানুষ ঠিক এই অংশটাই আশা করে। DC Locator সাইট মডেল পড়ে যখন এটি সার্ভিস রেকর্ড সমাধান করে, তাই সঠিক সাবনেট অবজেক্ট ক্লায়েন্টকে কী দেওয়া হবে তা বদলে দেয়।
পিনিং ভিন্ন স্তরে কাজ করে। অ্যাপ্লিকেশন কনফিগে নির্দিষ্ট কন্ট্রোলার নাম, ভেতরে হোস্ট থাকা LDAP স্ট্রিং, বা পছন্দের সার্ভারের নাম দেওয়া রেজিস্ট্রি মান—সবই পথ থেকে ডিসকভারি সরিয়ে দেয়। অ্যাপ্লিকেশনটি সেই কন্ট্রোলারের সঙ্গে কথা বলে যতক্ষণ না কেউ সেটিং বদলায়, আর ফেলওভার হলো অ্যাপ্লিকেশনটি যা বাস্তবায়ন করে তাই।
সাবনেট ম্যাপিং কোথায় জেতে
পুল ম্যাপ করলে DC Locator ব্যবহার করা প্রতিটি ক্লায়েন্টের জন্য নেটওয়ার্ক অবস্থান একবারই বর্ণনা করা হয়। পুল যখন একটি /24 থেকে তিনটিতে বাড়ে, মডেলটি অ্যাপ্লিকেশন ইনভেন্টরিতে নয়, দুই বা তিনটি অবজেক্টে বদলায়। এটাই পুরো সুবিধা, আর ক্লায়েন্ট সংখ্যা আপনার নিয়ন্ত্রণে না থাকলে এটি বড়।
অসুবিধা হলো অবজেক্টটিকে কন্ট্রোলার আসলে যে অ্যাড্রেস দেখে তার সঙ্গে মিলতে হবে। VPN গেটওয়ে যদি প্রতিটি ক্লায়েন্টকে হাব অ্যাড্রেসে রূপান্তর করে, তবে অনুবাদ না হওয়া পুল যোগ করলে এমন নেটওয়ার্ক অবস্থান বর্ণনা করা হয় যা কোনো কন্ট্রোলার কখনো দেখে না। ডিজাইন ক্লায়েন্টের সোর্স অ্যাড্রেস রাখে কি না তা আগেই ঠিক করুন, আর না রাখলে VPN সার্ভারে কনফিগার করা পুলের বদলে রূপান্তরিত পরিসরটি ম্যাপ করুন।
দ্বিতীয় সীমা: সাইট মডেল একটি পছন্দ ও টপোলজি বিবৃতি। এটি কন্ট্রোলারকে পৌঁছানোযোগ্য করে না, ব্যবহারকারীকে কিছু দেয় না। পৌঁছানোযোগ্যতা দেয় রুট ও ফায়ারওয়াল নীতি; অনুমোদন দেয় অ্যাকাউন্ট নীতি।
পিনিং কোথায় জেতে
ডিসকভারি কাজ করতে না পারলে পিনিং সঠিক উত্তর: একটি পুরনো অ্যাপ্লিকেশন যা এমন নামে কন্ট্রোলার সমাধান করে যা আপনি বদলাতে পারেন না, এমন ফিল্টার যা ঠিক একটি কন্ট্রোলার অ্যাড্রেস অনুমোদন করে, বা নির্দিষ্ট সার্ভার সেট যেখানে কন্ট্রোলার অ্যাপ্লিকেশন ডিজাইনের অংশ। সেই ক্ষেত্রে পিনটি শর্টকাট নয়, একটি বাস্তব সীমাবদ্ধতার নথিভুক্তি।
এর খরচ ম্যাপিংয়ের বিপরীত। পিন করা নাম পুল অনুসরণ করে না, অ্যাপ্লিকেশন না জানলে ফেলওভার করে না, এবং ইনভেন্টরি ঝাড়াই ছাড়া কন্ট্রোলারের নাম বদল বা চালু থেকে সরানো সহ্য করে না। এটি টপোলজি সমস্যাও লুকায়, কারণ পিন করা প্রতিটি ক্লায়েন্ট সুস্থ দেখায়, অথচ সাইট মডেল নীরবে ক্ষয়ে যায়।
ডোমেইনের সাধারণ অ্যাড্রেস রেকর্ড একটি পছন্দের সার্ভার দিয়ে বদলানো তৃতীয় বিকল্প নয়। এটি সাধারণ ডিসকভারি সেট আশা করা প্রতিটি গ্রাহককে ভাঙে, আর ডিরেক্টরি-সচেতন ক্লায়েন্ট কীভাবে সাইট বাছে তা এখনো নিয়ন্ত্রণ করে না।
তিনটি শর্তে বেছে নিন
এই ক্রমে জিজ্ঞাসা করুন, সিদ্ধান্ত সাধারণত নিজেই হয়ে যায়। প্রথমে, অ্যাপ্লিকেশনটি কি আদৌ DC Locator ব্যবহার করে, নাকি ইতিমধ্যে কন্ট্রোলার অ্যাড্রেস বহন করে? দ্বিতীয়ত, কন্ট্রোলার কি পুল অ্যাড্রেস দেখে, নাকি রূপান্তরিত একটি? তৃতীয়ত, পিন কত জায়গায় হালনাগাদ করতে হতো তার তুলনায় পুল কত ঘন ঘন বদলায়?
ডিরেক্টরি-সচেতন অ্যাপ্লিকেশন যোগ সোর্স-সংরক্ষক রাউটিং যোগ বদলানো পুল: সাবনেট ম্যাপ করুন। যে অ্যাপ্লিকেশন ডিসকভারি করতে পারে না, বা যে ফিল্টার একটি অ্যাড্রেস অনুমোদন করে: পিন করুন, এবং কেন লিখে রাখুন। বাকি সব টপোলজি ঠিক করার বিষয়, আরেকটি ওভাররাইড যোগ করার নয়।
VPN ক্লায়েন্ট থেকে যাচাই করুন এবং চুক্তিগুলো আলাদা রাখুন
সাইটে ইতিমধ্যে থাকা LAN ওয়ার্কস্টেশন থেকে নয়, প্রকৃত রিমোট পথ থেকে পরীক্ষা করুন। কেবল ক্লায়েন্টের নিজের দৃষ্টিভঙ্গিই গুরুত্বপূর্ণ:
nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%
রিপোর্ট করা সাইটটি আপনি যেটি ম্যাপ করেছেন সেটিই হলে অবজেক্টটি মিলছে। ক্লায়েন্ট কোনো সাইট রিপোর্ট না করলে সে যে অ্যাড্রেস উপস্থাপন করে তা কোনো সাবনেট অবজেক্টের ভেতরে পড়ে না, যার অর্থ সাধারণত রূপান্তর বা পুরনো প্রিফিক্স। এরপর ম্যাপিং ব্যর্থ হয়েছে ধরে নেওয়ার আগে যাচাই করুন বাছাই করা কন্ট্রোলারটিই আপনার ইচ্ছার ছিল কি না, কারণ ক্লায়েন্টরা ডিসকভারির ফলাফল ক্যাশ করে এবং ফেলওভার বৈধভাবে অন্য কন্ট্রোলার বাছতে পারে।
তিনটি চুক্তি একটি নথিতে রাখুন: পুল ও তার সাবনেট অবজেক্ট, VPN পথ থেকে পৌঁছানোযোগ্য কন্ট্রোলার, এবং সাইন-ইন করা ব্যবহারকারী কী করতে পারে তা নির্ধারণকারী নীতি। সাইট ফায়ারওয়াল নিয়ম নয় এবং সংযম সীমানা নয়, আর পরবর্তী পুল পরিবর্তন দূরবর্তী ব্যবহারকারীদের ডিরেক্টরির নেটওয়ার্ক মডেল থেকে নীরবে বিচ্ছিন্ন করবে যদি ম্যাপিং, রুট ও নথিভুক্ত বিকল্প একসঙ্গে না চলে।