nordvpn می‌گوید به دیمن دسترسی ندارد: سوکت، گروه یا واحد؟

اجرای nordvpn و دریافت پیامی دربارهٔ دیمنِ در دسترس‌ناپذیر، شکایتی باریک است که معمولاً وقتی دیر رسیده‌اید می‌آید. این پیام هیچ چیزی دربارهٔ کارکردن تونل نمی‌گوید، چون CLI فقط یک بخش جلویی است: با یک فرایند پس‌زمینه از طریق سوکت یونیکس گفتگو می‌کند و پیام یعنی آن گفتگو رخ نداده است. از فرمان به سمت بیرون بروید و در نخستین چیزی که نادرست از آب درمی‌آید بایستید.

از همان‌جایی که خطا ظاهر می‌شود شروع کنید

دو فرایند درگیرند و اشتباه گرفتن آنها همان چیزی است که ماجرا را مرموز می‌کند. دیمن صاحب تونل است و روی سوکتی زیر /run/nordvpn/ گوش می‌دهد. فرمانی که تایپ کرده‌اید به همان سوکت متصل می‌شود، نه اینکه خودش به واسط‌ها دست بزند.

وقتی سوکت غایب است یا اتصال را رد می‌کند، CLI کسی را برای پرسیدن ندارد، پس گونهٔ «دیمن کاربر» یا «دیمن سیستم» از همان شکایت را گزارش می‌کند. یکی از این گونه‌ها مسیر را مستقیم نام می‌برد و آن سودمندترین جمله در کل این گفتگو است.

پیش از هر چیز واحد را بررسی کنید

از مدیر سرویس بپرسید آیا دیمن در حال اجراست، و اگر نیست آن را در یک گام راه‌اندازی و فعال کنید:

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 لازم است. در صدف تازه آزمایش کنید، نه در همانی که فرمان را اجرا کرد. وگرنه نتیجه می‌گیرید که اصلاح شکست خورده، در حالی که هنوز اعمال نشده است.

مالکیت خود سوکت نیمهٔ دوم این بررسی است. گروه روی سوکت را با گروه‌هایی که صدفِ در حال اجرای CLI گزارش می‌کند بسنجید و پرسش مجوز در یک گام پاسخ داده می‌شود، نه با نصب دوباره:

ls -l /run/nordvpn
id

فرایند زنده اثبات سوکت درست نیست. دیمنی که مدیر دیگری راه انداخته، یا بستهٔ قدیمی‌ای که سوکتی با نام دیگر را بسته، همان را گزارش می‌کنند. فهرست پوشه در یک خط این حالت‌ها را از هم جدا می‌کند و به همین دلیل از نصب دوباره بهتر است.

فرایند هر کاربر در بسته‌بندی قدیمی‌تر

بعضی بسته‌بندی‌ها فرایند دومی را در بافت کاربر واردشده اجرا می‌کنند که یکپارچگی میزکار انتظار یافتنش را دارد. اگر اسکریپت آغاز سیستم آن را بدون فرودادن به آن حساب اجرا کند، CLI دنبال دیمنی می‌گردد که هیچ نشستی مالکش نیست.

در init بدون systemd، چیدمان مستند نقش‌ها را تقسیم می‌کند: سرویس سیستم زیر یک نام اجرا می‌شود و فرایند سمت کاربر زیر حساب هدف با chpst -u <user>. پیش از افزودن اسکریپت راه‌اندازی که چیدمان دیگر را فرض می‌کند، بررسی کنید نصب شما واقعاً کدام را به کار می‌برد.

از کجا بدانید کارتان تمام است

ارتقا محرک معمول است، چون فایل دودویی تازه وضعیت سرویسی را انتظار دارد که نسخهٔ قدیمی هرگز پشت سر نگذاشت. توقف، فعال‌سازی دوباره و راه‌اندازی به همین ترتیب آن را پاک می‌کند:

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

آن فرمان آخر آزمایش پذیرش است. چاپ‌شدن شمارهٔ نسخه یعنی سوکت پاسخ می‌دهد، که هر عیب باقی‌مانده را به قلمرو ورود، طرح یا اتصال منتقل می‌کند و از این مقاله بیرون می‌برد. اگر پاسخ داد، خواندن را همین‌جا رها کنید و به‌جایش سراغ حساب بروید.

اگر سوکت هنوز غایب است، ژورنال واحد را بخوانید تا ببینید چرا خارج شد، سپس بررسی کنید /run/nordvpn وجود دارد و حساب سرویس می‌تواند آنجا بنویسد. فرایندی که بالا می‌آید و بی‌درنگ می‌میرد دلیلش را در همان ژورنال ثبت می‌کند، و خواندن یک خط از انجام یک نصب دوباره سریع‌تر است.