چرخش PSK در AWS VPN: کدام تونل قطع میشود و چه زمانی
تغییر یک کلید از پیش اشتراکشدهٔ تونل AWS VPN آن تونل را قطع میکند تا زمانی که دو طرف به توافق برسند. ابتدا مسیر جایگزین را اثبات کنید، سپس تونلها را یکییکی بچرخانید.
تونل در همان لحظهای قطع میشود که دو سر دربارهٔ کلید از پیش اشتراکشده اختلاف دارند، و پایین میماند تا هر دو طرف مقدار جدید را حمل کنند. این بخش قابل انتظار است: AWS این تغییر را وقفهای در تونل انتخابشده میداند، و همتا تا زمانی که کلیدها متفاوت باشند IKE را تمام نمیکند. آنچه مردم را شگفتزده میکند نیمهٔ دوم است. تونل دیگر بهخودیخود ترافیک را برنمیگیرد، مگر اینکه بررسی کرده باشید که میتواند آن را حمل کند. به این ترتیب بچرخانید تا وقفه درون یک تونل بماند.
واقعاً وقتی کلید تغییر میکند چه اتفاقی میافتد
ModifyVpnTunnelOptions گزینههای یک تونل را بازنویسی میکند که با نشانی IP بیرونی آن شناسایی میشود. تونل فروپاشیده و از نو ساخته میشود، پس IKE و IPsec از صفر با کلید جدید مذاکره میکنند. AWS اعلام میکند که وقفه میتواند چند دقیقه طول بکشد، که برای اینکه یک پروتکل مسیریابی آن را ببیند کافی است. تونل دیگر در همان اتصال با این فراخوانی دستنخورده میماند.
اثر دومی هست که پیش از فرستادن هر چیزی ارزش دانستن دارد. عملیات تغییر مجموعهٔ کامل گزینههای تونل را میگیرد، بنابراین فیلدی که جا بیندازید با مقدار پیشفرض خود بازنویسی میشود. اگر طول عمر فاز 1 یا فاز 2 یا تنظیمات تشخیص همتای مرده را تنظیم کردهاید، مقادیر فعلی را در همان درخواست بفرستید یا برای بازگرداندنشان پس از آن برنامه داشته باشید.
اول مقادیر فعلی را بخوانید، سپس یک فیلد را تغییر دهید. این ترتیب تمام انضباط این کار است.
ابتدا تونل AWS را با همتای درست جفت کنید
کنسول تونلها را بر اساس ترتیب برچسب میزند و دستگاه شما از آن برچسب استفاده نمیکند. تونل را با نشانی IP بیرونی آن شناسایی کنید و آن را با بخش همتا در دروازهٔ مشتری جفت کنید. تونل 1 در یک پیکربندی محلی مدرکی نیست که تونلی را ویرایش میکنید که AWS آن را تونل 1 مینامد.
از خود اتصال شروع کنید که هر دو تونل و کلیدی را که هر یک اکنون نگه میدارد فهرست میکند:
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
--query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"کلیدی که برمیگردد همان است که اکنون استفاده میشود. پیش از تغییر هر چیزی آن را با پیکربندی همتا مقایسه کنید، زیرا ناسازگاریای که از قبل وجود دارد تونلی را توضیح میدهد که هرگز پایدار نبوده است.
ابتدا بگذارید تونل دیگر ترافیک را حمل کند
دو تونل در یک اتصال اثبات نمیکنند که دستگاه شما هر دو را پیکربندی کرده است، که هر دو پیشوندهای موردنیاز شما را اعلام میکنند، یا اینکه ترافیک میان آنها جابهجا میشود. مذاکرهٔ تونل جایگزین، مسیرهای آن و یک جریان واقعی برنامه در هر دو جهت را بررسی کنید. با BGP، مجاورت فعال شاهد مفیدی است اما با تأیید پیشوندها یکی نیست. با مسیریابی ایستا، تأیید کنید که دروازه چگونه مسیر را انتخاب میکند و وقتی مسیر ترجیحی ناپدید میشود چه میکند.
اگر جایگزین نمیتواند بار کاری را حمل کند، پیش از دست زدن به کلید، وقفه را زمانبندی کنید یا تونل جایگزین را تعمیر کنید. یک چراغ وضعیت روی صفحهٔ کنسول وعدهٔ سرویس بدون وقفه نیست.
یک تونل را بچرخانید، سپس با ترافیک واقعی بررسی کنید
وقتی مسیر جایگزین اثبات شد، ترتیب کوتاه است. نشانی تونل، همتای آن و تنظیمات غیرسرّی را ثبت کنید و یک مسیر مدیریتی به دروازه نگه دارید که به تونلی که میخواهید بشکنید وابسته نباشد.
- همتای دروازهٔ مشتری را برای نشانی بیرونی انتخابشده بهروزرسانی کنید، یا تغییر را طوری آماده کنید که چند ثانیه پس از فراخوانی API اعمال شود.
- فراخوانی تغییر را با کلید جدید بههمراه طول عمرهای فعلی و مقادیر DPD بفرستید.
- منتظر بمانید تا IKE و IPsec برگردند، سپس مسیرها و پیشوندهای لازم را تأیید کنید.
- یک جریان نمونهٔ برنامه را از آن تونل عبور دهید و هر دو جهت را تماشا کنید.
تونل تا وقتی دو سر اختلاف دارند و تا وقتی AWS تغییر را اعمال میکند غیرقابلاستفاده است، پس بهروزرسانی همتا باید بیدرنگ پس از آن بیاید نه بعد از ناهار. تنها وقتی تونل تغییرکرده ترافیک واقعی را حمل کند باید روند را روی دیگری تکرار کنید.
اگر پس از تونل اول بازیابی یا مسیریابی هنوز نامطمئن است توقف کنید. دو تونل نیمهکاره بدتر از تونلی است که میدانید کار میکند.
وقتی بازیابی گیر میکند، سمت IKE را بخوانید
تونلی که پس از داشتن کلید جدید در هر دو سر پایین میماند معمولاً ناسازگاری سیاستی است که چرخش آن را آشکار کرده نه ایجاد. پیشنهادها، هویتی که همتا میفرستد و انتخابگرهای ترافیک همه باید با سمت AWS توافق داشته باشند، و مقداری که از یک تونل برقرار جان به در برده است باز هم میتواند در مذاکرهٔ تازه رد شود. پیش از تغییر دوبارهٔ کلید، وضعیت مذاکره و پیام پیوستشده به آن را بخوانید.
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
--query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"اگر باید تغییر را برگردانید، کلید قدیمی را فقط به این دلیل که قبلاً کار میکرد بازنگردانید. با کلید افشاشده مانند کلید افشاشده رفتار کنید و در عوض مذاکره را درست کنید. با تأیید هر دو تونل و بهروزرسانی فهرست اسرار تمام کنید تا هر همتا ثبت کند کدام مقدار را نگه میدارد، و مستندات گزینههای تونل AWS را کنار رانبوک نگه دارید.