Cloud VPN به Cisco ASA: بازسازی پس از ناسازگاری پیشنهاد

خطای NEGOTIATION_FAILURE روی تونل Cloud VPN با یک Cisco ASA در طرف دور تقریباً همیشه ناسازگاری پیشنهاد یا انتخابگرهاست، و نخستین واقعیت سودمند این است که هیچ ویرایشی آن را درست نمی‌کند. Cloud VPN پیشنهاد IKE را هنگام ساخت شیء تونل تثبیت می‌کند. هیچ فیلدی برای تغییر الگوریتم در جای خود وجود ندارد، پس تعمیر یعنی حذف و ساخت دوباره با یک نقطه شروع ثبت‌شده. آن را بازسازی در نظر بگیرید و کار به یک فهرست بررسی تبدیل می‌شود، نه یک بعدازظهر حدس و گمان.

پیش از حذف هر چیز، شکست را بخوانید

شکست مذاکره یک مشکل فازی است و گزارش همتا معمولاً فاز را نام می‌برد. شکست فاز 1 یعنی دو طرف نتوانستند بر پیشنهادی توافق کنند یا نتوانستند یکدیگر را احراز هویت کنند. شکست فاز 2 یعنی تونل بالا آمد و انتخابگرهای محافظت‌شده مطابقت نداشتند. این‌ها تعمیرهای متفاوتی هستند و ارزش دارد پیش از آنکه کسی به پیکربندی دست بزند، خط گزارش را استخراج کنید.

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

هر دو پیکربندی را تا زمانی که هنوز وجود دارند ثبت کنید

حذف یک تونل نیم دقیقه طول می‌کشد و تنها مدرکی را که داشتید نابود می‌کند. پیش از آن، انتخابگرهای محلی و دور، نشانی همتا، اینکه راز مشترک از کیست، و crypto map یا نمایه IKEv2 روی ASA را بنویسید. ASA به دو پرسش جداگانه پاسخ می‌دهد: چه چیزی پیکربندی شده و چه چیزی اکنون بالاست:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

در سمت Google، شیء تونل را بخوانید نه خلاصه کنسول را، چون نشانی همتا و فیلدهای انتخابگر همان مقادیری هستند که باید دقیقاً بازتولید کنید:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

آن مقادیر را پیش از نخستین حذف در تیکت بنویسید. بازسازی زیر فقط به این دلیل کار می‌کند که می‌توانید همان شیء را با یک تفاوت آگاهانه دوباره بسازید.

الگوریتم‌هایی که یک طرف از مذاکره بر آن‌ها سر باز می‌زند

Cloud VPN مانند یک همتای سنتی از میان طیفی از الگوریتم‌های IKEv1 انتخاب نمی‌کند. تنظیمات همتایی که انتظار دارد ثابت است: aes-cbc-128 برای رمزنگاری، sha1-96 برای یکپارچگی و PRF، گروه Diffie-Hellman 2، 36,600 ثانیه برای فاز 1 و 10,800 ثانیه برای فاز 2. سیاست ASA باید دقیقاً همین مجموعه را ارائه دهد. پیشنهاد دوم روی ASA ضرری ندارد، به شرط آنکه پیشنهاد منطبق هم در فهرست باشد.

IKEv2 به هر دو طرف فضای بیشتری می‌دهد، اما قواعد همان شکل را حفظ می‌کنند: PFS را فعال کنید، گروه DHی را انتخاب کنید که تونل پشتیبانی می‌کند، و فهرست پیشنهادها را به‌قدری کوتاه نگه دارید که ناسازگاری آشکار باشد. همتای ASA روی Cloud VPN یعنی مسیریابی ایستا هم، پس پیشوندهای محافظت‌شده باید برنامه‌ریزی و فهرست شوند، نه به BGP سپرده شوند.

عمر کپی‌شده از قالب فروشنده‌ای دیگر همان پیچ اشتباه همیشگی اینجاست. Google این مقادیر را به‌عنوان تنظیمات الزامی همتا منتشر می‌کند، پس آن‌ها را تنظیم کنید؛ مقدار کوتاه‌تر به‌سمت بالا تا آنچه ASA می‌خواهد مذاکره نمی‌شود.

حذف کنید، دوباره بسازید و وضعیت قدیمی را پاک کنید

تونل را حذف کنید، نه دروازه را، و نامی را که Cloud VPN به جایگزین می‌دهد یادداشت کنید، چون نام‌ها تخصیص می‌یابند و بازاستفاده نمی‌شوند. آن را با مقادیر ثبت‌شده و همان نشانی همتا دوباره بسازید، سپس پیشنهاد منطبق را به فهرست سیاست ASA بیفزایید.

انجمن‌های امنیتی را پس از تغییر ASA و پیش از خواندن نتیجه پاک کنید. ASA می‌تواند تا وقتی SA جاری منقضی نشده یک سیاست کهنه ارائه دهد، پس یک پیکربندی درست به‌اندازه کل عمر قدیمی خراب به نظر می‌رسد و ناظر نتیجه می‌گیرد بازسازی شکست خورده، در حالی که هنوز آغاز نشده بود:

clear crypto ikev2 sa
clear crypto ipsec sa

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

انتخابگرها آینه‌ای هماهنگ می‌شوند، سپس شمارنده‌ها تصمیم می‌گیرند

فاز 2 تنها وقتی کار می‌کند که هر دو طرف بر نشانی‌های محافظت‌شده توافق داشته باشند، و توافق آینه‌ای است نه مشترک. انتخابگر محلی Google باید با انتخابگری که ASA آن را دور می‌نامد بخواند، و انتخابگر دور Google با آنچه ASA محلی می‌نامد. تونلی با 0.0.0.0/0 در یک طرف و یک شبکه فرعی در طرف دیگر فاز 1 را می‌گذراند و سپس فاز 2 را با همان خطای سرتیتر شکست می‌دهد. هیچ طرفی نمی‌تواند فهرست طرف دیگر را گسترده‌تر کند.

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

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