Azure GatewaySubnet সেটআপ: গেটওয়ের আগেই জায়গা সংরক্ষণ করুন

পোর্টালে ভার্চুয়াল নেটওয়ার্ক খুলে সাবনেট ব্লেডে হাত দেওয়ার আগে অ্যাড্রেস স্পেসটি দেখুন। ওই /24 যদি ইতিমধ্যেই ওয়ার্কলোড সাবনেটে ভাগ করা হয়ে থাকে এবং কিছুই খালি না থাকে, তাহলে /27 সংরক্ষণের জায়গা নেই, আর শেষে আপনাকে হয় নতুন করে ভাগ করতে হবে, নয়তো VNet বাড়াতে হবে—যা ভিন্ন পর্যালোচনাসহ ভিন্ন পরিবর্তন। আগে জায়গা ঠিক করুন, তারপর সাবনেট তৈরি করুন।

এই ক্রমটি গুরুত্বপূর্ণ, কারণ গেটওয়ে সাবনেট বিশেষ নামযুক্ত কোনো ওয়ার্কলোড সাবনেট নয়। এটি পরিচালিত গেটওয়ে ইনস্ট্যান্সের জন্য অ্যাড্রেস সংরক্ষণ, এবং সংরক্ষণ ভুল হলে Azure গেটওয়েটি গ্রহণ করবে না।

অ্যাড্রেস স্পেস দিয়ে শুরু করুন

কিছু লেখার আগেই VNet প্রিফিক্স, ওয়ার্কলোড সাবনেট এবং গেটওয়ে সংরক্ষণ এক লাইনে লিখুন। 10.60.0.0/16-এ থাকা VNet-এ জায়গা আছে; শেষে একটি রেঞ্জ বেছে নিন যাতে ওয়ার্কলোডের বৃদ্ধি সংলগ্ন থাকে।

উদাহরণস্বরূপ, 10.60.255.192/26 গেটওয়ের জন্য 64টি ঠিকানা রাখে, আর ওয়ার্কলোড 10.60.0.0/20-এ থাকে। এটি অ্যাড্রেস প্ল্যানিংয়ের উদাহরণ, আকারের প্রতিশ্রুতি নয়। Microsoft বর্তমানে নন-Basic VPN গেটওয়ের জন্য /27 বা তার বড় রেঞ্জ দাবি করে, যেখানে বড় মানে বেশি ঠিকানা: /26 দেয় 64, আর /28 দেয় 16। অ্যাড্রেস প্ল্যান যখন চলমান, তখন উপরে রাউন্ড করুন, কখনো নিচে নয়।

সঠিক নাম দিয়ে সাবনেট তৈরি করুন

পোর্টালে একটি সাবনেট যোগ করুন এবং নামটি GatewaySubnet হুবহু লিখুন—বড় হাতের G এবং বড় হাতের S, কোনো স্পেস বা প্রত্যয় ছাড়া। Azure ওই স্ট্রিং মেলায়, তাই Gateway-Subnet বা gateway এমন সাবনেট তৈরি করে যা গেটওয়ে পরিষেবা ব্যবহার করবে না।

CLI থেকে একই ধাপ, যা পর্যালোচনায় লেখা সহজ:

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

সাবনেটটি খালি রাখুন। কোনো VM নেই, কোনো প্রাইভেট এন্ডপয়েন্ট নেই, কোনো সার্ভিস ডেলিগেশন নেই। যদি সেখানে আগেই কিছু থাকে, ডিপ্লয়মেন্ট ব্যর্থ হয় এবং ত্রুটি বিরলভাবেই পথ আটকানো রিসোর্সের নাম বলে, তাই শুরু করার আগে সাবনেটের রিসোর্স তালিকা দেখুন।

পরিচালিত সাবনেট ওয়ার্কলোড নিয়মমুক্ত রাখুন

এই সাবনেটে নেটওয়ার্ক সিকিউরিটি গ্রুপ সংযুক্ত করবেন না; Microsoft এটিকে অসমর্থিত হিসেবে চিহ্নিত করে। এমন রুট টেবিল সংযুক্ত করবেন না যার ডিফল্ট রুট 0.0.0.0/0 কোথাও পাঠায়, কারণ তা গেটওয়ের কার্যক্রম ভাঙতে পারে; গেটওয়ে রুট প্রচার সক্রিয় রাখুন।

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

ফোর্সড টানেলিংয়ের নিজস্ব নথিভুক্ত নকশা আছে। গেটওয়ে সাবনেটে তাৎক্ষণিক বানানো ডিফল্ট রুট সেটা নয়।

পোর্টাল যেসব নির্ভরতা দেখায় না সেগুলো যাচাই করুন

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

কেউ যখন জিজ্ঞেস করে সাবনেট কেন VM ধরে না, তখন যে পৃষ্ঠাটি উদ্ধৃত করবেন সেটি হলো Azure গেটওয়ে সেটিংস রেফারেন্স।

গেটওয়ে যদি ইতিমধ্যেই থাকে

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

পদ্ধতিতে গেটওয়ে পুনরায় তৈরি করা লাগলে, একটি উইন্ডো ও রোলব্যাকসহ সার্ভিস মাইগ্রেশন হিসেবে পরিকল্পনা করুন। আপনি যে সংরক্ষণ বেছেছেন, আকারের কারণ এবং ইচ্ছাকৃতভাবে যে নিয়মগুলো সংযুক্ত করেননি তা লিখে রাখুন, যাতে পরের পর্যালোচক NSG যোগ করে খালি সাবনেট ঠিক করতে না যান।