VPN اندروید به Cisco IOS: قراردادی که باید نخست بگیرید
پیش از نصب کلاینت اندروید برای دروازه Cisco IOS، پروتکل، احراز هویت، هویت و مسیریابی را جمع کنید. راهنمای اجرایی برای آن مرحله.
تلفن باید به یک دروازه Cisco برسد. کسی از قبل نام کلاینتی را که باید نصب شود گفته است. این انتهای اشتباه کار است، و به همین دلیل تونل پس از یک ساعت تایپ دوباره اعتبارنامه‌ها شکست می‌خورد.
آنچه نخست لازم دارید یک قرارداد اتصال است: پروتکل، احراز هویت، هویت، مواد اعتماد، تخصیص نشانی و مسیریابی، که کسی که دروازه را اداره می‌کند بنویسد.
آن را کتبی بگیرید و انتخاب کلاینت به یک جست‌وجو تبدیل می‌شود. نادیده بگیرید و هر شکست مانند رمز عبور اشتباه به نظر می‌رسد.
پیش از نصب هر چیزی، جمع‌آوری اطلاعات را انجام دهید
برای مالک دروازه فهرستی بفرستید و پاسخ بخواهید، نه نام محصول. نُه مورد یک نمایه دسترسی از راه دور را کامل پوشش می‌دهد:
- نام میزبان یا نشانی دروازه‌ای که کلاینت باید شماره‌گیری کند، و اینکه از بیرون قابل دسترسی است یا نه.
- پروتکل و نسخه: IKEv2، نسل دیگری از IPsec، یا سرویس مبتنی بر TLS.
- هویت همتایی که دروازه انتظار دارد، و آنچه خودش در مقابل ارائه می‌دهد.
- مواد اعتماد: کدام CA گواهی دروازه را امضا می‌کند، یا اینکه از کلید از پیش اشتراکی استفاده می‌شود.
- احراز هویت کاربر: گواهی، نام کاربری و رمز عبور EAP، یا کلید از پیش اشتراکی.
- مخزن نشانی‌هایی که کلاینت در آن قرار می‌گیرد، همراه با ماسک و دروازه.
- سرورهای DNS برای استفاده درون تونل، و اینکه کلاینت باید آن‌ها را بپذیرد یا نه.
- پیشوندهای مقصد مجاز، و اینکه ترافیک بیرون آن‌ها باید مسدود شود یا نه.
- نسخه‌های پشتیبانی‌شده کلاینت و نسخه‌های سیستم‌عامل تلفن، به‌همراه هر الزام ثبت‌نام.
دو مورد از این‌ها بیشترین شکست‌های قابل‌اجتناب را ایجاد می‌کنند. بدون مواد اعتماد نمی‌توانید دروازه را اعتبارسنجی کنید، پس کلاینت درست معیوب به نظر می‌رسد. بدون پیشوندهای مجاز نمی‌توانید محدودیت مسیریابی را از مشکل سرویس تشخیص دهید.
نام فروشنده پروتکل نیست
Cisco IOS و IOS XE چند آرایش دسترسی از راه دور ارائه می‌دهند و یک قالب انتقال مشترک ندارند. IKEv2 با نمایه‌ای به سبک FlexVPN همان سرویس پیکربندی قدیمی‌تر IKEv1 نیست، و سرویس کلاینت مبتنی بر TLS محصول دیگری است، اغلب روی سکوی دیگری در همان محیط.
پس کلاینتی که نامش فروشنده مسیریاب را ذکر می‌کند چیزی را ثابت نمی‌کند. ممکن است یکی از آن سرویس‌ها را خوب پیاده‌سازی کند و هیچ‌یک از بقیه را نه. بپرسید کدام سرویس پیکربندی شده، سپس بررسی کنید که مستندات کلاینت آن سرویس را پشتیبانی‌شده بنامد.
مستندات IKEv2 خود Cisco پیشنهاد، سیاست، نمایه و دسته‌کلید را به‌عنوان اشیای جدا از هم تفکیک می‌کند. این ساختار وقتی پیکربندی‌ای را می‌خوانید که کسی برایتان می‌چسباند مفید است: به شما می‌گوید کدام شیء تنظیمات مهم برای یک تلفن از راه دور را نگه می‌دارد، به‌جای اینکه کل فایل را یک توده در نظر بگیرد.
پشته داخلی اندروید چه چیزی را پوشش می‌دهد
اندروید نمایه IKEv2/IPsec سکو را از طریق Ikev2VpnProfile ارائه می‌دهد، با انواع احراز هویت جداگانه برای کلید از پیش اشتراکی، گواهی RSA، و نام کاربری و رمز عبور EAP. مرجع Ikev2VpnProfile مرجع آن است که سازنده چه چیزی را می‌پذیرد، از جمله نام میزبان دروازه و CA ریشه سرور که برای اعتبارسنجی آن استفاده می‌شود.
آن API بیانیه توانایی است، نه وعده سازگاری. می‌گوید سکو می‌تواند IKEv2 را با آن انواع احراز هویت انجام دهد. نمی‌گوید صفحه تنظیمات یک OEM مشخص هر فیلد را نشان می‌دهد، و نه اینکه فایل نمایه‌ای که از محصول دیگری صادر شده وارد شود.
همچنین یعنی اگر دروازه سرویسی را اجرا کند که سکو پیاده‌سازی نمی‌کند، پشته داخلی نجاتتان نمی‌دهد. در آن صورت به کلاینت فروشنده‌ای نیاز دارید که اپراتور پشتیبانی می‌کند، نصب‌شده و پیکربندی‌شده همان‌طور که اپراتور مستند کرده، نه راه‌حل میان‌بری که بر پروتکلی ساخته شده که تلفن آن را صحبت نمی‌کند.
به ترتیبی که قرارداد نوشته شده آزمایش کنید
هر بار یک لایه را اعتبارسنجی کنید و در نخستین شکست متوقف شوید، چون آزمون‌های بعدی تا وقتی قبلی‌ها قبول نشوند بی‌معنا هستند.
اعتماد. اگر کلاینت گواهی دروازه را رد کند، چیز دیگری مهم نیست. تأیید کنید CA که به شما داده شده گواهی‌ای را که دروازه ارائه می‌دهد امضا می‌کند، و نام میزبانی که شماره‌گیری کردید در آن آمده است. اعتبارسنجی را روشن نگه دارید؛ خاموش کردنش یک مشکل هویت را به خطر شنود تبدیل می‌کند.
احراز هویت. اعتبارنامه ردشده و پیشنهاد ناهمخوان خطاهای متفاوت اما شکست‌های شبیه تولید می‌کنند. گزارش دروازه داور است: پیش از آنکه چیزی درباره کاربر بگوید، می‌گوید آیا پیشنهاد پذیرفتنی بود.
نشانی و DNS. تأیید کنید تلفن نشانی‌ای از مخزن مستند دریافت کرده، سپس یک نام داخلی را resolve کنید. تونلی که با نشانی و بدون resolver بالا می‌آید متصل به نظر می‌رسد و طوری رفتار می‌کند که گویی هیچ چیز کار نمی‌کند.
دسترسی‌پذیری. یک مقصد مجاز را با نشانی و سپس با نام آزمایش کنید. اگر نشانی کار کرد و نام نکرد، دوباره به DNS برگشته‌اید. اگر هیچ‌کدام کار نکرد، پیشوندی که آزمایش می‌کنید را پیش از دست زدن به کلاینت با فهرست مجاز مقایسه کنید.
حالت‌های شکست و بازگردانی
| Symptom | Contract item to re-check |
|---|---|
| Profile rejected at import | Protocol or client release unsupported for that service |
| No proposal chosen | IKE version or encryption proposal mismatch |
| Certificate error, correct credentials | Trust material or peer identity |
| Tunnel up, no address | Address pool or authorization on the gateway |
| Tunnel up, names fail | DNS servers or split-tunnel DNS behaviour |
نمایه کاری قبلی را پیش از تغییر هر چیزی صادرشده و مستند نگه دارید، از جمله نام مستعار CA و مخزن نشانی. آن‌گاه بازگردانی یعنی بازگرداندن یک نمایه شناخته‌شده، نه بازسازی آن از حافظه در میانه یک قطعی.
وقتی کار کرد، نُه پاسخ جمع‌آوری را کنار نمایه ثبت کنید. تلفن بعدی، به‌روزرسانی بعدی سیستم‌عامل و تغییر بعدی دروازه همه به مقایسه با یک سند تبدیل می‌شوند، نه یک بعدازظهر دیگر حدس و گمان.