به‌صورت پیش‌فرض، یک AWS Site-to-Site VPN منتظر می‌ماند تا customer gateway مذاکره را آغاز کند. این پیش‌فرض یک تنظیم است، نه قانون، و نام تنظیم Startup action است. پیش از آن‌که سراغ آن بروید، دو پرسشی را که پیوسته با هم اشتباه می‌شوند جدا کنید: چه کسی تونل را برپا می‌کند، و آیا بسته‌هایی که برایتان مهم‌اند مسیری از آن دارند. تنها پرسش نخست در گزینه‌های تونل است.

کنش راه‌اندازی را از کنش پایان مهلت DPD جدا کنید

دو گزینه برای هر تونل دو رویداد متفاوت را کنترل می‌کنند، و تنظیم یکی هیچ چیزی درباره دیگری نمی‌گوید.

EventOptionUseful values
A new or modified VPN connection needs a tunnelStartup actionadd waits for the peer; start asks AWS to initiate
Dead peer detection times outDPD timeout actionclear ends the session, restart reinitiates, none does nothing

اگر AWS باید تونلی جدید یا تغییرکرده برپا کند، انتخاب کنید start. اگر AWS باید پس از پایان مهلت DPD مذاکره را نیز از نو آغاز کند، برای آن رویداد جداگانه restart را پیکربندی کنید. هیچ‌کدام از دو گزینه سیاست تلاش دوباره برنامه نیست، و هیچ‌کدام فاصله تغییر کلید نیست: DPD بررسی می‌کند که همتا زنده است یا نه، در حالی که تغییر کلید security associations را روی تونلی فعال جایگزین می‌کند.

برنامه‌ای که در حالی مهلتش تمام می‌شود که تونل هنوز up گزارش می‌دهد، مشکل مسیر داده دارد. کوتاه کردن تایمر DPD آن را درست نمی‌کند و ممکن است آشوبی بیفزاید که بعداً باید توضیح دهید.

بررسی کنید که AWS جایی برای فرستادن مذاکره دارد

آغازگری از سمت AWS فقط با IKEv2 ممکن است، و AWS به نشانی عمومی customer gateway نیاز دارد تا بداند پیشنهاد را کجا بفرستد. موردی که دردناک است، منبع customer gateway با احراز هویت گواهی است که بدون نشانی ساخته شده: مستندات AWS ساختن منبع customer gateway تازه با نشانی و سپس تغییر اتصال VPN برای اشاره به آن را توضیح می‌دهد.

گواهی ثابت می‌کند همتا کیست. اما به AWS نمی‌گوید همتا کجاست، و این‌ها دو نیاز متفاوت‌اند. به همین دلیل راه‌حل منبع customer gateway تازه است، نه گواهی تازه. عوض کردن گواهی، AWS را با همان مقصد گمشده رها می‌کند.

اگر customer gateway پشت NAT باشد, AWS به responder identity پیکربندی‌شده نیز نیاز دارد، IDr, تا هویت همتا با آنچه دستگاه انتظار دارد بخواند. پیش از آن‌که گزینه‌ای را که همین حالا تغییر دادید سرزنش کنید، آن مقدار و مسیر دیوار آتشی را که ترافیک IKE را می‌پذیرد تأیید کنید. انتخاب start نمی‌تواند همتای دسترس‌ناپذیر یا بدشناسایی‌شده را به پذیرش پیشنهاد وادار کند.

تغییر را روی یک تونل اعمال کنید و انتظار وقفه داشته باشید

یک اتصال VPN دو تونل با گزینه‌های مستقل دارد، پس با نشانی بیرونی تأیید کنید کدام را ویرایش می‌کنید. AWS اجازه می‌دهد هر بار یک تونل تغییر کند، و اتصال روی تونل انتخاب‌شده ممکن است چند دقیقه قطع شود.

  1. اتصال Site-to-Site VPN را انتخاب کنید و Modify VPN tunnel options را باز کنید.
  2. تونل را بر پایه نشانی IP بیرونی انتخاب کنید و نسخه IKE و منبع customer gateway آن را تأیید کنید.
  3. کنش‌های راه‌اندازی و DPD را که واقعاً می‌خواهید تنظیم کنید، سپس در پنجره‌ای که خودتان کنترل می‌کنید ذخیره کنید.
  4. تأیید کنید که تونل تغییرکرده برپا می‌شود، و پیش از تغییر بعدی تونل دیگر و مسیریابی را بررسی کنید.

یک رفتار پیش از نگهداری شایسته توجه است. با فعال بودن آغازگری AWS هیچ مهلتی وجود ندارد: AWS تا بالا آمدن تونل تلاش می‌کند، و وقتی customer gateway پیام delete-SA می‌فرستد از نو آغاز می‌کند. اگر همتا را عمداً پایین بیاورید، AWS همچنان در می‌زند و گزارش‌های همتا آن را نشان می‌دهند.

مسیر برنامه را بررسی کنید، نه فقط وضعیت تونل را

تونلی که up گزارش می‌دهد با درخواستی که کار می‌کند یکی نیست. تابع Lambda متصل به VPC هنوز به مسیر subnet به پیشوند مشتری، به قواعد security group و network ACL که ترافیک را مجاز می‌کنند، به تفکیک نامی که نشانی درست را برمی‌گرداند، و به مسیر بازگشت در سمت مشترینیاز دارد.

یک بار با درخواستی واقعی از بستر برنامه آزمون کنید، و اگر شکست خورد flow logs را بخوانید. ترافیک keepalive گزینه‌ای مشروع است وقتی آغازگری AWS خاموش است و تونل بی‌کار برای ماندن به بسته نیاز دارد، اما باید تصمیم پایشگری باشد که می‌توانید نامش را ببرید، نه حلقه ping توضیح‌نشده‌ای که به یک تابع پیچ شده است.

نخست انتخاب کنید چه کسی تونل را برپا می‌کند، سپس باقی شکست را در لایه خودش عیب‌یابی کنید. مستندات AWS درباره آغازگری نیازهای نشانی، هویت و تلاش دوباره را با جزئیات بیشتری از اشاره‌های کنسول پوشش می‌دهد.

مقالات مرتبط