OpenVPN یا IKEv2: چهار بررسی پیش از انتخاب پروتکل

انتخاب بین OpenVPN و IKEv2 معمولاً به‌عنوان پرسشی در مورد پروتکل بحث می‌شود و این قالب‌بندی تصمیم را هدر می‌دهد. چیزی که آن را تعیین می‌کند این است که آیا سرور و دستگاه‌های شما همان پروفایل کامل را پشتیبانی می‌کنند و آیا آن پروفایل در برابر شیوه جابه‌جایی شما بین شبکه‌ها دوام می‌آورد. دو پشته به یکدیگر ترجمه نمی‌شوند: فایل OVPN یک پروفایل IKEv2 با نحو متفاوت نیست. چهار بررسی که به ترتیب انجام شوند، به این پرسش سریع‌تر از هر جدول ویژگی پاسخ می‌دهند.

نبودن کلاینت بحث را پایان می‌دهد

ویندوز و macOS یک کلاینت IKEv2 همراه دارند، بنابراین پروفایل IKEv2 در آنجا هزینه اضافی برای استقرار ندارد و گزینه‌های تأمینی را که سیستم‌عامل از قبل ارائه می‌دهد به ارث می‌برد. OpenVPN روی همان ماشین‌ها یعنی کلاینتی از شخص ثالث که باید نصب، به‌روزرسانی و پشتیبانی شود، و آن کلاینت باید هر گزینه‌ای را که پروفایل استفاده می‌کند بپذیرد. پیش از مقایسه هر چیز دیگری، پلتفرم‌هایی را که باید پوشش دهید بشمارید، زیرا پلتفرمی بدون کلاینت کارآمد اصلاً نقطه مقایسه نیست.

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

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

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

تحرک یک تنظیم مشترک است، نه وعده پروتکل

IKEv2 می‌تواند از MOBIKE استفاده کند وقتی هر دو طرف آن را پشتیبانی و فعال کنند، که به کلاینت اجازه می‌دهد تونل خود را در حالی که نشانی‌اش تغییر می‌کند حفظ کند. RFC 4555 این افزونه را تعریف می‌کند و عبارت شرطی مهم است: سروری که این قابلیت را نادیده بگیرد در عوض دوباره مذاکره می‌کند. نتیجه در انتقال فایل می‌تواند یکسان به نظر برسد و در یک تماس زنده بسیار متفاوت.

گذار مورد نظر خود را با چیزی در حال اجرا که می‌توانید ببینید آزمایش کنید. بگذارید ping -t <internal-host> در ویندوز ادامه یابد، یا ping ساده در جای دیگر، سپس از Wi-Fi به شبکه موبایل بروید و شکاف‌ها را ببینید. شکست MOBIKE در گزارش کلاینت به‌صورت احراز هویت مجدد کامل دیده می‌شود، نه به‌صورت به‌روزرسانی آرام نشانی. آنچه می‌سنجید این است که آیا تونل از تغییر جان سالم به در می‌برد، نه اینکه پروتکل پشتیبانی را اعلام می‌کند.

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

اعتبارنامه‌ها به سرویس تعلق دارند، نه به پشته

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

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

openssl x509 -in client.crt -noout -subject -issuer -dates

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

بررسی کنید تونل واقعاً چه چیزی را مسیریابی می‌کند

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

دو فرمان در ویندوز مسیر و جست‌وجوی نام را پوشش می‌دهند. معادل‌های لینوکس عبارت‌اند از ip route show default و resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

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

پس از بررسی‌ها نگهداری را بسنجید

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

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