واجهة tun المُنشأة مسبقًا في OpenVPN: مقارنة نموذجي الملكية

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

الاسم ليس ارتباطًا

يطلب dev tun1 من OpenVPN تلك الواجهة المسماة، وستحاول نسخ فضاء المستخدم التقليدية فتحها. وإذا لم يتبع الاسم النمط المعتاد tun أو tap، فسيحتاج الملف التعريفي أيضًا إلى dev-type مطابق، لأن النوع لا يُستنتج أبدًا من سلسلة نصية. وجهاز TAP ليس جهاز TUN بتسمية مختلفة: فربط الجهاز الخطأ إما يفشل مباشرة أو ينتج وصلة تحمل إطارات لا يتوقعها أحد. افحص النوع قبل أي شيء آخر، لأن كل فحص لاحق يفترض أن الطرفين متفقان عليه. بعد ذلك تأكد من أن العملية قادرة فعلاً على فتح الجهاز لا مجرد رؤيته.

dev tun1
dev-type tun

واجهة الشبكة كائن مختلف عن /dev/net/tun: أحدهما وصلة داخل نطاق أسماء، والآخر هو جهاز الحرف الذي يستخدمه برنامج فضاء المستخدم للارتباط. وتشرح وثائق Linux TUN/TAP مسار الارتباط هذا وقواعد الملكية الخاصة بالأجهزة الدائمة. أما صدفة الجذر القادرة على تشغيل ip link فتثبت فقط أن للصدفة صلاحيات، لا أن للخدمة صلاحيات. ملكية عقدة الجهاز ومجموعة قدرات الخدمة والمستخدم الذي تعمل به يجب أن تتفق جميعها قبل أن ينجح الفتح.

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

من يضبط الوصلة: نموذجا الملكية

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

يغطي ifconfig-noexec العناوين فقط: فجدول التوجيه لا يُمَس، وضبط المسارات يخص route-noexec. اعتبر التوجيهين عنصرَي تحكم منفصلين بمالكين منفصلين، لأن تعيين أحدهما وافتراض الآخر مصدر شائع لوصلات نصف مضبوطة. اختر مالكًا واحدًا بالضبط لكل طبقة، العناوين في مكان واحد والمسارات في مكان واحد. ومدير شبكة ومساعد VPN يكتبان العناوين معًا هو السبب في أن قطع الاتصال يحذف حالة لا يزال الطرف الآخر يعتمد عليها.

افحص الجهاز من نطاق الأسماء المهم

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

ip -details link show dev tun1
ip tuntap show

يطبع الأمر الأول الوصلة كما تراها النواة، بما في ذلك الأعلام ونوع الواجهة، وهكذا تتأكد من أن هذا هو الجهاز المقصود. ويسرد الثاني إدخالات tun/tap الدائمة، وهي موجودة دون أن يمسكها أي عملية. والواجهة التي تنتظر مالكها المقصود حالة مختلفة عن نفق حي مرتبط بـ VPN آخر، والثانية وحدها تفسر سبب فشل ارتباطك أنت. اعثر على العملية الماسكة للجهاز قبل تغيير أي شيء، لأن الإدخال الدائم والواجهة المشغولة لهما علاجان مختلفان.

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

نوعان مختلفان من الدوام

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

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

ما ينكسر عندما يُختبر التشغيل وحده

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

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

ينبغي أن تترك إعادة الضبط اللينة الجلسة صالحة للاستخدام والموارد سليمة، وهذا هو عمل persist-tun. أما الإيقاف الكامل فهو الموضع الذي يكشف فيه المدير الخارجي عن نفسه: فإن نجا الوصلة أو عناوينه من الإيقاف، كان مالكها شخصًا آخر، وذلك إما الحالة التي وثقتها أو العلة التي وجدتها للتو. سجّل الملاحظتين بجانب الملف التعريفي، ليبدأ التغيير التالي من دليل لا من مخطط.