nordvpn يقول إن الخدمة الخلفية غير قابلة للوصول: المقبس أم المجموعة أم الوحدة؟

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

ابدأ من حيث يظهر الخطأ

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

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

تحقّق من الوحدة قبل أي شيء آخر

اسأل مدير الخدمات إن كانت الخدمة الخلفية تعمل، ثم شغّلها وفعّلها في خطوة واحدة إن لم تكن كذلك:

systemctl status nordvpnd
sudo systemctl enable --now nordvpnd
nordvpn version

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

سرد ملفات الوحدات يحسم ذلك بأمر واحد، ويستحق أن تفعله قبل أن تستنتج أي شيء عن التثبيت:

systemctl list-unit-files 'nordvpn*'
service --status-all

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

المقبس ومجموعته يحددان الوصول

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

sudo usermod -aG nordvpn "$USER"
newgrp nordvpn

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

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

ls -l /run/nordvpn
id

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

العملية الخاصة بكل مستخدم في الحزم الأقدم

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

في تهيئة غير systemd تقسم الترتيبة الموثقة الأدوار: تعمل خدمة النظام باسم واحد، وتعمل العملية الخاصة بالمستخدم تحت الحساب المستهدف باستخدام chpst -u <user>. تحقّق من الترتيبة التي يستخدمها تثبيتك فعلًا قبل إضافة سكربت بدء يفترض الأخرى.

كيف تعرف أنك انتهيت

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

sudo systemctl stop nordvpnd
sudo systemctl enable --now nordvpnd
sudo systemctl start nordvpnd
nordvpn version

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

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