خادم أم عميل: أي وحدة OpenVPN على جهاز Pi ثنائي الدور

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

طابِق اسم الوحدة مع الدليل الذي تحمّله

يوفّر الإصدار الأعلى 2.6 وحدتي قالب، [email protected] و[email protected]. يبدأ قالب الخادم في /etc/openvpn/server ويحمّل %i.conf من هناك. يبدأ قالب العميل في /etc/openvpn/client. يمكن أن توجد نسخة باسم roaming في الموضعين معًا، كخادم وكعميل، بإعدادين غير مترابطين ولا صلة بينهما غير النص.

اسأل systemd بدلًا من نظام الملفات، لأن القائمين على الحزم يضيفون ملفات تجاوز قد تغيّر دليل العمل أو الوسائط التي يتلقاها الملف التنفيذي.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

يسرد الأمر الأول كل وحدة مُنشأة، بما فيها التي فشلت وبقيت محمّلة. يطبع الثاني ملف الوحدة مع أي تجاوز. أما الثالث فهو أسرع طريقة لرؤية الحقيقتين اللتين تحسمان السؤال: الدليل الذي تبدأ فيه العملية، ومسار الإعداد الذي أُعطي لها.

قرّر حسب اتجاه الحزم، لا حسب اسم الواجهة

تمتلك نسخة الخادم مقبس استماع وتقبل الاتصالات. نقلها المشفّر مدخل محلي ومخرج محلي على جهاز Pi، أما حركة المرور التي تمرّرها للمستخدمين فتتبع مسار التمرير وتخضع لمجموعة قواعد مختلفة. نسخة العميل لا تمتلك مستمعًا بهذا المعنى: فهي تتصل بنظير، لذا نقلها المشفّر مخرج محلي نحو الطبقة الأساسية.

هذا الاختلاف يخبرك أين تنتمي القاعدة. القاعدة التي تطابق واجهة داخل سلسلة تمرير تسمح فقط بالمرور الذي اختاره التوجيه مسبقًا؛ ولا تختار المسار أبدًا. عندما تغادر حزم مستخدم متجول عبر المسار الخاطئ، فالسلسلة التي يجب فحصها هي التمرير، لا المخرج.

انظر إلى المقابس قبل أن تنظّر. الخادم المرتبط بـ udp/1194 يُظهر مقبس استماع. والعميل يُظهر ارتباطًا بعنوان المزوّد ولا شيء يستمع إطلاقًا.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

المسار الافتراضي لنسخة واحدة قد يختطف ردود الأخرى

المسار الافتراضي الذي يدفعه عميل المصدر الأعلى، أي redirect-gateway، يثبّت مسارًا افتراضيًا ينافس كل شيء آخر على الجهاز، بما في ذلك الردود التي يرسلها الخادم إلى المستخدمين المتجولين. يستثني OpenVPN عنوان نظيره الخاص كي يبقى النفق قابلًا للوصول، لكن هذا الاستثناء لا يقول شيئًا عن هاتف على شبكة فندق.

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

اختبر القرار المحلي بدلًا من حالة النفق، لأن النواة تختار المصدر والواجهة قبل أن يرى OpenVPN الحزمة.

ip route get 203.0.113.44
ip rule show

أعد تشغيل دور واحد وأثبت أن الآخر نجا

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

دوّن شرط التوقف قبل التغيير: هل يمنع فقدان نفق المصدر الأعلى المستخدمين المتجولين، أم يعود إلى رابط Pi نفسه؟ تحتاج DNS و IPv6 إلى جواب صريح أيضًا، لأن محلّلًا مدفوعًا غالبًا ما يعيش أطول من المسار الذي جعله مفيدًا.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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