محدودیت‌های Cloud VPN که نمی‌توانید تنظیم کنید: عمر IKE و NAT همتا

به دستگاه راه دور عمر 24 ساعته برای فاز 1 بدهید و تونل Cloud VPN پایین می‌ماند، حتی وقتی همه‌چیز در سمت Google درست پیکربندی شده است. همتا مقداری پیشنهاد می‌کند که پاسخ‌دهنده آن را نمی‌پذیرد، بنابراین مذاکره یا کاملاً شکست می‌خورد یا بی‌پایان دوباره شروع می‌شود. Cloud VPN فاز 1 را به 36,000 ثانیه، یعنی ده ساعت، محدود می‌کند و این سقف تنظیمی نیست که بتوانید بالا ببرید. تغییر باید روی دستگاه راه دور انجام شود.

همتا می‌پرسد، پاسخ‌دهنده تصمیم می‌گیرد

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

پیش از باز کردن تیکت، وضعیت خود تونل را بخوانید، چون وضعیت تفصیلی معمولاً مرحله‌ای را که شکست خورده نام می‌برد:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

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

36,000 ثانیه سقف است

فاز 1 در 36,000 ثانیه متوقف می‌شود. دستگاهی که روی 86,400 تنظیم شده چیزی می‌خواهد که پاسخ‌دهنده هرگز با آن موافقت نمی‌کند، و تلاش دوباره نظرش را عوض نمی‌کند. پیشنهاد راه دور را به داخل محدوده برگردانید و همان پیکربندی برقرار می‌شود؛ این عدم تقارن تمام درس است، چون می‌توانید مقدار خودتان را کم کنید و نمی‌توانید مقدار Google را بالا ببرید.

مقدار انتخاب‌شده را در یادداشت‌های طراحی بنویسید. وگرنه مهندس بعدی آزمایش 24 ساعته را تکرار می‌کند و به همان دیوار می‌رسد.

مجموعه پشتیبانی‌شده برای هر نوع دروازه و نسخه IKE منتشر می‌شود در نمای کلی Cloud VPN، پس بخش مربوط به توپولوژی خودتان را بخوانید، نه یک راهنمای عمومی IKE.

تونلی که طبق برنامه می‌افتد

فاز 2 رفتار متفاوتی دارد: وقتی دو سر توافق ندارند، بازتولید کلید از فاصله کوتاه‌تر پیروی می‌کند. همتایی که ناهمخوانی را مرگبار می‌داند به‌جای آن تونل را رها می‌کند، بنابراین یک ناهمخوانی می‌تواند مثل دو نقص بی‌ربط به نظر برسد. ریتم بازتولید کلید را ببینید، نه فقط اولین اتصال را. تونلی که بالا می‌آید و بعد با ضرب‌آهنگ منظم می‌افتد، بیشتر ناهمخوانی عمر است تا نقص مسیریابی.

پیش از هر تغییری، آن مهرهای زمانی افتادن را با گزارش‌های خود همتا مرتبط کنید، چون تغییر انتخاب‌گر یا مسیر می‌تواند همان ریتم را تقلید کند. اگر ضرب‌آهنگ با تایمر فاز 2 بخواند، علت بدون دست زدن به هیچ پیشنهادی پیدا شده است.

مجموعه‌ها از نوع دروازه می‌آیند

مجموعه‌های رمزنگاری و یکپارچگی، پروفایل جداگانه هر تونل نیستند که مثل strongSwan ویرایش کنید. آن‌ها را بر اساس نوع دروازه و نسخه IKE انتخاب می‌کنید، و گشتن دنبال پروفایلی که وجود ندارد یک بعدازظهر را تلف می‌کند.

دستگاه قدیمی که چیزی در محدوده مجموعه پشتیبانی‌شده ارائه نمی‌دهد دو راه صادقانه باقی می‌گذارد: دستگاه را عوض کنید، یا روی دروازه نرم‌افزاری که خودتان کنترل می‌کنید پایان دهید و از آنجا به VPC مسیریابی کنید. هر چیز دیگری یک راه‌حل دور زدن است که در بازبینی بعدی رد می‌شود.

یک نشانی خارجی برای هر دستگاه

نشانی خارجی همتا باید یک‌به‌یک به نشانی داخلی آن نگاشت شود. مخزن PAT اشباع‌شده نمی‌تواند کار کند، چون چند میزبان پشت یک نشانی عمومی، هیچ راهی برای تفکیک آن‌ها به پاسخ‌دهنده نمی‌دهند. جایی که چند میزبان باید یک نشانی را شریک شوند، تونل باید جایی پایان یابد که بتواند آن‌ها را از هم تشخیص دهد.

آن نشانی خارجی را هم پایدار نگه دارید. دستگاه را پشت NAT دیگری ببرید و پیوند می‌شکند، هرچند هر پیشنهاد هنوز منطبق است. ارزشش را دارد که بنویسید کدام مقدارها مال Google است و کدام مال شما: عمرها، مجموعه‌ها و NAT یک‌به‌یک در سمت آن‌ها ثابت‌اند، در حالی که پیشنهادها، انتخاب‌گرها، مسیریابی و اولویت‌های BGP مال شما هستند.