Cloud VPN-এর BGP ঠিকানাগুলো NIC-তে নয়, টানেলের ভেতরে থাকে
HA VPN-এর জন্য Cloud Router BGP জোড়া IPsec পথের ভেতরে বসে। VM ইন্টারফেসে link-local ঠিকানা যোগ না করে স্ট্যাকের নিচে এটি অনুসরণ করুন।
VPN-এর Cloud Router পৃষ্ঠা খুলুন, আর 169.254.0.0/16-এর মধ্যে ঠিকানাসম্পন্ন একটি BGP সেশন আপনার দিকে তাকিয়ে আছে। স্বাভাবিক প্রতিক্রিয়া হলো সেই ঠিকানাটি VM-এর কোথাও বসিয়ে সেশনটি ওঠার অপেক্ষা করা। এই প্রতিক্রিয়া একটি নির্দিষ্ট উপায়ে ভুল: জোড়াটি IPsec টানেল যে যৌক্তিক লিংক তৈরি করে তার অন্তর্গত, মেশিনের সাধারণ নেটওয়ার্ক ইন্টারফেসের নয়। NIC-তে যা-ই যোগ করুন না কেন, তা টানেলকে BGP বহন করতে বাধ্য করে না।
জোড়াটি হোস্টে যোগ না করে স্ট্যাকের নিচের দিকে অনুসরণ করুন।
কনসোল যেখানে জোড়াটি দেখায় সেখান থেকে শুরু করুন
সেশন পৃষ্ঠায় একটি Cloud Router BGP ঠিকানা ও একটি পিয়ার ঠিকানা তালিকাভুক্ত থাকে, IPv4 HA VPN-এর ক্ষেত্রে দুটিই link-local। পাশে আছে টানেল শেষ করা বাইরের গেটওয়ে ঠিকানা। এগুলো আলাদা বস্তু: link-local জোড়া ভেতরে থাকে, আর গেটওয়ে ঠিকানা বাইরে থাকে এবং অন্য কিছু কাজ করার আগে সেগুলো রুটযোগ্য হতে হবে।
কনফিগারেশন ফাইল খোলার আগে তিনটিই লিখে রাখুন, কারণ এগুলো গুলিয়ে ফেলাই সম্পূর্ণ ব্যর্থতার ধরন।
যে টানেল এটি বহন করে তার কাছে নিচে নামুন
দুই গেটওয়ের মধ্যে IPsec নিরাপত্তা সংযুক্তি তৈরি হওয়ার পরেই link-local জোড়ার অর্থ হয়। Google-এর দিকে HA VPN টানেল দুটি ইন্টারফেসে তা তৈরি করে; আপনার দিকে তা হলো পিয়ার যা নিয়ে আলোচনা করেছে। প্রথমে swanctl --list-sas দিয়ে ডেটা সংযুক্তি পরীক্ষা করুন এবং কোন টানেল কোন ইন্টারফেসে ওপরে আছে তা লিখে রাখুন, কারণ মৃত টানেলের ওপর সুস্থ BGP সেশন অসম্ভব, আর আশাবাদী কনফিগারেশনসহ মৃত টানেল সাধারণ ব্যাপার।
BGP প্যাকেট হলো ভেতরের IP ট্রাফিক। বাইরের নেটওয়ার্ক তা কখনোই দেখে না, তাই কোনো সুইচের এক VLAN-তে দুটি ঠিকানাই থাকার দরকার নেই।
এখন Linux পিয়ার মিলিয়ে কনফিগার করুন
সমর্থিত টানেল নকশা বেছে নিন এবং সেটিকেই ভেতরের ঠিকানা নির্ধারণ করতে দিন। রুট-ভিত্তিক ইন্টারফেসে রাউটিং এন্ট্রি ও আলোচিত ট্রাফিক সিলেক্টরকে একমত হতে হবে, কারণ শুধু ইন্টারফেসের নাম কিছুই অনুমোদন করে না। BIRD-কে ভেতরের লোকাল ঠিকানা ও Cloud Router-এর ভেতরের ঠিকানায় নির্দেশ করুন, সেশন পৃষ্ঠা থেকে AS নম্বরগুলো সেট করুন, এবং সুরক্ষিত পথের ভেতরে TCP 179 অনুমোদন করুন। দূরের বাইরের ঠিকানার রুটটি ফিজিক্যাল আপলিংকে রাখুন যাতে টানেল নিজের পরিবহন নিজেই ধরে না ফেলে।
যে টানেল নিজেকেই রুট করে তা হ্যান্ডশেকসহ একটি লুপ, এবং এক ঘণ্টা ধরে তা ফায়ারওয়াল সমস্যার মতো দেখাবে।
প্রতিটি ধাপ ক্রমানুসারে পরীক্ষা করুন, সব একসঙ্গে নয়
ধাপগুলো হাঁটুন: নিরাপত্তা সংযুক্তি ওপরে, টানেল ঠিকানা থেকে ভেতরের পিয়ার পৌঁছানো যায়, BGP সেশন প্রতিষ্ঠিত, প্রিফিক্স গৃহীত, তারপর ওয়ার্কলোড প্রিফিক্স সত্যিই ব্যবহৃত। birdc show protocols তৃতীয় প্রশ্নের উত্তর দেয় আর কিছুই না, তাই মানুষ তাড়াতাড়ি জয় ঘোষণা করে।
প্রতিষ্ঠিত প্রতিবেশী এই নিশ্চয়তা দেয় না যে দুই পক্ষই আপনার প্রয়োজনীয় প্রিফিক্স বিজ্ঞাপিত করেছে, বা সেই রুটগুলো পছন্দের হিসেবে ইনস্টল হয়েছে।
সেশন প্রতিষ্ঠিত থাকলেও যদি ট্রাফিক ভুল পথে যায়, বিজ্ঞাপিত প্রিফিক্সগুলোকে রাউটিং টেবিল তাদের সঙ্গে কী করে তার সঙ্গে তুলনা করুন. অন্যত্র আরও নির্দিষ্ট রুট, বা অন্য পথের প্রতি অগ্রাধিকার আপনাকে একটি কাজ করা BGP সেশন দেয় এবং কোনো কাজের ফরওয়ার্ডিং দেয় না।
এটি Router Appliance-এ প্রয়োগ করার আগে থামুন
Network Connectivity Center Router Appliance একটি ভিন্ন সংযুক্তি মডেল। এর Cloud Router পিয়ারগুলো HA VPN link-local জোড়ার বদলে VPC ও সাবনেট বিন্যাস থেকে অভ্যন্তরীণ ঠিকানা ব্যবহার করে। যদি আসল লক্ষ্য রাউটিং VM-সহ BGP হয়, তবে link-local সেশন কপি না করে সেই পণ্যের ইন্টারফেস প্রয়োজনীয়তা অনুসরণ করুন।
link-local পরিসর এখনও যা বলে তাই বোঝায়। যৌক্তিক টানেল এই সংলগ্নতা দেয়, এবং এটি VPC জুড়ে ইচ্ছেমতো link-local গন্তব্য রুট করার অনুমতি দেয় না।