SSH عن بُعد عبر VPN: ما الذي لا يفعله النفق

يمنح VPN خادم SSH مساراً خاصاً ويزيل الحاجة إلى مستمع عام على المنفذ 22. وهو لا يوثّق المضيف ولا يصرّح للمستخدم ولا يقرر أي الحسابات يُسمح لها بتسجيل الدخول. يبقى ذلك من عمل SSH. وما إذا كان VPN هو الطريقة الصحيحة للوصول إلى الخادم يعتمد على ثلاثة شروط، والنفق ليس سوى أحد الإجابات الممكنة.

ما الذي يغيّره النفق وما الذي يقرره SSH بعد

يغيّر النفق إمكانية الوصول: أي العناوين يمكن الوصول إليها، ومن أين. وهو لا يغيّر ما يحدث بعد وصول اتصال TCP، حيث يعرض الخادم مفتاح المضيف ويطلب هوية المستخدم.

أبقِ الطبقتين منفصلتين في ذهنك وفي وثائقك. تسجيل الدخول إلى VPN يثبت من يجوز له استخدام الشبكة. وهو لا يقول شيئاً عن الحسابات الموجودة على الهدف، وليس إذناً بتسجيل الدخول إلى كل جهاز يمكن الوصول إليه.

أنماط الفشل منفصلة أيضاً، وهذا ما يجعل الفصل مفيداً أثناء الحادث.

ثلاثة شروط تحدد نموذج الوصول

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

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

أجب عن هذه الثلاثة فيختار النموذج نفسه. وإن تجاهلتها فستنتهي إلى تعريض SSH للعامة لتجنّب نشر العميل.

تأكد من المسار الخاص قبل لوم SSH

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

إذا لم يصل الاتصال أبداً، فتحقق من أن الخادم يستمع على الواجهة التي تتوقعها وأن جدار الحماية الخاص بالمضيف يسمح بالمصدر الذي يراه فعلاً. يمكن لـ NAT البوابة أن يعيد كتابة ذلك المصدر، لذا قد لا تتطابق أبداً قائمة سماح كُتبت لعنوان نفق العميل.

هذا عدم التطابق هو أكثر أسباب فشل SSH الشائعة التي يسبّبها المستخدم عبر VPN.

اقرأ مرحلة الفشل، لا الخطأ المدمج

ثلاث مراحل تنتج ثلاث رسائل مختلفة، وواحدة فقط منها تتعلق ببيانات الاعتماد.

استخدم الخطأ الدقيق وسجل الخادم نفسه بدلاً من إعادة تعيين بيانات اعتماد VPN وSSH معاً. فإعادة تعيين كلتيهما هي الطريقة التي تتحول بها تشخيصات خمس دقائق إلى حادث هوية يستمر يومين.

يُظهر الإخراج المطوّل المرحلة التي وصلت إليها:

ssh -vv [email protected]

حافظ على مفاتيح المضيف والتصريح سليمين

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

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

احصر الوصول إلى الخدمات في الهويات المطلوبة واحتفظ بمسار استرداد مصرّح به لتغييرات الشبكة.