AWS VPN-এ লোকাল ও রিমোট CIDR: কোন দিক কোনটি?

Site-to-Site VPN-এর অপশন খুললে স্থানীয় ও দূরবর্তী নামে দুটি CIDR বক্স দেখতে পান, আর আপনি স্থানীয় বলে যেই ঠিকানাটি ভাবেন—VPC—সেটার দিকেই হাত বাড়ান। API যা বোঝায় তার ঠিক উল্টোটা এটি। সংযোগের অপশনে LocalIpv4NetworkCidr গ্রাহক-গেটওয়ে দিকের নাম, আর RemoteIpv4NetworkCidr AWS দিকের নাম, কারণ সংযোগটি তৈরি হয় গ্রাহক গেটওয়ে থেকেই। কনসোল কখনো এটা স্পষ্ট করে বলে না, আর দেখতে বিশ্বাসযোগ্য কোনো অদলবদলও প্রত্যাখ্যাত হয় না।

কনসোলের লেবেল নয়, API কল থেকেই শুরু করুন

সংযোগ অপশনের রেফারেন্স একবার পুরোটা পড়ুন এবং লক্ষ করুন, প্রতিটি অপশন লেখা হয়েছে গ্রাহক গেটওয়ের দৃষ্টিকোণ থেকে। এটি নামকরণের কোনো আকস্মিকতা নয়। টানেলটিকে ঠিক সেভাবেই বর্ণনা করা হয় যেভাবে আপনার দিকের যে ডিভাইসটি এটি শেষ করে সে দেখে, তাই স্থানীয় মানে আপনার গেটওয়ের পেছনের নেটওয়ার্ক এবং দূরবর্তী মানে AWS গেটওয়ের পেছনের নেটওয়ার্ক। IPv4 ও IPv6—দুটো ফিল্ডই একই নিয়ম মেনে চলে।

কিছু লেখার আগেই দুটি লেবেল স্টিকি নোটে লিখে রাখুন: গ্রাহকের দিক, AWS-এর দিক। তারপর আপনার ঠিকানাগুলো সেগুলোর সঙ্গে মিলিয়ে নিন।

ভূমিকাসহ একটি কাজ করা উদাহরণ

ধরুন, অন-প্রিমাইজেস প্রিফিক্স 10.20.0.0/16 এবং VPC প্রিফিক্স 10.60.0.0/16। অপশনগুলো ঠিক ভূমিকা যেভাবে বলে সেভাবেই পড়া যায়, অন-প্রিমাইজেস রেঞ্জটি স্থানীয় ফিল্ডে থাকে:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

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

কোনো ডিভাইস স্পর্শ করার আগেই কাগজে পিয়ারের পরিভাষায় অনুশীলনটি পুনরাবৃত্তি করুন, দুটি CIDR ও দুটি লেবেলসহ।

ডিফল্ট কোনো ডিজাইন নয়

একই রেফারেন্সে IPv4—এর দুটি ফিল্ডের জন্যই ডিফল্ট হিসেবে 0.0.0.0/0 দেওয়া আছে, সঙ্গে অনুরূপ IPv6 মান। বিদ্যমান কোনো সংযোগে ওই মান দেখলে বোঝা যায় ফিল্ডটি কখনো সংকুচিত করা হয়নি, এটা নয় যে ইন্টারনেট এগ্রেস কনফিগার করা হয়েছে। রুট বিতরণ, সাবনেট রুট টেবিল এবং নিরাপত্তা নিয়ন্ত্রণই ঠিক করে কোন ট্রাফিক সত্যিই পার হতে পারে; CIDR মান শুধু বলে টানেল কোন রেঞ্জ নির্বাচন করতে রাজি।

তাই টানেল খারাপ আচরণ করলে সংকীর্ণ মানের বদলে ডিফল্ট বসানো কোনো সামঞ্জস্যের কৌশল নয়। এটি সিলেক্টরকে প্রশস্ত করে এবং বাকি প্রতিটি স্তরকে আগের মতোই রেখে দেয়।

পিয়ার ডিভাইস অন্য দৃষ্টিকোণ ব্যবহার করে

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

ডিভাইসের ফিল্ডের নাম নয়, ফিল্ডের সাহায্য পড়ুন। প্রস্তুতকারকরা একই দুটি শব্দ তিনটি ভিন্ন ধারণার জন্য ব্যবহার করেন।

তারপর দুই ফেজের জন্যই টানেলের অবস্থা দেখুন, কারণ বেমানান সিলেক্টর সাধারণত দ্বিতীয় ফেজের ব্যর্থতা হিসেবে দেখা যায়, আর প্রথম ফেজ তখন নিশ্চিন্তে প্রতিষ্ঠিত থাকে।

অপশন বদলান পরিবর্তন হিসেবে, ডকুমেন্টেশন হিসেবে নয়

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

পরিবর্তনের পরে AWS দিক ও পিয়ার—দুই দিক থেকেই যাচাই করুন: প্রতিটি রেঞ্জের একটি সোর্স অন্য রেঞ্জের গন্তব্যে পৌঁছায়, দুই দিকেই। এক দিক থেকে একটি ping একটিমাত্র সিলেক্টর প্রমাণ করে।

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