AWS Client VPN স্প্লিট টানেল: কোন রুটগুলি প্রকাশ করবেন

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

স্প্লিট-টানেল ফ্ল্যাগ কোনো গন্তব্যের তালিকা নয়

AWS স্প্লিট টানেলিংকে বর্ণনা করে সংযোগ স্থাপনের সময় ক্লায়েন্টের রুট টেবিলে এন্ডপয়েন্ট রুট যোগ করা হিসেবে। প্রাইভেট VPC-র জন্য একটি রুট টানেলকে সেই গন্তব্যে সীমিত রাখে; বাকি সব ক্লায়েন্টের স্বাভাবিক পথ অনুসরণ করে। ডিফল্ট রুট আলাদা প্রভাবযুক্ত আলাদা নির্দেশ, তাই স্প্লিট-টানেল ডকুমেন্টেশন এই মোডের জন্য কনফিগার করা এন্ডপয়েন্টে 0.0.0.0/0 প্রকাশের বিরুদ্ধে সতর্ক করে: এটি সংযোগ বাড়ানোর বদলে সাধারণত ভেঙে দেয়। এন্ডপয়েন্ট রুট টেবিল হলো নীতি, আর ক্লায়েন্ট রুট টেবিল হলো ফলাফল যা আপনি পরীক্ষা করতে পারেন।

এন্ডপয়েন্ট রুট টেবিল এবং ক্লায়েন্টে ইনস্টল করা রুট একসঙ্গে পড়ুন। লেবেল একটি অভিপ্রায় বর্ণনা করে; রুটগুলি বর্ণনা করে কী ঘটে।

প্রথম সিদ্ধান্ত: সাধারণ ইন্টারনেট ট্র্যাফিক কি লোকাল থাকা উচিত?

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

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

দ্বিতীয় সিদ্ধান্ত: কোন প্রাইভেট প্রিফিক্স, কার অনুমোদনে?

প্রকৃত কাজের চাহিদা মেটায় এমন ক্ষুদ্রতম গন্তব্য সেট প্রকাশ করুন, এবং যাচাই করুন যে প্রতিটি সংশ্লিষ্ট সাবনেট তাদের কাছে রুট করতে পারে. এন্ডপয়েন্টের রুট টার্গেট এবং সাবনেটের VPC রাউটিং আলাদা স্তর, আর একটিতে বিদ্যমান রুট অন্যটি সম্পর্কে প্রমাণ নয়। অনুমোদন আবার আলাদা: একটি গন্তব্য পৌঁছানোযোগ্য হয়েও অস্বীকৃত হতে পারে, কারণ ক্লায়েন্টের গ্রুপের এমন নিয়ম নেই যা তা অনুমোদন করে।

একটি সফল সেশন পরীক্ষা করা একটি পথ প্রমাণ করে। প্রতিটি সংশ্লিষ্ট সাবনেট পরীক্ষা করুন, কারণ পরে যোগ করা সাবনেট সংযোগই সাধারণত অনুপস্থিত রুটের জায়গা।

যখন কোনো গন্তব্যকে নাম দিয়ে পৌঁছানোযোগ্য হতে হবে, লক্ষ্য করুন যে নাম রেজলিউশনের প্রশ্নটিই পরবর্তী, রুটের প্রশ্ন নয়।

তৃতীয় সিদ্ধান্ত: কোন রেজলভার টানেল অনুসরণ করে?

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

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

রুট সেট পরিবর্তন করুন, তারপর দুই জগৎই যাচাই করুন

AWS নথিভুক্ত করে যে স্প্লিট-টানেল এন্ডপয়েন্টে রুট পরিবর্তন করলে ক্লায়েন্ট সংযোগ রিসেট হয়। সেই কথা মাথায় রেখে পরিবর্তনের পরিকল্পনা করুন: এটি প্রয়োগ করুন, সমর্থিত ক্লায়েন্ট দিয়ে আবার সংযোগ করুন, এবং সম্পাদনার আগে প্রয়োগ করা অবস্থার উপর ভরসা না করে ইনস্টল করা রুট আবার পড়ুন। পুরনো প্রয়োগ করা অবস্থাই সঠিক পরিবর্তনকে ভাঙা দেখানোর সবচেয়ে সাধারণ কারণ।

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

রুট তালিকাটি যুক্তির পাশে রানবুকে লিখে রাখুন, যাতে পরের ব্যক্তি ইচ্ছাকৃত বাদ দেওয়া আর ভুলে যাওয়া বাদ দেওয়ার পার্থক্য বুঝতে পারে।