NetworkManager-ssh يعرض الاتصال لكن لا شيء يُوجَّه
المؤشر يثبت فقط وجود علاقة SSH المُدارة. تحقّق مما إذا كان الملحق قد بنى جهاز نفق أو مجموعة تحويلات، ثم اختبر مسار التطبيق.
تعرض القائمة اتصال SSH كأنه نشط، وقد قُبِل مفتاح المضيف، ومع ذلك لا يصل المتصفح إلى أي شيء كان يُفترض أن يصل إليه. هذا ليس تناقضًا، لأن ملف NetworkManager-ssh يمكن أن ينتج نتيجتين مختلفتين تمامًا من المضيف والمفتاح نفسهما: جهاز نفق يحمل الحزم، أو مجموعة تحويلات لا يمكن إلا لتطبيقات معيّنة استخدامها. يبلّغ المؤشر بوجود علاقة SSH المُدارة. وهو لا يبلّغ أبدًا أيّ النتيجتين حصلت عليه.
نتيجتان خلف إدخال واحد في القائمة
الوضعان يوثّقان بالطريقة نفسها، ولهذا تحديدًا يختلط أحدهما بالآخر. اختيار الملف بالطريقة نفسها حرفًا بحرف، وببيانات الاعتماد نفسها، قد يتركك بواجهة يمكنك التوجيه عبرها أو بمقبس استماع يجب إبلاغ تطبيق واحد به.
ابدأ بتحديد النتيجة التي تحتاجها المهمة فعلًا. متطلب الوصول إلى شبكة فرعية كاملة يحتاج جهازًا. وخدمة واحدة على مضيف بعيد تحتاج تحويلًا، وبناء نفق لها عادةً يخلق عمل توجيه أكثر مما استحقته المشكلة.
ما يجب أن يتوفر في كل وضع قبل أن يعمل
يوثّق المشروع الوضعين، والمتطلبات المسبقة تختلف بما يكفي ليبدو المتطلب الناقص فشلًا في البروتوكول بدلًا من خيار تصميمي.
| Mode | What must exist | What still has to be true |
|---|---|---|
| Tunnel device | Compatible TUN/TAP arrangement on both ends, permission, addressing | A route policy that actually sends the intended prefixes into it |
| Forwarding only | A chosen SOCKS, local-forward or remote-forward listener | A permitted destination path on the far side |
اقرأ العمود الأيمن بعناية، لأنه حيث تنتهي معظم هذه التذاكر. فحتى جهاز النفق المبني بإتقان لا يغطي إلا ما يرسله التوجيه إليه، وحتى التحويل المثالي لا يساعد إلا التطبيقات التي أُبلِغت باستخدامه.
الواجهة الوهمية ليست نفقًا
في وضع التحويل يوثّق الملحق واجهة وهمية تُنشأ لتلبية نموذج الاتصال. وهي موجودة ليكون للمدير شيء يربط به الحالة. وهي لا تحمل حزم تطبيقات عشوائية إلى الشبكة البعيدة، ولا شيء في وجودها يعني أن توجيه IP قد تغيّر.
أمثلة النفق الكامل في المشروع تتعلق بدعم جهاز نفق OpenSSH، فكلمة نفق في أي تسمية تصف قدرة، لا سياستك الفعلية. تحقّق مما سيفعله النواة بدلًا من الاسم الذي يحمله الملف.
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"
ثم طابق النتيجة مع التطبيق. البرنامج الذي يفهم SOCKS يجب تهيئته لاستخدام الوسيط. ومستهلك التحويل المحلي يجب توجيهه إلى مقبس استماعه. لا أحدهما يكتشف التحويل من تلقاء نفسه، ولا أحدهما يساعده مؤشر اتصال أصبح أخضر.
جهّز الجانب البعيد بدلًا من فرضه
يمكن لحساب SSH عادي أن يوثّق دون أي إذن لإنشاء جهاز نفق بعيد. ويوثّق المشروع مسارًا بلا صلاحيات جذر يقوم فيه مسؤول بإنشاء الجهاز مسبقًا لذلك المستخدم، ثم يختار العميل الرقم المطابق.
يتطلب هذا الترتيب تنسيقًا مع سياسة النفق في الخادم ومع من يملك العنونة على الشبكة البعيدة. إنشاء الجهاز لا يمنح بحد ذاته مسارات الموارد ولا أذونات التحويل ولا مسار عودة، ولا شيء من ذلك يأتي لأن إعداد المثال بدا مقنعًا.
ما لا ينبغي فعله هو تمكين تحويل غير مقيّد أو تسجيل دخول جذر عن بُعد لجعل مثال يعمل. وحيث يملك المشغّل إعداد الشبكة البعيدة، استخدم الترتيب المدعوم لترك تلك الأوامر لذلك المالك، وتجنّب مساعدًا ثانيًا يعيد فرض عناوين متعارضة عند قطع الاتصال.
سياق التوثيق، وما يجب وضعه في التذكرة
للتوثيق سياقه الخاص. يبحث الملحق عن وكيل SSH مرتبط بجلسة المستخدم ويشترط أن يكون مضيف الوجهة معروفًا، فمفتاح يعمل في طرفية واحدة لا يصبح تلقائيًا مرئيًا لمسار توثيق المدير. اجعل مفتاح المضيف مسجّلًا ومُتحقَّقًا منه عبر العملية المعتمدة بدلًا من إطفاء التحقق.
للدعم، سجّل أربعة أمور: الملحق وإصداره، والوضع المختار، والهوية البعيدة المقصودة، والواجهة أو مقبس الاستماع الذي كان يجب أن يظهر. ثم اختبر نقطة دخول التطبيق مباشرة. مؤشر متصل مع اختبار ناجح دليل؛ أما مؤشر متصل وحده فهو عبارة عن SSH، لا عن التوجيه أو إذن المورد الذي كنت تحاول الحصول عليه.