پروفایل WireGuard برای دروازه IPsec: در عوض چه چیزی را بخواهیم

وقفه‌های دست‌دادن با دروازه‌ای خاموش معمولاً به معنای دو پروتکلی است که هرگز به هم نمی‌رسند. همتا WireGuard به Noise سخن می‌گوید، در حالی که دروازه IPsec منتظر IKE است. نشانی و درگاه درست این را تغییر نمی‌دهد.

استفاده دوباره از نقطه پایانی در یک پروفایل این دو را به هم پل نمی‌زند. گام بعدی درخواستی از کسی است که دروازه را اداره می‌کند.

درخواست یکم: نسخه پروتکل

IPsec یک خانواده را نام می‌برد، نه یک گردش‌کار واحد. IKEv2 و IKEv1 در تبادل‌ها، گزینه‌های احراز هویت و رفتارشان هنگام تغییر شبکه متفاوت‌اند. دروازه‌ای که فقط IKEv1 را پایان می‌دهد رفتار کاملاً متفاوتی با دروازه‌ای خواهد داشت که IKEv2 ارائه می‌کند. پیکربندی کارخواه هم با آن تغییر می‌کند.

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

درخواست دوم: روش احراز هویت کارخواه

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

کلید خصوصی WireGuard هیچ‌یک از این‌ها نیست. کلیدی Curve25519 است که در یک دست‌دادن مشخص به کار می‌رود. هیچ تبدیلی آن را به گواهی یا اعتبارنامه EAP تبدیل نمی‌کند. ابزاری که خلاف این را ادعا کند، فایل را تغییر نام می‌دهد یا چیزی نامرتبط تولید می‌کند.

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

درخواست سوم: هویت مورد اعتماد و مقصدها

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

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

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

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

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

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

اداره هر دو شبکه دلیل موجهی برای نگه‌داشتن هر دو پروتکل است. طراحی معمول WireGuard و IPsec را روی واسط‌های جدا یا دروازه‌های جدا پایان می‌دهد. ترافیک تأییدشده سپس میان آن‌ها مسیریابی می‌شود.

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

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

نخست الزامات پروتکل و احراز هویت سرور را روشن کنید. سپس کارخواه و مسیر ثبت‌نامی را که اپراتور پشتیبانی می‌کند به کار ببرید و در این میان کلیدهای خصوصی را از تبدیل‌کننده‌های وب دور نگه دارید.