RRAS DHCP: নতুন ঠিকানা নাকি শুধু কনফিগারেশন অপশন?

ক্যাপচারে DHCPACK দেখে ধরে নেওয়া যে VPN ক্লায়েন্ট তার ঠিকানা DHCP থেকে পেয়েছে, তা ভুল। সাধারণত এটি শুধু প্রমাণ করে যে কোনো একটি DHCP বার্তার উত্তর দেওয়া হয়েছে। Windows RRAS নিজের স্ট্যাটিক পুল থেকে সেশনের ঠিকানা দিতে পারে, আর DHCP তখনও সংযুক্ত ক্লায়েন্টকে অপশন সরবরাহ করে। রিকোয়েস্টের ধরনই বলে দেয় দুটি কাজের মধ্যে কোনটি চলছিল।

একই বার্তা-ধরন ভাগ করা দুটি কাজ

DHCP দুটি আলাদা কাজ করে, আর তারা বার্তা-ধরন ভাগ করে। একটি হলো ঠিকানা ও লিজ বরাদ্দ করা। অন্যটি হলো এমন হোস্টে কনফিগারেশন পৌঁছে দেওয়া যার আগেই ঠিকানা আছে, যাকে RFC 2131 বলে DHCPINFORM। দ্বিতীয় ক্ষেত্রে উত্তরটি অপশন বহন করে এবং কোনো লিজ সময় বহন করে না।

তাই ACK হলো উত্তরের প্রমাণ, বরাদ্দের প্রমাণ নয়। তার আগের বার্তাই ঠিক করে কোন প্রশ্নটি করা হয়েছিল। আগে রিকোয়েস্ট লাইনটি পড়ুন, বাকি ট্রেস সাধারণত নিজেই নিজেকে ব্যাখ্যা করে।

RRAS ঠিকানাটি কোথা থেকে পায়

RRAS কনফিগার করা IPv4 অ্যাসাইনমেন্ট পদ্ধতির মাধ্যমে VPN ঠিকানার সিদ্ধান্তের মালিক: হয় একটি DHCP সার্ভার, নয় একটি স্ট্যাটিক ঠিকানা পুল। পুল স্ট্যাটিক হলে পুলই বরাদ্দকারী, আর আলাদা DHCP সার্ভারের একটি রিজার্ভেশনের সেই সেশনে কোনো ভূমিকা নেই। দুটি ব্যবস্থা একই নেটওয়ার্কে সহাবস্থান করতে পারে, একটিও অন্যটিকে নিয়ন্ত্রণ না করে।

Get-Command -Module RemoteAccess *IPAddress*

ঠিকানা নিয়ে সমস্যা খোঁজার আগে চালু অ্যাসাইনমেন্ট পদ্ধতিটি জেনে নিন. যদি এটি স্ট্যাটিক পুল হয়, তবে DHCP স্কোপ ভুল জায়গা। উপরের কমান্ডটি আপনার সংস্করণে উপলব্ধ কমান্ডলেটগুলো তালিকাভুক্ত করে, আর সেটিংটি খুঁজে পেতে এটাই যথেষ্ট।

ইউজার ক্লাস কী প্রমাণ করতে পারে আর কী পারে না

DHCP ইউজার ক্লাস হলো ক্লায়েন্টের পাঠানো একটি স্ট্রিং, প্রমাণিত গ্রুপ সদস্যপদ নয়। ক্লায়েন্ট একটি পাঠালে এবং সার্ভার তার ভিত্তিতে পলিসি মিলালেও, লেবেলটি শুধু প্রমাণ করে স্ট্রিংটি পৌঁছেছে। RFC 3004 স্পষ্ট বলে যে অপশনটি ক্লাসের অধিকার যাচাই করে না।

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

ACK নয়, প্রমাণের তুলনা করুন

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

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

ঠিকানাটি যদি RRAS পুল থেকে আসে, তবে DHCP রিজার্ভেশন কিছুই ব্যাখ্যা করে না। অপশন এলে কিন্তু ক্লায়েন্ট তা উপেক্ষা করলে, সার্ভার তার কাজ করেছে এবং পরের গন্তব্য ক্লায়েন্ট কনফিগারেশন। এই দুটি ফলাফল স্পষ্টভাবে তুলনা করুন, ACK আর দ্ব্যর্থক থাকবে না। দুটি ট্রেস, প্রতিটি অ্যাসাইনমেন্ট পদ্ধতি থেকে একটি, যেকোনো ডকুমেন্টেশনের চেয়ে দ্রুত বিতর্ক মিটিয়ে দেয়।