لماذا تُعطّل قاعدة منفذ المصدر أحد مسارات SSH لديك

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

مدخلان، ومنفذ خدمة واحد

يحمل المضيف عنوانًا من جهة LAN وعنوان VPN، ويستمع sshd على كليهما. لذلك تتشارك الجلسة المباشرة والجلسة النفقية منفذ الخدمة، ولا تختلفان إلا في العنوان المحلي الذي يستقبل الاتصال.

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

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

اقرأ القاعدة، ثم اقرأ الجدول

قاعدة السياسة محدِّد مرتّب، وأول قاعدة تعيد إجابة صالحة تنهي البحث. اقرأ القائمة بالترتيب ولاحظ أي قاعدة يمكن أن تفوز.

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

ip -4 rule show
ip route show table 100
ip route show table main

هذان المخرَجان معًا يفسّران النتيجة؛ وأي منهما وحده يدعو إلى استنتاج خاطئ.

احصر القاعدة في المسار الذي تقصده

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

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

إذا تُرجم المدخلان إلى عنوان محلي واحد، يختفي ذلك التمييز ويحتاج التصميم إلى حالة واعية بالاتصال بدلًا من ذلك.

افصل المستمع والإذن واختيار الاستجابة

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

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

أبقِ قناة استرداد لا تعتمد على المسار الذي تغيّره، لأن خطأً هنا يمنع الإصلاح نفسه.

أثبته بجلسة جديدة، لا بجلسة قديمة

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

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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