দুটি শাখার মধ্যে ট্র্যাফিক Azure VPN গেটওয়ের মাধ্যমে রাউট করুন
একটি Azure VPN গেটওয়েতে দুটি সাইট-টু-সাইট সংযোগ শাখার ট্র্যাফিক পার করতে পারে, কিন্তু কেবল তখনই যখন দুই প্রান্ত প্রিফিক্স শিখে এবং LAN ফেরত পথ বিদ্যমান থাকে।
দুটি শাখা তাদের মধ্যে কোনো সরাসরি টানেল ছাড়াই Azure VPN গেটওয়ের মাধ্যমে ট্র্যাফিক বিনিময় করতে পারে। প্রতিটি শাখা একই গেটওয়েতে একটি সাইট-টু-সাইট সংযোগ খোলে, এবং গেটওয়ে দুটি সংযোগের মধ্যে শেখা প্রিফিক্সগুলো পাস করে। এটি কাজ করায় দ্বিতীয় টানেল নয়, বরং রুট বিনিময়: শাখা A-কে শাখা B-এর প্রিফিক্স শিখতে হবে, এবং B-কে A-এর প্রিফিক্স শিখতে হবে। নিচের চেকগুলো ক্রমানুসারে সম্পন্ন করুন এবং প্রথম ব্যর্থ হওয়া চেকেই থামুন, কারণ পরবর্তী প্রতিটি ধাপ এর উপর নির্ভর করে।
কিছু কনফিগার করার আগে পূর্বশর্ত
চারটি শর্ত ঠিক করে এই ডিজাইন আদৌ কাজ করতে পারে কি না। গেটওয়েটি রুট-ভিত্তিক হতে হবে এবং এমন SKU-তে থাকতে হবে যা BGP সমর্থন করে, উভয় সংযোগে BGP সক্রিয় থাকতে হবে, শাখাগুলোর ঠিকানা স্থান ওভারল্যাপ করা যাবে না, এবং কোনো পক্ষই তার প্রকৃত প্রিফিক্স লুকাতে NAT-এর উপর নির্ভর করতে পারবে না।
ASN-গুলো সচেতনভাবে পরিকল্পনা করুন। Azure-এর নথিভুক্ত ডিফল্ট হলো 65515, এবং প্রতিটি শাখা রাউটারের নিজস্ব প্রাইভেট ASN দরকার যা গেটওয়ে বা অন্য শাখার সঙ্গে সংঘর্ষ করে না। বিদ্যমান গেটওয়ে কনফিগারেশন না পরীক্ষা করে ডিফল্ট পুনরায় ব্যবহার করাই পরে AS পাথ প্রত্যাখ্যাত হওয়ার উপায়।
এটিও নিশ্চিত করুন যে আপনি VNet পিয়ারিং আচরণ আশা করছেন না। গেটওয়ে আপনার কনফিগার করা দুটি সংযোগের মধ্যে রুট বিনিময় করে; এটি ইচ্ছামতো পিয়ারিংকে ট্রানজিটিভ করে না। যদি তৃতীয় কোনো নেটওয়ার্ককে উভয় শাখায় পৌঁছাতে হয়, তবে তার নিজস্ব সংযোগ বা নিজস্ব রুট পথ দরকার, গেটওয়ে ট্র্যাফিক ছড়িয়ে দেবে এমন অনুমান নয়। প্রথম পরিবর্তন উইন্ডোর আগে সেই সীমা লিখে রাখুন, কারণ পরে কোনো সাইট যোগ করলে মানুষ এই ডিজাইন সিদ্ধান্তেই ফিরে আসে।
এই ক্রমে কনফিগার করুন
প্রতিটি ধাপের একটি পর্যবেক্ষণযোগ্য ফলাফল আছে, তাই তা না দেখা পর্যন্ত এগোবেন না।
- ভার্চুয়াল নেটওয়ার্ক গেটওয়েতে BGP সক্রিয় করুন এবং এর ASN ও পিয়ার ঠিকানা নোট করুন।
- প্রতিটি শাখার জন্য সেই শাখার প্রকৃত ঠিকানা স্থান, তার ASN এবং তার BGP পিয়ার ঠিকানা দিয়ে একটি লোকাল নেটওয়ার্ক গেটওয়ে তৈরি করুন।
- প্রতিটি সাইট-টু-সাইট সংযোগ তৈরি করুন এবং সংযোগটির নিজের উপরেই BGP সক্রিয় করুন।
- শাখা রাউটারকে অনুমানের ভিত্তিতে গেটওয়ের পাবলিক IKE এন্ডপয়েন্টের সঙ্গে নয়, Azure যে গেটওয়ে ঠিকানা বরাদ্দ করেছে তার সঙ্গে পিয়ার করতে কনফিগার করুন।
চতুর্থ ধাপেই বেশিরভাগ প্রচেষ্টা আটকে যায়। Azure যে BGP পিয়ার ঠিকানা রিপোর্ট করে সেটিই শাখা রাউটারকে প্রতিবেশী হিসেবে ব্যবহার করতে হবে, এবং এটি সবসময় টানেল ডায়াগ্রাম থেকে মানুষ যে ঠিকানা আশা করে তা নয়।
শাখার প্রিফিক্স নিজেই বিজ্ঞাপন দিন, যেমন A থেকে 10.10.0.0/16 এবং B থেকে 10.20.0.0/16। অনুপস্থিত নির্দিষ্ট নেটওয়ার্ক ঢাকতে ডিফল্ট রুট বা প্রশস্ত সমষ্টি বিজ্ঞাপন দেবেন না; ফাঁকটি পরে নীরব কালো গর্ত হিসেবে ফিরে আসে।
উভয় প্রান্তে রুট বিনিময় যাচাই করুন
সংযোগের অবস্থা চেক নয়। উভয় সংযোগে IPsec চালু থাকতে পারে অথচ তাদের মধ্যে কোনো প্রিফিক্স পার হয় না। গেটওয়ের BGP পিয়ার এবং শেখা রুটগুলো পড়ুন, তারপর নিশ্চিত করুন যে অন্য শাখার দিকে রুটটি ব্যবহারযোগ্য পথ হিসেবে দেখা যাচ্ছে।
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP টেবিলে থাকা একটি প্রিফিক্স এখনও স্ট্যাটিক রুট বা আরও নির্দিষ্ট প্রিফিক্সের কাছে ফরওয়ার্ডিং সিদ্ধান্ত হারাতে পারে। শুধু প্রাপ্ত রুট নয়, নির্বাচিত রুট পরীক্ষা করুন।
LAN পাশে ফেরত পথ অনুসরণ করুন
এটাই সেই অংশ যা Azure-এ সঠিক দেখায় এবং সাইটে ব্যর্থ হয়। শাখা A-এর একটি হোস্ট তার প্যাকেট A-এর VPN রাউটারে পাঠায় কেবল যদি সেই রাউটার তার ডিফল্ট গেটওয়ে হয়, অথবা হোস্ট বা তার গেটওয়ে B-এর প্রিফিক্সের জন্য একটি রুট ধারণ করে। বিপরীত দিকেও একই সত্য হতে হবে।
যদি আলাদা কোনো কোর সুইচ LAN-এর ডিফল্ট গেটওয়ে হয়, তবে তার অন্য শাখার দিকে VPN রাউটারের দিকে নির্দেশ করা রুট দরকার। তা ছাড়া অনুরোধ আসে এবং উত্তর ইন্টারনেট পথে চলে যায়, আর ব্যবহারকারী এমন সংযোগ দেখে যা খোলে এবং তারপর আটকে যায়।
এটি ঠিক করতে গেটওয়ে সাবনেটে নেটওয়ার্ক সিকিউরিটি গ্রুপের দ্বারস্থ হবেন না। সেই সাবনেটের নিজস্ব প্রয়োজন আছে এবং সেখানে NSG শাখা-পক্ষের নীতির সমর্থিত বিকল্প নয়। ফিল্টারিং শাখার ফায়ারওয়ালে এবং ওয়ার্কলোডগুলোর নিজের উপরই থাকা উচিত, যেখানে নিয়মগুলো তাদের মালিকরা পর্যালোচনা করতে পারেন। ওই নিয়মগুলো সাবনেট NSG-তে সরানো পরবর্তী বিভ্রাট ডিবাগ করবে এমন দল থেকেও সেগুলো লুকিয়ে ফেলে।
অপারেশন অনুমোদন করুন, তারপর প্রত্যাখ্যাত পরীক্ষায় তা প্রমাণ করুন
শেখা রুট অনুমতি নয়। আপনার প্রকৃত প্রয়োজনীয় উৎস, গন্তব্য ও পরিষেবা শাখার ফায়ারওয়াল ও এন্ডপয়েন্ট নীতির মাধ্যমে অনুমোদন করুন, বাকিটা প্রত্যাখ্যাত রাখুন।
শাখা A-এর একটি সাধারণ ওয়ার্কলোড থেকে শাখা B-এর প্রকৃত পরিষেবায় পরীক্ষা করুন, উত্তর নিশ্চিত করুন, তারপর এমন একটি অপারেশন চেষ্টা করুন যা নিষিদ্ধ থাকা উচিত। VPN অ্যাপ্লায়েন্স নিজে যে ট্র্যাফিক তৈরি করে তা ভিন্ন উৎস ঠিকানা ব্যবহার করতে এবং LAN রাউটিং ধাপ এড়িয়ে যেতে পারে, তাই রাউটার থেকে সফল ping দেখতে যা মনে হয় তার চেয়ে কম প্রমাণ করে।
চারটি তথ্য লিখে শেষ করুন: বিনিময় হওয়া প্রিফিক্স, ব্যবহৃত ASN, প্রতিটি পক্ষের LAN ফেরত পথ, এবং যে নীতি পরিষেবাটি অনুমোদন করে। এর একটি অনুপস্থিত থাকলে সেটআপ প্রথম পরিবর্তন পর্যন্ত কাজ করে, তারপর কেউ ব্যাখ্যা করতে পারে না কেন।