ipsec.conf أم swanctl.conf؟ اختر واجهة strongSwan واحدة

ملف تعريف IKEv1 عامل من دليل أقدم يصل إلى Ubuntu 24.04، وتفشل المحاولة الأولى لأن الخدمة لم تقرأ الملف قط. الاستجابة المعتادة هي تحرير ملف التعريف مرة أخرى. السؤال الحقيقي هو أي واجهة strongSwan مثبّتة وأيها تستخدمها الخدمة العاملة. وإلى أن يُجابة عن ذلك، فإن كل تحرير موجّه إلى محمّل قد لا يكون موجودًا.

ملفان، محمّلان، خدمة واحدة

ترتيب starter القديم يقرأ ipsec.conf ويسلّم الاتصالات إلى charon عبر تكامله الإداري القديم. نقطة دخوله التشغيلية هي أمر ipsec.

ترتيب swanctl يحمّل التعريفات عبر VICI، ويقرأ swanctl.conf، ويُدار بأمر swanctl. تتكامل خدمة charon الأصلية في systemd مع هذا النهج.

يمكن تثبيت الاثنين على الجهاز نفسه، وهنا يبدأ الالتباس. وجود ملف تحت /etc يثبت فقط أن أحدهم كتبه، لا أن العملية العاملة حمّلته. تثبيت كل بديل لمعرفة أيهما يعمل ينشئ مضيفًا بمسارين إداريين وبلا مالك واضح. اختر ترتيبًا واحدًا وأزل الآخر أو عطّله.

اقرأ الحزم والوحدات المثبّتة

ابدأ للقراءة فقط. أسماء الحزم على Ubuntu 24.04 منفصلة: strongswan-starter وstrongswan-swanctl وcharon-systemd. الحزمة المفقودة معلومة مفيدة، وليست تعليمًا بتثبيتها.

اجرد الحزم والوحدات في تمريرة واحدة:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

ثم افحص الوحدة النشطة وأمر تشغيلها. يخبرك اسم الوحدة أي خدمة تملك الإعداد، ويؤكد سطر الأوامر الملفات التي طُلب منها قراءتها. الوحدة الممكّنة لكن غير النشطة تحكي قصة مختلفة عن وحدة تعمل الآن.

إذا كانت الوحدة النشطة strongswan-starter، فملف ipsec.conf هو المهم. وإذا كانت charon-systemd مع swanctl، فملف ipsec.conf مجرد زينة.

استخدم مسار التحكم المطابق

لكل واجهة رؤيتها الخاصة للاتصالات والارتباطات. يعرض swanctl --list-conns التعريفات المحمّلة، ويعرض swanctl --list-sas الارتباطات النشطة. يستخدم المسار القديم ipsec statusall.

خلطها ينتج أخطاء مضللة. مقبس VICI المفقود أو طلب تحكم مرفوض مشكلة في مسار الإدارة، وليس دليلًا على أن النظير رفض المصادقة.

اقرأ العرض الذي يخص الخدمة العاملة، ثم فسّر النتيجة. إذا كان الاتصال غائبًا عن ذلك العرض، فالمشكلة في التحميل لا في التفاوض.

الصيغة ليست نسخة IKE

ملف التعريف القديم يختار IKEv1 عبر keyexchange=ikev1. اتصال swanctl يستخدم إعداد النسخة، حيث يختار 1 نسخة IKEv1. هاتان مفردتان للفكرة نفسها، وليستا تحويلًا.

عناوين النظراء والهويات المحلية والبعيدة ومصادر بيانات الاعتماد والمقترحات ومحددات الأبناء يجب أن تُعيَّن بقصد. لصق كتلة left/right في صيغة swanctl لا يفعل شيئًا من ذلك.

تغيير نسخة البروتوكول فقط هو أشهر هجرة ناقصة. ينتج ملفًا يُحمَّل ثم يفشل في المصادقة لأسباب لا علاقة لها بالنسخة. IKEv1 نفسه مهجور بموجب RFC 9395، لذا يستحق نظير قائم لا يزال يتطلبه قيد توافق موثّقًا ومسار هجرة، لا إعدادًا افتراضيًا جديدًا.

افحص المحمّل قبل لمس ملف التعريف

نفّذ فحص المحمّل أولًا، ثم حمّل الاتصال المقصود، ثم قيّم التفاوض، ثم مسار الحركة المحمية. لكل مرحلة بصمة فشل مختلفة.

مسارا التحكم يجيبان عن سؤال التحميل مباشرة:

swanctl --list-conns
ipsec statusall

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

تعامل مع ملكية الحزم وتحميل الإعداد وتوافق البروتوكول كأسئلة ثلاثة منفصلة. الملف الصالح لواجهة واحدة سيُحرَّر مرارًا وتكرارًا بينما تكون خدمة أخرى هي العاملة.