লাইভ টানেলে কি AWS VPN টানেল লগ চালু করা উচিত?

একটি Site-to-Site VPN-এর জন্য টানেল কার্যকলাপ লগ চালু করা ছোট একটি পরিবর্তন, যা যে টানেলটি মাপছে সেটিকেই পড়িয়ে দিতে পারে। AWS সতর্ক করে যে বিদ্যমান টানেলে লগিং চালু করলে সেটি কয়েক মিনিটের জন্য বিঘ্নিত হতে পারে, তাই আসল প্রশ্নটি পতাকাটি কীভাবে উল্টাবেন তা নয়, বরং কোন টানেলে এবং কখন উল্টাবেন। তিনটি শর্ত ক্রম নির্ধারণ করে: অন্য টানেলটি সত্যিই রুটগুলি বহন করে কি না, আপনার সেবা-ঘটনা দরকার না BGP ঘটনা, এবং পরিবর্তনটি কনসোল দিয়ে যায় না টানেল অপশন API দিয়ে। এগুলি ভুল করলে হয় বিঘ্ন, নয়তো শূন্যতায় ভরা একটি লগ গ্রুপ নিয়ে শেষ করবেন।

তিনটি শর্ত ক্রম নির্ধারণ করে

আপনি যা বদলাচ্ছেন তার পরিচয় দিয়ে শুরু করুন। আপনার VPN সংযোগ ID, রিজিয়ন এবং নির্দিষ্ট টানেলের বাইরের IP ঠিকানা দরকার, কারণ এই বৈশিষ্ট্যের প্রতিটি লগ সেটিং সংযোগভিত্তিক নয়, টানেলভিত্তিক। ভুল বাইরের ঠিকানায় প্রয়োগ করা পরিবর্তন এমন একটি টানেলের পরিবর্তন যা কেউ ডিবাগ করছিল না।

গন্তব্য একই রিজিয়নে একটি CloudWatch লগ গ্রুপ, যে ধারণ ও প্রবেশ নীতি আপনি সত্যিই চান তা নিয়ে। AWS এই গ্রুপগুলির জন্য /aws/vendedlogs/ উপসর্গের সুপারিশ করে, কারণ এটি সাধারণ নামে পৌঁছে যাওয়া রিসোর্স-নীতি আকারসীমা এড়ায়। /aws/vendedlogs/vpn/branch-a-activity-এর মতো নাম শুধু উদাহরণ; গুরুত্বপূর্ণ হল গ্রুপটি আছে, ডেলিভারি ভূমিকা সেখানে লিখতে পারে, এবং দুটিই VPN কনফিগারেশনের মালিক দ্বারা পরিচালিত। নাম অনুমতি দেয় না, এবং ডেলিভারি নীতি ছাড়া তৈরি গ্রুপ ত্রুটি নয়, নীরবতা তৈরি করে।

প্রথম শর্ত: সত্যিই ট্রাফিক বহনকারী একটি অতিরিক্ত টানেল

এটি সেই শর্ত যা দলগুলি এড়িয়ে যায়। দুটি কনফিগার করা টানেল প্রমাণ নয় যে অ্যাপ্লিকেশনটির একটি ব্যবহারযোগ্য বিকল্প পথ আছে।

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

দ্বিতীয় শর্ত: কার্যকলাপ লগ নাকি BGP লগ

এটি নির্ধারণ করে আপনি আসলে কী পড়তে পারবেন। কার্যকলাপ রেকর্ড সেবা-ঘটনা কভার করে, যেমন IKE ও IPsec অবস্থা পরিবর্তন এবং DPD বার্তা, যা আপনি চান যখন টানেল উঠে না বা বারবার কী পুনর্নবীকরণ করে। BGP রেকর্ড নিজস্ব নিয়ন্ত্রণসহ আলাদা প্রবাহ, এবং তারা ভিন্ন প্রশ্নের উত্তর দেয়: রুটগুলি প্রত্যাশিতভাবে বিনিময় ও প্রত্যাহার হয়েছে কি না।

কার্যকলাপ পতাকা চালু করা সেবাটি যত প্রবাহ নির্গত করতে পারে তার সবগুলির জন্য অনুরোধ নয়। সন্দেহ যদি রাউটিং হয়, দুটিই চালু করুন; সন্দেহ যদি ফেজ 1 বা ফেজ 2 আলোচনা হয়, কার্যকলাপ প্রবাহই তা দেখাবে।

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

তৃতীয় শর্ত: কনসোল পরিবর্তন নাকি টানেল অপশন API

কোনো মানুষ একবারের পরিবর্তন করলে কনসোল পথটি ঠিক আছে: VPC console, Site-to-Site VPN connections, সংযোগটি বাছুন, Actions, Modify VPN tunnel options, বাইরের IP বাছুন, Tunnel activity log চালু করুন, গ্রুপ ও আউটপুট ফরম্যাট বাছুন, সময়সীমার ভিতরে সংরক্ষণ করুন। VPN যদি কোড হিসেবে পরিচালিত হয়, একই ক্লিক পরে সমন্বয় করতে হবে এমন ড্রিফট।

স্বয়ংক্রিয়করণের জন্য টানেল অপশনের কার্যকলাপ-লগ অংশের একটি নির্দিষ্ট আকার আছে: LogOptions যাতে CloudWatchLogOptions আছে, সাথে LogEnabled, LogGroupArn এবং LogOutputFormat। ওই ব্লকটি খণ্ড, অনুরোধ নয়; modify-vpn-tunnel-options-এর এখনও সংযোগ ID ও টানেলের বাইরের IP দরকার, এবং বাকি টানেল সেটিংস টেমপ্লেটের মালিককে সংরক্ষণ করতে হবে। BGP লগিং একই কাঠামোয় নিজস্ব BgpLogEnabled, BgpLogGroupArn এবং BgpLogOutputFormat কী ব্যবহার করে। কলটি প্রয়োগ হয়েছে ভরসা না করে describe-vpn-connections দিয়ে পরিবর্তনটি আবার পড়ুন।

রেকর্ডগুলি আপনাকে কী বলতে পারে আর কী পারে না

প্রথম টানেল শেষ হলে এবং অভীষ্ট পথ পাওয়া গেলে, দ্বিতীয় টানেলেরও লগ দরকার হলে একই নিয়ন্ত্রিত ক্রমটি পুনরাবৃত্তি করুন। একবারে একটি টানেল — এটাই মূল কথা।

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

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