حافظ على SSH المحلي عندما يستخدم المضيف شبكة VPN صادرة

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

تفترض الخطوات أدناه أن المسؤول موجود على الشبكة المحلية نفسها.الإدارة عن بُعد مسألة مختلفة بإجابة مختلفة.

اربط SSH بالعنوان الذي يستخدمه المسؤولون

ابدأ من المستمع.ss -ltnp | grep :22 يوضّح ما يرتبط به sshd، والمستمع على 0.0.0.0 يقبل الاتصالات من كل واجهة، بما في ذلك النفق. الربط بعنوان الشبكة المحلية أضيق ويجعل النية ظاهرة:ListenAddress 192.168.10.20 في sshd_config، يتبعه اختبار للإعداد ثم إعادة تحميل. الخطأ المطبعي في ذلك العنوان أظهر من حرف بدل، لأن sshd يرفض البدء عندما لا يكون العنوان موجودًا.

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

أبقِ مسار الشبكة المحلية خارج النفق

المضيف الذي يحمل عنوانًا على 192.168.10.0/24 لديه مسار متصل لتلك البادئة، والمسار الأكثر تحديدًا يتفوق على المسار الافتراضي لـ VPN داخل الجدول نفسه. لهذا السبب غالبًا ما يستمر SSH المحلي في العمل من تلقاء نفسه عندما يرتفع النفق. تحقق من ذلك بدلًا من افتراضه:ip route get 192.168.10.50 يسمّي الواجهة وعنوان المصدر الذي سيستخدمه النواة، ويجب أن تكون الإجابة جهاز الشبكة المحلية لا النفق. أعد الفحص من جهاز المسؤول أيضًا، لأن جدوله الخاص هو ما يقرر وصول الحزم أصلًا. يمكن لمضيفين على السلك نفسه أن يختلفا حول الاتجاه القابل للوصول.

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

شبكات VLAN الإدارية الموجّهة هي الحالة الأخرى. إذا كان المسؤول على 192.168.50.0/24 خلف الموجّه المحلي، فيحتاج الخادم إلى مسار صريح لتلك البادئة عبر 192.168.10.1، ويجب أن يصمد ذلك المسار أمام إعادة الاتصال. أبقِ الاستثناء خاصًا ببادئة الإدارة؛ فالاستثناء الواسع لنطاقات العناوين الخاصة يبطل الغرض من النفق.

اجعل استثناء الجدار الناري بقدر ضيق القاعدة

إذا كان المضيف يشغّل جدارًا ناريًا، فاسمح بـ SSH من مصدر الإدارة فقط، وعلى واجهة الشبكة المحلية فقط. القاعدة التي تسمح بالمنفذ 22 من أي مكان أوسع من المطلب وأصعب تبريرًا في المراجعة. على مضيف nftables تنتمي القاعدة إلى سلسلة الإدخال مع مطابقة الواجهة والمصدر؛ وعلى مضيف iptables المكافئ هو زوج من المطابقات على -i و -s. علّق على القاعدة بمجموعة المسؤولين التي تخدمها، حتى لا يضطر التدقيق التالي إلى التخمين لماذا المنفذ 22 مفتوح.

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

اختبر الحالتين

نفّذ الاختبار مرتين: مرة والنفق متصل، ومرة وهو غير متصل. في كل حالة، تأكد من المستمع والمسار وتسجيل دخول SSH فعلي من جهاز المسؤول. المسار الذي يعمل فقط أثناء اتصال النفق ليس مسار إدارة محليًا؛ إنه صدفة.

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

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

اكتب مسار الاسترداد في دليل التشغيل

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

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