উৎস/গন্তব্য যাচাই একটি দরজা, পুরো VPN পথ নয়

VPN একটি EC2 ইনস্ট্যান্সে শেষ হয়, আপনি সেই ইনস্ট্যান্সের টানেল ঠিকানায় পৌঁছাতে পারেন, আর অন্য একটি ব্যক্তিগত হোস্টের দিকে এর মধ্য দিয়ে যাওয়ার কথা থাকা ট্রাফিক উধাও হয়ে যায়। এগুলো দুটি আলাদা পরীক্ষা, আর দুটিকে মিশিয়ে ফেললে ঘণ্টা নষ্ট হয়। প্রথমটি জিজ্ঞেস করে আপনি ইনস্ট্যান্সে পৌঁছাতে পারেন কি না; দ্বিতীয়টি চায় যে এটি এমন একটি গন্তব্যের জন্য ট্রাফিক ফরওয়ার্ড করুক যা এর নিজের নয়, যার জন্য দরকার Linux ফরওয়ার্ডিং, ফায়ারওয়াল নীতি, দূর পাশে একটি রুট এবং AWS স্তরের একটি অনুমতি, যার অতিথি অপারেটিং সিস্টেমের সঙ্গে কোনো সম্পর্ক নেই। কনসোলে কিছুই ওই পার্থক্যের দিকে মনোযোগ আকর্ষণ করে না। উপসর্গটি রাউটিং ত্রুটির মতো দেখায়, আর সাধারণত তা নয়।

কিছু বদলানোর আগে দুটি পরীক্ষা আলাদা করুন

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

গেটওয়েতে কাজ করা ping আর তার ওপারের হোস্টে ব্যর্থ হওয়া ping কোনো মাঝে মাঝে আসা সমস্যা নয়। এটি এমন একটি ইনস্ট্যান্সের প্রত্যাশিত আচরণ, যাকে বলা হয়নি যে সে ফরওয়ার্ড করতে পারে।

কোনো সেটিংসে হাত দেওয়ার আগে পথটি লিখে ফেলুন

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

তারপর উৎস/গন্তব্য যাচাইয়ের সেটিংসটি প্রকৃত ফরওয়ার্ডিং উপাদানে দেখুন, VPC-র প্রতিটি ইনস্ট্যান্সে নয়। AWS নথিভুক্ত করে কেন অন্যদের জন্য ট্রাফিক ফরওয়ার্ড করা ইনস্ট্যান্সের ওই যাচাই বন্ধ রাখা দরকার, এবং কেন সেটিংটি VPC-ব্যাপী ডিফল্ট নয় বরং প্রতিটি ইনস্ট্যান্সের সিদ্ধান্ত।

চারটি সীমানা, আর যাচাই তাদের মধ্যে কেবল একটি

পথটিকে চারটি প্রশ্ন হিসেবে ধরুন এবং ক্রম অনুসারে উত্তর দিন। প্রথম ব্যর্থ উত্তরই কাজের জায়গা, আর বাকিগুলোর কোনোটিই তার ক্ষতিপূরণ দেবে না।

ক্রমটি গুরুত্বপূর্ণ কারণ যাচাই করা সস্তা: রুটগুলো এক পাতায় দেখা যায়, যাচাই একটি মাত্র বৈশিষ্ট্য, আর গন্তব্যের মত সাধারণত সবার শেষে জিজ্ঞাসা করা জিনিস।

অনুবাদ বদলে দেয় গন্তব্য কোন উৎস দেখে

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

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

মূল ক্লায়েন্ট থেকে পরীক্ষা করুন, তারপর পরিবর্তনটি ধরে রাখুন

গেটওয়েতে তৈরি একটি অনুরোধ সফল হতে পারে অথচ ফরওয়ার্ড করা অনুরোধ ব্যর্থ হয়, কারণ এটি ভিন্ন উৎস ও ভিন্ন ফরওয়ার্ডিং কেস। লক্ষ্যযুক্ত সংশোধনের পর যে ক্লায়েন্ট-থেকে-রিসোর্স পরীক্ষাটি ব্যর্থ হয়েছিল ঠিক সেটিই একই ক্লায়েন্ট থেকে পুনরাবৃত্তি করুন, এবং অনুরোধ পৌঁছেছে কিনা তা নয়, উত্তরটি ফিরে আসছে কিনা তা নিশ্চিত করুন।

সবশেষে, সেটিংটি গেটওয়ের পরিচালিত কনফিগারেশনে রাখুন যাতে প্রতিস্থাপক ইনস্ট্যান্স তা পায়। হাতে করা ব্যতিক্রমের উপর নির্ভর করা সফল পরীক্ষা এমন এক পরীক্ষা যা পরের পুনর্নির্মাণেই শেষ হয়, আর যে ব্যক্তি এটি আবিষ্কার করেছে সে কেন তা মনে রাখতে সেখানে থাকবে না।