آیا باید گزارش‌های تونل AWS VPN را روی یک تونل فعال روشن کنید؟
فعال‌کردن گزارش‌های فعالیت تونل می‌تواند یک تونل فعال را چند دقیقه قطع کند. پیش از هر تغییری تصمیم بگیرید کدام تونل، کدام نوع گزارش و کدام بازه زمانی.
روشن‌کردن گزارش‌های فعالیت تونل برای یک VPN سایت‌به‌سایت تغییری کوچک است که می‌تواند تونلی را که اندازه می‌گیرد از کار بیندازد. AWS هشدار می‌دهد که فعال‌کردن ثبت رویداد روی یک تونل موجود می‌تواند آن را چند دقیقه قطع کند، پس پرسش جالب این نیست که چگونه پرچم را برگردانیم، بلکه این است که روی کدام تونل و چه زمانی این کار را بکنیم. سه شرط ترتیب را تعیین می‌کند: آیا تونل دیگر واقعاً مسیرها را حمل می‌کند، آیا به رویدادهای سرویس نیاز دارید یا رویدادهای BGP، و آیا تغییر از طریق کنسول انجام میشود یا از طریق API گزینه‌های تونل. اگر اینها را اشتباه کنید، یا با یک قطعی روبه‌رو می‌شوید یا با یک گروه گزارش پر از هیچ.
سه شرط ترتیب را تعیین می‌کند
از هویت چیزی که تغییر می‌دهید شروع کنید. به شناسه اتصال VPN، منطقه و نشانی 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 هنوز به شناسه اتصال و IP بیرونی تونل نیاز دارد، و بقیه تنظیمات تونل را باید مالک قالب حفظ کند. ثبت BGP هم کلیدهای خودش BgpLogEnabled، BgpLogGroupArn و BgpLogOutputFormat را در همان ساختار به کار می‌برد. تغییر را با describe-vpn-connections دوباره بخوانید، به‌جای اعتماد به اینکه فراخوانی اعمال شده است.
رکوردها چه می‌توانند بگویند و چه نمی‌توانند
وقتی تونل اول انجام شد و مسیر موردنظر در دسترس بود، اگر به گزارش‌های تونل دوم هم نیاز دارید همان توالی کنترل‌شده را برای آن تکرار کنید. یک تونل در هر لحظه تمام نکته است.
رکوردها در جریان‌هایی می‌رسند که با اتصال و نشانی بیرونی تونل شناسایی می‌شوند، پس با همان هویت همبستگی برقرار کنید نه اینکه انتظار داشته باشید تاریخچه به‌صورت گذشته‌نگر ظاهر شود. چیزی پیش از تغییر وجود ندارد و هیچ انتظاری شکاف را پر نمی‌کند. اگر به یک خط مبنا نیاز دارید، وضعیت فعلی تونل و جدول مسیریابی را پیش از تغییر ثبت کنید تا چیزی برای مقایسه وجود داشته باشد.
گروه گزارش، نگهداری آن، مجوزهای تحویل آن و بلوک گزینه‌های تونل را در همان فهرستی نگه دارید که خود VPN هست، چون یک پیکربندی هستند که روی چهار جا پخش شده است. روش AWS برای فعال‌کردن گزارش‌ها جریان کار هر تونل و هشدار قطعی آن را مستند می‌کند و ارزش خواندن پیش از تغییر را دارد نه بعد از آن. سپس به ترتیب بررسی کنید: تونل برگشت، رکوردها در جریان موردانتظار ظاهر می‌شوند، و رکوردها به پرسشی که بلیت را برایش باز کردید پاسخ می‌دهند. اگر سومی شکست بخورد، مشکل انتخاب جریان بود نه ثبت رویداد.