عميل SoftEther عند الإقلاع: AccountStartupSet وترتيب خدمة الخلفية
قد يبدأ العميل بلا أخطاء ويترك كل حساب غير متصل. اضبط علامة الحساب، وابدأ خدمة الخلفية أولًا، ثم افحص المحوّل والمسار.
إعادة تشغيل الجهاز تتركه على الشبكة مع تعطّل النفق مجددًا. يحتفظ عميل SoftEther بجزئين من الحالة يعتبرهما معظم الناس شيئًا واحدًا: هل الخدمة تعمل، وهل يُسمح لحساب محفوظ بالنهوض معها. يجب أن يكون الاثنان صحيحين، والثاني علامة على مستوى الحساب لا إعداد إقلاع. نفّذ الفحوص الأربعة أدناه بالترتيب وتوقّف عند أول فشل.
تأكّد من أن الحساب مُعلَّم للبدء التلقائي
تعيش العلامة في سجل الحساب داخل إعدادات العميل نفسه، لذا فإن إعادة تثبيت العميل أو استعادة دليل فارغ يمحوها. افتح وحدة التحكم الإدارية وانظر إلى قائمة الحسابات قبل تغيير أي شيء آخر.
cd /opt/softether/vpnclient
./vpncmd
اختر 2 لإدارة عميل VPN واقبل الخادم المحلي بالضغط على Enter.
AccountStartupSet
office-hub
exit
يسجّل AccountStartupSet الحساب كحساب يجب إحضاره عند بدء خدمة العميل. وهو لا يشغّل الخدمة ولا ينشئ حسابًا جديدًا، ولا يطبع أي شيء مفيد عندما يكون الاسم خاطئًا. اقرأ قائمة الحسابات مرة أخرى بعد الأمر، لأن الخطأ المطبعي صامت ويبدو تمامًا كعلامة لم تدخل حيز التنفيذ.
تأكّد من أن الخدمة تبدأ، وفي وقت مبكر بما يكفي
على Linux يعمل العميل كخدمة خلفية من دليله الخاص، ويجب أن يكون قائمًا قبل أن تحاول أي خطوة إقلاع استخدام الحساب. خطّاف قصير يغيّر الدليل ويشغّله يكفي في الأنظمة التي ما زالت تستخدم rc.local.
cd /opt/softether/vpnclient
./vpnclient start
حيث لم يبقَ rc.local، اكتب وحدة systemd مع WorkingDirectory صريح وسياسة إعادة تشغيل. تحدّد الملف التنفيذي إعداده نسبةً إلى المكان الذي يبدأ منه، لذا فإن وحدة بلا ذلك الإعداد قد تبدأ بنجاح وتقرأ لا شيء. الترتيب هو النصف الثاني من المشكلة: محاولة اتصال تعمل قبل أن تبدأ الخدمة الخلفية بالاستماع تفشل على نحو متقطّع، وهو أصعب بكثير في التشخيص من فشل ثابت. وتغطي سياسة إعادة التشغيل الحالة الثالثة، حيث تموت الخدمة الخلفية بهدوء بعد ساعات.
افحص قائمة العمليات بدلًا من الوثوق بملف pid خلّفه الإقلاع السابق.
تأكّد من أن المحوّل حصل على عنوان
بمجرد أن يتصل الحساب، يعرض العميل محوّلًا افتراضيًا ولا يزال المحوّل بحاجة إلى عنوان. غالبًا ما يجيب مركز يشغّل SecureNAT على DHCP؛ المركز المربوط إلى شبكة LAN فعلية يتوقع أن يجيب خادم تلك الشبكة بدلًا من ذلك.
ip -brief address
dhclient vpn_vpn1
خذ اسم الواجهة من القائمة، لأن الرقم في المثال ليس ثابتًا. إذا وجب أن يكون العنوان ثابتًا، ضعه في إعداد الشبكة لدى التوزيعة لتلك الواجهة بحيث يُعاد تطبيقه بعد حدث ربط ولا يكون مقتصرًا على الإقلاع. السكربت ذو التشغيل الواحد يترك المحوّل بلا عنوان في المرة الأولى التي يتصل فيها النفق من جديد خلال اليوم. ويبدو ذلك الفشل كنفق ميت رغم أن الحساب سليم.
المحوّل بلا عنوان هو أهدأ فشل في القائمة، لأن الحساب ما زال يبلّغ بأنه متصل.
تأكّد من أن المسار يشير إلى حيث تظن
قد تفشل حركة المرور رغم رابط سليم وعنوان صالح. اسأل النواة عن الواجهة التي ستستخدمها لوجهة داخل شبكة المركز الفرعية، ثم قارن تلك الإجابة بالنفق.
ip route get 10.10.20.15
الشبكة الفرعية المحلية المتداخلة مع نطاق المركز هي التي تفوز، لأن مسارها أكثر تحديدًا ومثبّت مسبقًا.
هذا قرار ترقيم لا خلل في العميل، وإعادة تشغيل الخدمة لن تغيّره. إعداد الممحّل هو النصف الآخر: عنوان بلا خادم DNS عامل ينتج نفقًا يجتاز كل فحص للرابط وما زال لا يستطيع فتح اسم.
اكتب الفحوص الأربعة في ملاحظات إعادة البناء
سجّل اسم الحساب وأمر بدء الخدمة واسم الواجهة معًا، لأن المضيف المعاد بناؤه يستعيد بيانات الحساب لكن ليس خطّاف نظام التشغيل الذي يطلق الخدمة الخلفية. تلك الأشياء تعيش في أماكن مختلفة ويُنسخ احتياطيًا لها عادةً أشخاص مختلفون.
العلامة سطر واحد لإعادة تطبيقه ويسهل نسيانه.
احتفظ بالترتيب: العلامة، الخدمة، العنوان، المسار. قائمة التحقق التي تبدأ من المنتصف تنتج كثيرًا من الإجابات الخاطئة الواثقة.