RemoteEnable ليس تسجيل دخول VPN: تحديد نطاق إدارة SoftEther
يمنح RemoteEnable إدارة عن بُعد لخدمة عميل SoftEther. وهو ليس تسجيل دخول VPN ولا تحققًا من هوية الخادم. أبقِ الثلاثة منفصلة.
يقول الدليل: شغّل RemoteEnable ثم اتصل، ويُقرأ ذلك كما لو أن الخطوتين من النوع نفسه. وهما ليستا كذلك. يمنح RemoteEnable جهازًا آخر إذنًا بإدارة خدمة عميل SoftEther VPN العاملة على هذا الحاسوب. أما الاتصال فهو حساب VPN يُصادق على خادم، ولا يتدخل فيه أي إذن إداري على الإطلاق.
الأسطورة: RemoteEnable يشغّل الـ VPN
ينشأ الالتباس من التجاور. يُفعّل دليلٌ الإدارة عن بُعد، ثم يعيد تشغيل خدمة العميل، ثم يتصل، وينجح الاتصال بعد ذلك، فتبدو الخطوتان مرتبطتين سببيًا. ما تغيّر فعليًا هو مَن يجوز له مخاطبة الخدمة، لا ما إذا كانت الخدمة تستطيع الوصول إلى خادم. عطّل الإدارة عن بُعد على عميل مُهيأ بشكل صحيح، وستظل وصلة VPN تعمل.
إن مساعدة الأوامر في المصدر الأعلى صريحة بشأن النطاق: الإدارة عن بُعد عبر VPN Client Manager أو vpncmd من خارج localhost. لا يذكر ذلك الوصف أي نفق أو حساب أو مسار. الإذن الممنوح هو وصول إداري، وموضوعه خدمة العميل لا الاتصال.
ثلاث هويات تشترك في كلمة المرور
تستخدم الأدلة القديمة كلمة واحدة لثلاثة بيانات اعتماد غير مترابطة، وهكذا تنتهي عمليات النشر بسرٍّ ملصوق في الحقل الخطأ.
كلمة مرور إدارة خدمة العميل تحمي إدارة عميل SoftEther المحلي. كلمة مرور حساب VPN تُصادق على خادم وفق سياسة ذلك الخادم. شهادة الخادم ليست كلمة مرور على الإطلاق، لكنها تجيب عن أي نقطة نهاية ينبغي للعميل أن يقبلها. تغيير واحدة منها لا يغيّر الأخريات، ونسخ قيمة بينها ينتج تهيئة مختلفة بدل تهيئة أبسط.
يستحق خيار الإدارة من بُعد فقط في كلمة مرور الإدارة نظرة ثانية، لأنه يقرر ما إذا كان شرط كلمة المرور ينطبق أيضًا على الإدارة من الجهاز المحلي. تضييق ذلك النطاق خيار متعمّد لحاسوب محمول لمستخدم واحد، وليس حلًا ملتفًا لكلمة مرور لم يسجّلها أحد.
ما يغيّره تفعيل الإدارة عن بُعد فعليًا
تتبع نتيجتان تشغيليتان، وكلتاهما يسهل إغفالهما في دليل نسخ ولصق. تصبح كلمة مرور الإدارة إلزامية بمجرد تشغيل الإدارة عن بُعد، ولا يسري التوافر الجديد إلا بعد إعادة تشغيل خدمة العميل.
إعادة التشغيل تلك انقطاع حقيقي لأي شيء يستخدم العميل، فخطّط لها مع مَن يملك الجهاز. كما أن تفعيل الميزة لا يفتح مسارًا في الجدار الناري من تلقاء نفسه: لا يزال يجب أن تكون الخدمة قابلة للوصول من محطة الإدارة، وقد يُبقي جدار ناري على المضيف أو قائمة تحكم في المنبع الخدمة غير قابلة للوصول. خدمة غير قابلة للوصول ليست دليلًا على أن الإذن حُدّد نطاقه بشكل صحيح، بل على أن شيئًا آخر يحجبه.
اكتب مسار الإدارة المقصود في ملاحظات النشر، بما في ذلك المنفذ ونطاق العناوين الذي يجوز له استخدامه. وتلك الملاحظة هي أيضًا مكان تسجيل مَن طلب القدرة ومتى ينبغي سحبها.
حدّد مَن يجوز له إدارة هذا العميل
على حاسوب محمول تملكه، أبقِ الإدارة على الطرفية المحلية ما لم تستطع تسمية الجهاز الذي يحتاج وصولًا عن بُعد وقول السبب. أما الجهاز الذي يُدار مركزيًا، فسمّ المسؤول ومسار الإدارة ومالك الاستعادة قبل تفعيل أي شيء. السؤال ليس هل الميزة مريحة، بل مَن المسؤول عن التهيئة التي تعرّضها.
نفّذ الأوامر على الخدمة المحلية كي يبقى التغيير في سجل الصدفة الخاص بك لا في لقطة شاشة: vpncmd localhost /client /cmd RemoteDisable يوقف القدرة، والأمر نفسه مع RemoteEnable يشغّلها. أعد تشغيل الخدمة بعد ذلك، وإلا فلن يكون الإعداد نافذًا.
إذا فعّلتها إرشاداتٌ كخطوة أولية بلا تفسير، فتعامل مع ذلك كسؤال معلّق لا كتعليمة تُتّبع. اسأل أي محطة إدارة يُقصد أن تستخدمها، وإن لم يكن هناك جواب فاترك القدرة معطّلة.
تحقق من وصول الإدارة والاتصال بشكل منفصل
اختباران يجيبان عن سؤالين مختلفين، وتشغيل واحد فقط منهما هو كيف ينتهي نشر بإدارة عن بُعد لم يقصدها أحد.
vpncmd localhost /client /cmd RemoteDisable
systemctl restart vpnclient
vpncmd localhost /client /cmd AccountList
vpncmd localhost /client /cmd NicList
أول سطرين يعيدان العميل إلى الإدارة المحلية ويطبّقان التغيير. والسطران الأخيران يؤكدان أن حسابات VPN والمحوّلات الافتراضية لا تزال مهيأة، وهذا ما ينبغي أن يكون، لأن نطاق الإدارة وحالة الاتصال إعدادان مستقلان. إذا رجعت قائمة الحسابات فارغة بعد إعادة التشغيل، فقد تعطّل شيء آخر، وإعداد الإدارة عن بُعد ليس التفسير.
ثم اختبر الاتصال نفسه من العميل وأكّد أن المحوّل يحمل العنوان والمسارات المتوقعة. جلسة vpncmd ناجحة تثبت علاقة تحكم ولا تقول شيئًا عن مغادرة حركة المرور عبر النفق.