দুটি অন-প্রিম VPN ঠিকানা: দুটি Azure পিয়ার, একটি নয়

ডায়াগ্রামে শাখায় দুটি ইন্টারনেট লিঙ্ক এবং Azure-এ একটি VPN গেটওয়ে আছে, তাই লোকাল নেটওয়ার্ক গেটওয়ে দুটি পাবলিক ঠিকানাই পায়। এটি দেখতে গোছানো, এবং ডায়াগ্রামটি যা বোঝায় সেভাবে কাজ করে না। প্রতিটি অন-প্রিম VPN ডিভাইস আলাদা পিয়ার সম্পর্ক, এবং Microsoft-এর বহু-ডিভাইস ডিজাইন প্রত্যেকটিকে নিজস্ব লোকাল নেটওয়ার্ক গেটওয়ে রিসোর্স ও নিজস্ব সংযোগ দেয়। একক রিসোর্সে দ্বিতীয় ঠিকানা যোগ করলে দ্বিতীয় পিয়ার তৈরি হয় না। এটি এমন রিসোর্স তৈরি করে যা কোনও ডিভাইসকেই ঠিকভাবে বর্ণনা করে না।

মিথ: একটি গেটওয়ে, দুটি ঠিকানা

লোকাল নেটওয়ার্ক গেটওয়ে হলো দূরবর্তী পিয়ারের বর্ণনা: একটি পাবলিক এন্ডপয়েন্ট এবং তার পেছনের প্রাইভেট প্রিফিক্সগুলি। সেই রিসোর্সকে «এই দুটি যন্ত্রের যেকোনোটি» অর্থে পরিণত করার কোনো সমর্থিত উপায় নেই।

একই বিভ্রান্তি উল্টো দিকেও চলে, যেখানে Azure-এর দুটি পাবলিক IP-কে দুটি Azure গেটওয়ের প্রমাণ হিসেবে পড়া হয়।

বস্তু গণনা করুন, তারপর টানেল গণনা করুন

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

হিসাবটি ডিজাইন ডকুমেন্টে পেস্ট করার মতো যথেষ্ট ছোট:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

একটি সংযোগ রিসোর্স একাধিক অন্তর্নিহিত টানেল বহন করতে পারে, তাই চারটি টানেল মানে চারটি ভার্চুয়াল নেটওয়ার্ক গেটওয়ে নয়। Azure-এর দুটি পাবলিক IP-ও দূরবর্তী সাইট বর্ণনাকারী দুটি লোকাল নেটওয়ার্ক গেটওয়ের মতো একই বস্তু নয়।

Azure-এর দিকে সক্রিয়-সক্রিয় কী যোগ করে

সক্রিয়-সক্রিয় Azure গেটওয়েকে একটি সক্রিয় ইনস্ট্যান্স থেকে দুটিতে বদলে দেয়, প্রত্যেকটির নিজস্ব পাবলিক IP থাকে, এবং এটিই পূর্ণ মেশকে আদৌ সম্ভব করে। এটি একক প্রবাহের থ্রুপুট দ্বিগুণ করে না। দুটি ডিভাইস একসাথে ফরোয়ার্ড করলে অন-প্রিম দিককে সমান-খরচের মাল্টিপাথ সমর্থন করার প্রয়োজনীয়তাও এটি সরায় না। কিছু প্রস্তুত করার আগে গেটওয়ে মোড, SKU ও দূরবর্তী ডিভাইসের সামর্থ্য নিশ্চিত করুন।

প্যাসিভ-স্ট্যান্ডবাই গেটওয়ে সম্পূর্ণ বৈধ ডিজাইন; এটি শুধু ভিন্ন টানেল সংখ্যা দেয়।

BGP দুই পথকেই ব্যবহারযোগ্য করে

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

ফিরতি রাউটিং এবং যে-কোনো স্টেটফুল ইন্সপেকশনের পরিকল্পনা করুন যা দুই পথের যেকোনোটি সহ্য করতে হবে। প্রতিটি এন্ডপয়েন্টে সুস্থ IKE সেশন প্রমাণ করে না যে কোনো ওয়ার্কলোড প্রতিটি ঘোষিত রুট ব্যবহার করতে পারে।

প্রবাহ-ভিত্তিক নির্বাচন ব্যান্ডউইথ পুলিং নয়

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

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

আপনি আসলে কোন অপ্রয়োজনীয়তা সরিয়েছেন

একটি যন্ত্রে দুটি WAN ঠিকানা অ্যাক্সেস-লিঙ্কের বিকল্প বাড়ায়, তবে সেই যন্ত্রের পাওয়ার, সফটওয়্যার ও ব্যর্থতার অবস্থা ভাগ করে। এগুলি দুটি ডিভাইসের সমান নয়, এবং Azure-এর দিকের কোনো কনফিগারেশনই তা বদলায় না। ঠিকানার সংখ্যা থেকে অপ্রয়োজনীয়তা অনুমান না করে বিক্রেতার সমর্থিত ডুয়াল-WAN বা ক্লাস্টার ডিজাইন অনুসরণ করুন। তারপর পরীক্ষা করুন: একবারে একটি পথ সরান এবং অবশিষ্ট রুট ও দুই দিকেই বাস্তব অ্যাপ্লিকেশন বিনিময় নিশ্চিত করুন।

সনাক্তকরণ ও কনভার্জেন্স বিলম্ব আশা করুন, এবং কিছু বিদ্যমান সেশন শেষ হওয়ার আশা করুন।