بدأ OpenVPN دون أن يطبع شيئًا: افحص log-append أولًا

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

للصمت تفسيران مختلفان جدًا

الأول أن العملية تعمل على ما يرام وتكتب إلى ملف لا تراقبه. والثاني أنها خرجت فورًا مع خطأ مسجّل في الملف نفسه.

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

اعثر على التوجيه، ثم اعثر على العملية.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

اعثر على الوجهة التي تستخدمها العملية الجارية

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

توجيه cd الصريح يجعل هذا التمييز أوضح، لأن المسار النسبي ينتقل مع تغيير الدليل. وإن ورثت هذا الإعداد، فقد يكون الملف في مكان لا يبحث فيه أحد الآن.

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

log مقابل log-append: الدليل والمحو

log-append يضيف إلى ما هو موجود في الملف بالفعل. أما log فيفتح الملف للكتابة ويقتطعه، لذا قد يمحو التبديل بينهما التشغيل الذي كنت على وشك قراءته.

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

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

عندما يلتقط غلاف الخدمة المخرجات

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

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

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

ارفع مستوى الإسهاب فقط بعد أن تستطيع قراءته

زيادة الإسهاب قبل إيجاد الوجهة تنتج فقط نصًا أكثر في مكان لا تنظر إليه.

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

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