شبكة VPN الخاصة بك لا تعمل إلا بعد تسجيل الدخول بسبب حلقة المفاتيح

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

لماذا يجعل تسجيل الدخول الأمر يعمل

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

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

حدد أي مالك يبدأ النفق

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

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

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

ضع السر حيث تستطيع الخدمة قراءته

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

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

اختبر الحدث الذي يحدث فعلاً

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

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

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

تحقق من المسارات و DNS، لا من الواجهة فقط

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

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

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