ملف 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، وكل سياسة بينهما تنطبق عليها.

حدّد أولًا متطلبات البروتوكول والمصادقة لدى الخادم. ثم استخدم العميل ومسار التسجيل الذي يدعمه المشغل، وأبقِ المفاتيح الخاصة بعيدًا عن محولات الويب أثناء ذلك.