RRAS-এর VPN ক্লায়েন্টদের নিজেদের IPv4 পুল এবং ফিরে আসার পথ দরকার
RRAS-এ আলাদা স্ট্যাটিক পুল পরিবর্তনের অর্ধেক মাত্র। সঠিক cmdlet বেছে নিন, তারপর LAN হোস্টগুলিকে নতুন ক্লায়েন্ট রেঞ্জে ফেরার রুট দিন।
VPN ক্লায়েন্ট সংযোগ করে এবং একটি ঠিকানা পায়, অথচ তার প্রয়োজনীয় LAN হোস্টটি এখনও তাকে উত্তর দিতে পারে না। Windows Routing and Remote Access-এ VPN ক্লায়েন্টদের অভ্যন্তরীণ ঠিকানা আসে সার্ভারের LAN অ্যাডাপ্টার থেকে আলাদাভাবে কনফিগার করা একটি পুল থেকে, আর LAN দিকের সেই পুলে ফেরার রুট দরকার। দুটি পরিবর্তন, একটি নয়, এবং সেগুলি আলাদা আলাদা ভাবে ব্যর্থ হয়। পুরনো রেঞ্জ বাদ দেওয়ার আগে ঠিকানা পরিকল্পনা ও ফেরার পথ প্রমাণিত হওয়ার জন্য ক্রম অনুসারে এগুলি করুন।
কনসোল খোলার আগে রেঞ্জ সংরক্ষণ করুন
এমন প্রিফিক্স বাছুন যা LAN, অন্য VPN রেঞ্জ বা সাইটে রাউট হওয়া কোনও কিছুর সঙ্গে ওভারল্যাপ না করে। পরীক্ষার জন্য /24 সুবিধাজনক আকার, এবং প্রথম ব্যবহারযোগ্য অংশটি ক্লায়েন্টদের দেওয়া যায়, বাকিটা প্রবৃদ্ধির জন্য মুক্ত থাকে। কনসোলে টাইপ করার আগে এর উদ্দেশ্য ও মালিকসহ লিখে রাখুন। ব্লকের দুই প্রান্তে জায়গা রাখুন, যাতে পরে বিভাজন করলে পুনঃসংখ্যায়ন বাধ্যতামূলক না হয়।
শুধু কনসোলে বাস করা ঠিকানা পরিকল্পনা একটি পুনর্নির্মাণ দূরত্বে সংঘর্ষের মুখে থাকে। এটি বাড়ার প্রবণতাও দেখায়: কেউ পরে দ্বিতীয় রেঞ্জ যোগ করে এবং কেউ প্রথমটি যাচাই করে না। পরিকল্পনাটি চ্যাট থ্রেডে নয়, সার্ভার ডকুমেন্টেশনের পাশে রাখুন।
সার্ভারের LAN অ্যাডাপ্টার এই পুল নির্ধারণ করে না। পাবলিক লিসেনার বদলানো বা LAN-এ অ্যাডাপ্টার যোগ করা সম্পূর্ণ ভিন্ন কিছু করে। এজন্যই ক্লায়েন্ট সংযোগ করতে পারে এবং তবুও ভুল জায়গা থেকে ঠিকানা পায়। পুলটি সার্ভারের IPv4 বৈশিষ্ট্যে থাকে, অ্যাডাপ্টার তালিকায় নয়।
পদ্ধতি বদলানো মানে রেঞ্জ যোগ করা নয়
RRAS-এ একটি অ্যাসাইনমেন্ট পদ্ধতি এবং একগুচ্ছ রেঞ্জ থাকে। DHCP থেকে স্ট্যাটিক পুলে যাওয়া একটি পদ্ধতি পরিবর্তন। স্ট্যাটিক পুল ইতিমধ্যে সক্রিয় থাকা অবস্থায় আরেকটি ব্লক যোগ করা একটি রেঞ্জ পরিবর্তন।
যেকোনো একটি চালানোর আগে দুটি অপারেশনই প্রিভিউ করুন এবং কোনটি সার্ভারের বর্তমান অবস্থার সঙ্গে মেলে তা পড়ুন:
Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf
সার্ভার এখনও DHCP অ্যাসাইনমেন্টে থাকলে দ্বিতীয় cmdlet ব্যর্থ হয় বা অকেজো পুল তৈরি করে। প্রথমটি বিদ্যমান পুল বাড়ানোর বদলে পদ্ধতিটি প্রতিস্থাপন করে। কোনও প্রিভিউ কিছু প্রয়োগ করে না, তাই যেটি মেলে সেটি চালান, তারপর কনসোলে ফলাফল পুল নিশ্চিত করুন। সার্ভার কোন অবস্থায় আছে তা নিশ্চিত না হলে IPv4 বৈশিষ্ট্য পৃষ্ঠায় অ্যাসাইনমেন্ট পদ্ধতি পড়ুন এবং কনফিগার করা রেঞ্জের তালিকা দেখুন:
Get-VpnIPAddressRange
DHCP পদ্ধতি ও খালি রেঞ্জ তালিকা মানে প্রথম প্রিভিউ প্রযোজ্য। বিদ্যমান রেঞ্জসহ স্ট্যাটিক ঠিকানা পুল মানে দ্বিতীয়টি প্রযোজ্য।
সেটিংয়ের প্রয়োজন হতে পারে এমন পরিষেবা পুনরায় চালু হওয়ার হিসাব রাখুন, এবং সংযুক্ত ক্লায়েন্টদের সঙ্গে সঙ্গে পুনঃসংখ্যায়িত হবে ধরে নেবেন না। যে ক্লায়েন্ট পুনরায় সংযোগ না করা পর্যন্ত পুরনো ঠিকানা রাখে সে স্বাভাবিক আচরণ করছে। পুনঃসংযোগ গ্রহণযোগ্য এমন একটি উইন্ডোর জন্য পরিবর্তনটির পরিকল্পনা করুন।
LAN-এর ফেরার রুট দরকার
ধরুন LAN হলো 10.60.0.0/24 এবং RRAS সার্ভার তার উপর 10.60.0.10। ওই LAN-এর যে হোস্ট 10.250.50.0/24-এর একটি ক্লায়েন্টকে উত্তর দেয়, তার RRAS সার্ভারের মধ্য দিয়ে পুলে যাওয়ার পথ দরকার। সেই পথ ছাড়া অনুরোধ পৌঁছায় এবং উত্তর মারা যায়।
হোস্টের ডিফল্ট গেটওয়ে অন্য রাউটার হলে সেই রাউটারের VPN প্রিফিক্সের ফেরার রুট দরকার। RRAS সার্ভারে স্ট্যাটিক রুট এখানে কাজে লাগে না; ফেরার পথটি সেই ডিভাইসে থাকতে হবে যার কাছে LAN গেটওয়ে আছে, তাই সাইট যে পদ্ধতি ব্যবহার করে সেই অনুযায়ী এটি রাউটিং টেবিলে বা ডাইনামিক রাউটিং প্রক্রিয়ায় যোগ করুন।
নতুন সোর্স রেঞ্জের বিপরীতে হোস্টের ফায়ারওয়াল এবং যে কোনও নেটওয়ার্ক অ্যাক্সেস নিয়মও যাচাই করুন। পুরনো ক্লায়েন্ট রেঞ্জের জন্য লেখা নিয়ম নতুনটিকে প্রত্যাখ্যান করে, যদিও অ্যাসাইনমেন্ট সফল হয়েছে। LAN-এর দিকে ক্লায়েন্ট রুট এবং DNS রিজলিউশন আলাদা প্রয়োজনীয়তা, এবং টানেল সুস্থ দেখালেও দুটোই ব্যর্থ হতে পারে। প্রতিটি আলাদাভাবে পরীক্ষা করুন।
পুরনোটি বাদ দেওয়ার আগে একটি ডিভাইসে নতুন পুল প্রমাণ করুন
আপনার নিয়ন্ত্রণে থাকা একটি অনুমোদন নিন, পুনরায় সংযোগ করুন এবং ক্লায়েন্ট যে পুল ঠিকানা পেয়েছে তা পড়ুন। ওই একটি সংখ্যাই বরাদ্দ ও রাউটিংকে আলাদা করে। তারপর একটি নামযুক্ত অ্যাপ্লিকেশন চালান, ফেরার ট্রাফিক দেখুন এবং এমন গন্তব্য চেষ্টা করুন যা প্রত্যাখ্যাতই থাকা উচিত। তিনটি পর্যবেক্ষণ, তিনটি ভিন্ন ব্যর্থতার ধরন।
নাম রিজলিউশন নিজের পরীক্ষার দাবিদার: IP দিয়ে অ্যাক্সেস কাজ করতে পারে, অথচ ক্লায়েন্টের DNS এখনও এমন একটি রিজলভার দেখায় যা সে পৌঁছাতে পারে না। LAN-এর DNS সার্ভারে পৌঁছানো যায় কেবল যদি ক্লায়েন্টের সেখানে রুট থাকে এবং সার্ভার নতুন রেঞ্জ থেকে কোয়েরি গ্রহণ করে। পুল সরে গেলে দুটোই সাধারণত বাদ পড়ে।
সক্রিয় সেশন ও রক্ষণাবেক্ষণ প্রক্রিয়ার হিসাব নেওয়ার পরেই পুরনো রেঞ্জ ও তাদের ব্যতিক্রম বাদ দিন। নতুন ঠিকানাসহ সংযুক্ত ক্লায়েন্ট বরাদ্দ প্রমাণ করে, অ্যাক্সেস নীতি নয়। যে শেষ সেশনটি পুরনো রেঞ্জ ব্যবহার করেছে তা শেষ না হওয়া পর্যন্ত সেটি নথিভুক্ত রাখুন।
তিনটি পর্যবেক্ষণে ফলাফল যাচাই করুন
গ্রহণযোগ্যতার জন্য তিনটি তথ্য দরকার: ক্লায়েন্টের কাছে নতুন পুলের ঠিকানা আছে, একটি LAN হোস্ট সেখানে পৌঁছে উত্তর পায়, এবং প্রত্যাখ্যাত গন্তব্য প্রত্যাখ্যাতই থাকে। প্রতিটির নিজস্ব যাচাই আছে, তাই ব্যর্থতা বরাদ্দ, রাউটিং বা নীতির দিকে ইঙ্গিত করে। এই ক্রমে সেগুলি চালান।
ক্লায়েন্ট থেকে ঠিকানা এবং একটি LAN হোস্টের পথ নিশ্চিত করুন:
ipconfig | findstr /i "IPv4"
route print -4
LAN হোস্ট থেকে একবারেই ফেরার পথ ও নীতি নিশ্চিত করুন। পিং ব্যর্থ হলেও অ্যাপ্লিকেশন কাজ করলে অনুপস্থিত অংশটি সম্ভবত রুট নয়, ICMP নিয়ম। দুটোই ব্যর্থ হলে VPN সম্পাদনার আগে হোস্টের রুট পড়ুন। তিনটি ফলাফল পরিবর্তন টিকিটে লিখুন, যাতে পরবর্তী ব্যক্তি প্রমাণ থেকে শুরু করেন।