النفق الكامل في strongSwan يحتاج 0.0.0.0/0 على الطرفين

اتصال strongSwan يعمل مع شبكة فرعية خاصة واحدة لن ينقل حركة الإنترنت لمجرد أن أحدهم عدّل سطرًا واحدًا. النفق الكامل اتفاق بين طرفين على العناوين التي يحميها child SA، وكل طرف يسمّي الطرف الآخر نسبةً إلى نفسه. اضبط أحد الجانبين وأخطئ في الآخر، فإما لا يصعد child SA أو يصعد أضيق من المقصود. الفحوص الخمسة أدناه تتبع ذلك الاتفاق من العميل، عبر البوابة، وإلى الإنترنت.

افحص محدد العميل أولًا

يصف العميل ما يريد حمايته على الجانب البعيد بقيمة remote_ts، وكل ما يرسله ينطلق من عنوانه المعيّن له. بالنسبة لحركة الإنترنت يجب أن تغطي تلك القيمة الوجهات التي سيصل إليها المستخدم فعليًا، وهذا يعني عمليًا كامل فضاء IPv4. العميل الذي ما زال يدرج شبكة فرعية واحدة يطلب نفقًا منقسمًا، مهما كان اسم الملف التعريفي في الواجهة. عادةً يكون جانب المصدر dynamic لأن العنوان يُعيَّن عند الاتصال. المصدر الثابت المكتوب هناك ينكسر بمجرد أن تتغير مجموعة العناوين.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

المقتطف ليس ملف اتصال كاملًا، وهذا الملف يفترض أن المصادقة والهويات ومجموعة العناوين الافتراضية مهيأة مسبقًا. لا يزال على محدد المصدر لدى العميل والعنوان الذي يخصصه الخادم أن يتفقا، وإلا صعد child SA بنطاق لم يتوقعه أي من الطرفين. حمّله بـ swanctl --load-all واقرأ المخرجات قبل أن تفترض النجاح. الملف الذي يُحلَّل بنجاح قد يُرفض مع ذلك بسبب محدد لا يتقاطع مع اقتراح الطرف الآخر.

افحص محدد البوابة على جانبها هي

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

يستخدم ipsec.conf القديم دوري اليسار واليمين بمفاتيح مختلفة، وسطر rightsubnet ليس بديلًا مباشرًا لقيمة swanctl. احتفظ بالصيغتين في ملفين منفصلين بدلًا من لصق إحداهما في الأخرى. خلطهما في دليل واحد هو الطريق الذي يعود به اتصال عامل إلى حالته السابقة بهدوء بعد إعادة التشغيل.

افحص child SA المتفاوض عليه، لا الملف

الإعداد المحفوظ يثبت النية ولا شيء أكثر. يمكن للطرف الآخر أن يضيّق ما طُلب، وchild SA القائم لا يُستبدل لمجرد أن الملف تغيّر تحته. أكّد ما هو مثبَّت فعليًا قبل أن تغيّر أي شيء آخر.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

الأمر الأول يُظهر ما حمّله البرنامج الخفي، والثاني يُظهر جلسات child SA القائمة، والثالث يُظهر السياسات التي سيطبّقها النواة. إذا قال الملف 0.0.0.0/0 وأظهرت القائمة شبكة فرعية واحدة، فقد ضيّقت المفاوضات النطاق، وإعادة قراءة الملف لن تفسّر ذلك. أنهِ child وأعد بدءه وقارن المخرجات الثلاثة مرة أخرى. child يعود بالنطاق الضيق نفسه يكون قد ضُيّق من الطرف البعيد لا من الملف المحلي، وذلك حوار مع المسؤول الآخر وليس تعديلًا محليًا.

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

افحص التمرير ومسار العودة

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

افحص ما لا يغطيه النفق بعد

زوج المحددات يغطي IPv4 ولا شيء غيره. IPv6 وDNS وأي سياسة على مستوى التطبيق قرارات منفصلة يتجاهلها محدد IPv4 الواسع بصمت. النفق الذي يحمل كل حزمة IPv4 يمكنه مع ذلك تسريب كل بحث عن اسم.

صرّح بمسار DNS المقصود، لأن النفق الكامل الذي ما زال يحل الأسماء عبر الموزّع المحلي يسرّب الاستعلامات خارج النفق ويكسر الأسماء الخاصة. إذا مُنح العميل عنوان IPv6، فتحتاج عائلة العناوين تلك المعالجة نفسها، وإلا فضّل المضيف مسارًا لا يحميه النفق. اختبر باسم لا يستطيع الإجابة عنه إلا الجانب الخاص، واعتبر أي إجابة عامة تسريبًا.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

أكّد السلسلة بهذين الأمرين إضافة إلى المحددات المتفاوض عليها من القائمة أعلاه. إذا أظهر traceroute أن الموجّه المحلي هو القفزة الأولى، فالحركة لا تستخدم النفق مهما ادّعت المحددات. يكون الوصول إلى الإنترنت كاملًا فقط عندما تُقبل الحركة المختارة وتُمرَّر وتعود عبر البوابة المصممة. العثور على 0.0.0.0/0 في ملف تعريف هو بداية تلك السلسلة لا دليل عليها.