কেন পয়েন্ট-টু-সাইটের জন্য রুট-ভিত্তিক Azure VPN গেটওয়ে দরকার
পলিসি-ভিত্তিক গেটওয়ের ক্লায়েন্ট রুটের জন্য কোনো টানেল ইন্টারফেস নেই। কী কী নতুন করে তৈরি করতে হবে, কোন ক্রমে, আর প্রতিস্থাপনের পরে কোন সীমাবদ্ধতা থেকে যায়।
পলিসি-ভিত্তিক গেটওয়ে ট্রাফিক সিলেক্টর দিয়ে নির্বাচিত একটি IPsec টানেল তৈরি করে, আর ক্লায়েন্ট রুট হস্তান্তর করার জন্য এর কোনো ইন্টারফেস নেই। পয়েন্ট-টু-সাইট একটি রাউটিং বৈশিষ্ট্য: গেটওয়ে একটি ক্লায়েন্ট অ্যাড্রেস পুলের মালিক এবং ভার্চুয়াল নেটওয়ার্কে সেই ক্লায়েন্টদের জন্য রুট ইনস্টল করে। এই অমিলের কারণেই পোর্টালে এটি যোগ করার কোনো বিকল্প দেখায় না। বিদ্যমান গেটওয়েতে এমন কিছু নেই যা টগল করে ইন্টারফেসটি তৈরি করা যায়, তাই পরিবর্তনটি কনফিগারেশন সম্পাদনা নয়, প্রতিস্থাপন।
স্বতন্ত্র ধাপগুলোর চেয়ে ক্রমটাই বেশি গুরুত্বপূর্ণ। ক্রম ভুল করলে সাইট-টু-সাইট বিভ্রাট রক্ষণাবেক্ষণ উইন্ডোর বাইরেও গড়িয়ে যাবে।
পলিসি-ভিত্তিক গেটওয়ে আসলে কী করে
পলিসি-ভিত্তিক গেটওয়ে প্যাকেটগুলোকে সংযোগে কনফিগার করা ট্রাফিক সিলেক্টরগুলোর সঙ্গে মেলায় এবং মিলগুলোকে একটি টানেলে পাঠায়। ঠিকানা সহ কোনো টানেল ইন্টারফেস নেই, আর ভার্চুয়াল নেটওয়ার্কের কোথাও প্রতি-ক্লায়েন্ট রুট দেখা যায় না। রুট টেবিল কেবল গেটওয়ের দিকে নির্দেশ করা অন-প্রিমাইজেস প্রিফিক্স পায়। দুইটি নির্দিষ্ট ঠিকানা স্পেসের মধ্যে সাইট-টু-সাইট সংযোগের জন্য এই মডেলই যথেষ্ট।
রুট-ভিত্তিক গেটওয়ে উল্টোভাবে কাজ করে: এটি একটি টানেল ইন্টারফেস উপস্থাপন করে, আর রুট নির্ধারণ করে এর ভেতরে কী প্রবেশ করবে। পয়েন্ট-টু-সাইট এবং যে ডিজাইনে অংশীদারদের সেট বদলায়, তা ওই ইন্টারফেসের অস্তিত্বের ওপর নির্ভর করে।
কেন ক্লায়েন্ট পুলের ওই ইন্টারফেস দরকার
ল্যাপটপ সংযুক্ত হলে গেটওয়ে তাকে পয়েন্ট-টু-সাইট পুল থেকে একটি ঠিকানা দেয়। তখন ভার্চুয়াল নেটওয়ার্কের এমন একটি রুট দরকার যা বলে যে এই ঠিকানাটি গেটওয়ে হয়ে পৌঁছানো যায়। টানেল ইন্টারফেস ছাড়া ওই রুট জুড়ে দেওয়ার মতো কিছু থাকে না।
পুলটি আসে আপনার নির্ধারিত একটি রেঞ্জ থেকে, আর গেটওয়ে সেখান থেকেই বরাদ্দ করে। যদি ওই রেঞ্জ অন-প্রিমাইজেস নেটওয়ার্ক বা পিয়ার্ড ভার্চুয়াল নেটওয়ার্কের সঙ্গে ওভারল্যাপ করে, তাহলে সংঘাত কেবল কোনো ক্লায়েন্ট সংযুক্ত হওয়ার পরেই দেখা যায়, যা এটি আবিষ্কারের জন্য খারাপ সময়। মাইগ্রেশন শুরুর আগেই পুলটি সংরক্ষিত রাখুন।
টাইপও প্রতি-সংযোগ সেটিং নয়। একটি গেটওয়ের একটি টাইপ থাকে, আর এটি যে সংযোগ ধারণ করে তার প্রত্যেকটি সেই অনুযায়ী আচরণ করে, তাই মিশ্র ডিজাইনের জন্য দ্বিতীয় সংযোগ নয়, দ্বিতীয় গেটওয়ে দরকার।
টাইপ তৈরি করার সময়েই নির্ধারিত হয়
Microsoft জানায়, ডিপ্লয় করার পরে একটি ভার্চুয়াল নেটওয়ার্ক গেটওয়ে পলিসি-ভিত্তিক ও রুট-ভিত্তিকের মধ্যে পরিবর্তন করা যায় না। রূপান্তরের কোনো কমান্ড নেই, পোর্টালে কোনো টগল নেই। একই সাবনেটে দ্বিতীয় গেটওয়ে তৈরি করাও কোনো বিকল্প উপায় নয়, কারণ Azure প্রতি ভার্চুয়াল নেটওয়ার্কে একটি গেটওয়ে অনুমোদন করে। তাই মাইগ্রেশন মানে সরানো, নতুন করে গড়া, আবার সংযোগ করা।
এতে SKU-র সিদ্ধান্তও একই নির্মাণে যুক্ত হয়ে যায়। পরে বড় SKU-তে যাওয়া আরেকটি বিভ্রাটসহ আরেকটি গেটওয়ে প্রতিস্থাপন।
একটি গেটওয়ে, একটি GatewaySubnet
গেটওয়ে GatewaySubnet নামের একটি সাবনেটে থাকে, আর কেবল একটি গেটওয়ে সেটি দখল করে। ওই সাবনেটের আকার নির্ধারণ প্রস্তুতির অংশ, কারণ বড় SKU-তে বেশি ঠিকানা লাগে আর সাবনেট পরে ছোট করা যায় না। কিছু স্পর্শ করার আগে বর্তমান সাইট-টু-সাইট সেটিংস, শেয়ার্ড কী, লোকাল নেটওয়ার্ক গেটওয়ে এবং কার্যকর রুট লিপিবদ্ধ করুন। এরপর উইন্ডোটিকে বিভ্রাট হিসেবে ধরুন, কারণ নতুন সংযোগ কনফিগার না হওয়া পর্যন্ত সাইট-টু-সাইট টানেল বন্ধ থাকবে।
বিভ্রাট সীমিত রাখে এমন পুনর্নির্মাণের ক্রম: রুট-ভিত্তিক গেটওয়ে তৈরি করুন, একই লোকাল নেটওয়ার্ক গেটওয়ের সঙ্গে সাইট-টু-সাইট সংযোগ আবার তৈরি করুন, টানেল ও একটি হোস্ট-টু-হোস্ট অনুরোধ নিশ্চিত করুন, তারপরেই পয়েন্ট-টু-সাইট যোগ করুন এবং নতুন ক্লায়েন্ট প্যাকেজ তৈরি করুন।
প্রতিস্থাপন যা ঠিক করে না
দ্বিতীয় সীমাবদ্ধতা Azure-এর নয়, সহকর্মী প্রান্তের। পলিসি-ভিত্তিক অন-প্রিমাইজেস ডিভাইস কেবল যে ভার্চুয়াল নেটওয়ার্কে সংযুক্ত হয় সেটিতেই পৌঁছাতে পারে, আর একই গেটওয়ে দিয়ে অন্য অন-প্রিমাইজেস নেটওয়ার্ক বা অন্য ভার্চুয়াল নেটওয়ার্কে ট্রানজিট করতে পারে না। Azure-এর দিক প্রতিস্থাপন করলে সহকর্মী প্রান্ত কী নির্বাচন করতে পারবে তা বদলায় না।
প্রয়োজনটি সত্যিই সাইটগুলোর মধ্যে ট্রানজিট হলে উত্তর হলো রুট-ভিত্তিক সহকর্মী ডিভাইস বা এমন টপোলজি যেখানে প্রতিটি গন্তব্য আলাদাভাবে শেষ হয়। তারিখ দেওয়ার আগেই এটি ঠিক করুন, কারণ কেবল গেটওয়ে প্রতিস্থাপন তা দেবে না।
কার্যক্রম ও যাচাইয়ের ক্রম
প্রতিটি সক্ষমতা আলাদাভাবে যাচাই করুন। প্রথমে সাইট-টু-সাইট টানেলের অবস্থা ও একটি হোস্ট-টু-হোস্ট অনুরোধ, তারপর পয়েন্ট-টু-সাইট সংযোগ ও একটি প্রাইভেট রিসোর্স, তারপর ডিজাইন যে ট্রানজিট পথের দাবি করে তা। সবুজ গেটওয়ে অবস্থা কেবল প্রমাণ করে সিকিউরিটি অ্যাসোসিয়েশন উঠেছে, এর বেশি কিছু নয়। যাচাইগুলো এই ক্রমেই রাখুন যাতে ব্যর্থতা যে পর্যায়ে এসেছে সেদিকেই ইঙ্গিত করে।
যেকোনো টপোলজি পরিবর্তনের পরে ক্লায়েন্ট প্যাকেজ আবার তৈরি করুন, আর পুলটিকে প্রতিটি অন-প্রিমাইজেস ও পিয়ার্ড রেঞ্জ থেকে মুক্ত রাখুন। সীমাবদ্ধতা ও SKU-র পার্থক্যগুলো Azure VPN Gateway সেটিংস রেফারেন্সে সংকলিত আছে।