Azure VM-এ RRAS সমর্থিত নয়: নকশার আগে যাচাই করুন

আপনি পোর্টাল খুলে Windows Server 2022 একটি সাবনেটে স্থাপন করেন, আর Remote Access ভূমিকা নির্ভুলভাবে ইনস্টল হয়। এই ক্রমটি প্রমাণ করে ইনস্টলার কাজ করে, মাইক্রোসফট এই কনফিগারেশন সমর্থন করে তা নয়। Azure ভার্চুয়াল মেশিনের জন্য প্রকাশিত সার্ভার সফটওয়্যার সমর্থন নির্দেশিকা RRAS-কে Azure VM-এ অসমর্থিত Windows Server বৈশিষ্ট্যের তালিকায় রাখে, এবং এটি সমস্যা সমাধানের খুঁটিনাটি নয়, একটি স্থাপত্য সিদ্ধান্ত। যে টানেল উঠে আসে তা স্থাপনাকে সমর্থন সীমার ভিতরে নিয়ে যায় না।

নিচের পথনির্দেশ সমর্থন পৃষ্ঠা থেকে শুরু হয়, তারপর প্রয়োজনীয়তা ও প্রতিস্থাপন বিকল্পের দিকে এগোয়।

ল্যাবে নয়, সমর্থন পৃষ্ঠা থেকেই শুরু করুন

যেকোনো আকার নির্ধারণের আগে Azure VM সমর্থন নির্দেশিকা পড়ুন। এটি Windows Server-কে একটি অবিভক্ত ব্লক হিসেবে না দেখে সমর্থিত পণ্য, ভূমিকা ও বৈশিষ্ট্য আলাদা করে। আপনার উদ্দিষ্ট কাজটি আসলে কোন সারিতে পড়ে তা খেয়াল করুন, কারণ কনসোলে সম্পর্কিত দেখানো দুটি উপাদান ভিন্ন সারিতে থাকতে পারে।

পৃষ্ঠাটি খোলা থাকতেই নকশা নথিতে উদ্ধৃতিটি লিখুন। সমর্থন অবস্থা একটি উৎসসহ তথ্য, আর যে নকশা পর্যালোচনা এটির উদ্ধৃতি দিতে পারে না, ডেমো যার কাছে আছে সে তর্কে তাকে হারিয়ে দেবে।

OS সমর্থনকে ভূমিকা ও বৈশিষ্ট্য সমর্থন থেকে আলাদা করুন

একই নির্দেশিকা Network Policy and Access Services-কে সমর্থিত ভূমিকার মধ্যে রাখে, অথচ RRAS-কে আলাদাভাবে অসমর্থিত হিসেবে রাখে। এই দুটি ভুক্তি ভিন্ন জিনিস বোঝায়, আর তাদের মিলিয়ে “রিমোট অ্যাক্সেস সমর্থিত” বানানোই ভুল পাঠের ভিত্তিতে প্রকল্প অনুমোদনের পথ। অপারেটিং সিস্টেম সমর্থিত হওয়া নিজস্ব সারি আছে এমন বৈশিষ্ট্য সম্পর্কে কিছু বলে না।

সীমাবদ্ধতাটি মাঝে মাঝে যেভাবে উদ্ধৃত হয় তার চেয়েও সংকীর্ণ। এটি Azure VM-এর ভিতরে চলা সেই বৈশিষ্ট্য সম্পর্কে; এর মানে নয় যে একটি প্রাইভেট নেটওয়ার্ক Azure-এ সংযোগ করতে পারে না, এবং এটি বলে না যে RRAS সব জায়গায় অসমর্থিত। পুরোনো ল্যাব যা প্যাকেট সঠিকভাবে ফরোয়ার্ড করে, তা প্যাকেট সম্পর্কে প্রমাণ, সমর্থন বিবৃতি সম্পর্কে নয়।

প্রকল্পের বাকি সময় এই দুই প্রশ্ন আলাদা রাখুন: এটি কাজ করে কি, এবং এটি সমর্থিত কি। প্রতিটির জন্য ভিন্ন উত্তর এবং কখনও ভিন্ন মালিক লাগবে।

নকশাকে আসলে কী করতে হবে তা লিখে রাখুন

প্রতিস্থাপন বেছে নেওয়ার আগে সাইটের তালিকাকে এমন প্রয়োজনীয়তায় বদলান যার বিপরীতে একটি পণ্য মাপা যায়:

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

NAT হলো সেই বিষয় যা এড়িয়ে যাওয়া হয়, তারপর গোটা নকশা ঠিক করে দেয়। যে ডিভাইস IPsec প্রতিষ্ঠা করতে পারে, সে এখনও যে RRAS স্থাপনাকে প্রতিস্থাপন করছে তার চেয়ে ভিন্নভাবে ঠিকানা অনুবাদ করতে পারে, আর এতে বদলে যায় শাখা কোন ঠিকানাকে উৎস হিসেবে দেখে এবং আপনার লগ কী লিখে রাখে।

তালিকাটি নেটওয়ার্ক মালিকদের কাছে নিয়ে যান এবং যেকোনো পণ্য আলোচনার আগে নিশ্চিত করুন। অস্পষ্ট প্রয়োজনীয়তা প্রতিটি বিক্রেতা তুলনাকে পছন্দের তর্কে পরিণত করে।

সেই প্রয়োজনীয়তার বিপরীতে প্রতিস্থাপনগুলি মূল্যায়ন করুন

Azure-এর পরিচালিত সংযোগ পরিষেবা এবং বিক্রেতা-সমর্থিত নেটওয়ার্ক ভার্চুয়াল অ্যাপ্লায়েন্স—দুটিকেই একই তালিকার বিপরীতে মূল্যায়ন করতে হবে। IPsec শেষ করতে পারে বলে কোনোটিকেই RRAS VM-এর সরাসরি সমতুল্য ধরে নেবেন না: NAT মডেল ও রুট মালিকানা এবং উচ্চ প্রাপ্যতার নকশাই ঠিক করে বিদ্যমান সাইটগুলি কীভাবে সংযোগ করে এবং তাদের উত্তর কোথায় ফেরে। প্রতিটি প্রার্থীকে কাগজে তালিকার বিপরীতে মূল্যায়ন করুন এবং কোন প্রয়োজনীয়তায় সে ব্যর্থ হয় তা লিখুন, কারণ সেই নোটই পরে সিদ্ধান্তটি পর্যালোচনযোগ্য করে।

দুটি অ্যাপ্লায়েন্স VM-এর সামনে একটি লোড ব্যালান্সার নিজে নিজে উচ্চ প্রাপ্যতা নয়। এটি একটি ফ্রন্ট এন্ড দেয়, সমন্বিত টানেল অবস্থা নয়, আর প্রতিটি সেশন ফেলে দেওয়া ফেইলওভার এমন একটি নকশা সিদ্ধান্ত যা কাউকে সচেতনভাবে নিতে হবে। অ্যাপ্লায়েন্স বিক্রেতাকে জিজ্ঞাসা করুন সমর্থিত HA প্যাটার্ন কী এবং তা সাইটগুলিকে প্রতিশ্রুত প্রাপ্যতার সঙ্গে মেলে কি না। সাইটগুলি এর উপর নির্ভর করার আগেই ফেইলওভার পরীক্ষা করুন, এবং প্রতিটি হারানো সেশনকে বিস্ময় নয়, একটি ফলাফল হিসেবে দেখুন।

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

যদি একটি RRAS VM ইতিমধ্যে চলছে

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

সমর্থনযোগ্যতা ও কারিগরি নির্ণয়কে সর্বত্র আলাদা ফলাফল হিসেবে রাখুন। একটি অসমর্থিত ব্যবস্থাতেও সাধারণ রাউটিং ত্রুটি থাকতে পারে, আর সেই ত্রুটি সংশোধন করলে তার সমর্থন অবস্থা বদলায় না। দুটি বিবৃতিই প্রতিবেদনে থাকা উচিত, এবং কোনোটি অন্যটিকে বাতিল করে না।

সমর্থন উদ্ধৃতি, প্রয়োজনীয়তার তালিকা, নির্বাচিত প্রতিস্থাপন এবং কাটওভার ক্রম লিখে পথনির্দেশটি শেষ করুন। নিরীক্ষক বা নতুন দলসদস্য প্রথমেই এই চারটি জিনিস চাইবেন।