بوابة SSH أم وصول VPN مباشر: أي سياسة تنطبق؟

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

افحص ما تتحكم فيه البوابة فعليًا

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

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

افحص هل يستطيع الهدف التمييز بين المسارين

لا تعمل قواعد عنوان المصدر إلا ما دام المساران يصلان بعنواني مصدر مختلفين. وبوابة VPN التي تُخفي حركة المرور إلى شبكة الخوادم الفرعية تمحو ذلك الفرق، فيظهر كل اتصال بالمنفذ 22 كأنه آتٍ من البوابة. الفحص محلي على الهدف ولا يستغرق سوى لحظة: اسرد جلسات SSH القائمة واقرأ عنوان النظير لكل منها.

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

افحص ما يحتفظ به كل سجل فعلًا

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

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

افحص أين تُفرض السياسة فعليًا

إعداد في العميل مثل ProxyJump هو طلب لا قيد. سيفتح OpenSSH بسرور اتصالًا مباشرًا عندما تكون الوجهة قابلة للوصول، لذا تصف ملفات الإعداد على الحواسيب المحمولة النيّة بينما تحدد الجدران النارية النتائج. الفرض ينتمي إلى الوجهات المسموح بها في بوابة VPN وإلى قواعد الوصول على الهدف نفسه، وكلاهما لا يستطيع المستخدم تعديله. دقّق المسارات البديلة في الوقت نفسه: واجهة ثانية، أو مستمع عام، أو طبقة شبكية متداخلة، أو نفق قديم بين المواقع، يمكن لكل منها أن يعيد الاختصار الذي أغلقته للتو.

اضبط ProxyJump على أي حال، لأنه يجعل المسار المعتمد هو السهل ويمنع العمل الروتيني من توليد استثناءات. تحقّق مما يحلّه العميل فعليًا قبل الوثوق به.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

تحقّق بمحاولة مباشرة متعمدة

السياسة التي لم تُختبر قط هي أمل. من عميل متصل بـ VPN، جرّب المسار الذي ينبغي أن يُرفض الآن، ثم جرّب المسار المعتمد، واحتفظ بالنتيجتين. المحاولة المرفوضة هي الدليل على أن التغيير قد سري مفعوله.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

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