SNX على Linux: مكتبات 32 بت ومُحلِّل يُعاد ضبطه

يفشل SSL Network Extender من Check Point على Linux بأربع طرق يمكن تمييزها، وثلاث منها تُفهَم خطأً كمشكلة تسجيل دخول. إما ألا يبدأ الملف التنفيذي، أو يبدأ ولا يترك أي مسار، أو يتصل فتموت ترجمة الأسماء، أو تعمل بوابة المتصفح بينما لا يعمل سطر الأوامر. عالِجها بهذا الترتيب، لأن كلًّا منها شرط دخول للتالي.

العرض الأول: المُحمِّل يرفض قبل تسجيل الدخول

يضع المُثبِّت المسحوب من الجدار الناري ملفًا تنفيذيًا 32 بت ذا صلاحية setuid-root في /usr/bin/snx. على توزيعة 64 بت لا يعمل حتى تُفعَّل معمارية i386 وتوجد المكتبات التي يرتبط بها.

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

قائمة not found الفارغة هي البوابة لكل ما يأتي بعدها. تتبدل مجموعة الحزم الدقيقة بين الإصدارات: تقرير عامل احتاج libstdc++5:i386 وlibx11-6:i386 وlibpam0g:i386، وآخر احتاج أيضًا libstdc++6:i386. اقرأ ldd بدلًا من نسخ قائمة حزم من درس كُتب لتوزيعة مختلفة.

إذا لم يُعثر على snx إطلاقًا، فإن المُثبِّت لم يكتمل أو ثُبِّت في مكان خارج PATH لديك. هذا عطل مختلف، ويستحق التأكد منه قبل أن تضيف معماريات إلى النظام. تحقق باستخدام command -v snx وانظر في الدليل الذي أبلغ عنه المُثبِّت. إضافة حزم i386 إلى جهاز يكون الملف التنفيذي فيه غائبًا ببساطة لا تصلح شيئًا.

العرض الثاني: تسجيل الدخول ينجح ولا يُوجَّه شيء

تسجيل دخول ناجح ينشئ tunsnx ويعدّل جدول التوجيه بنفسه، فافحص ما هو موجود فعلًا قبل أن تغيّر أي شيء آخر.

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

استخدم snx -d للتفكيك. قتل العملية يترك الواجهة ومساراتها خلفه، ثم تفشل المحاولة التالية بسبب لا علاقة له ببيانات الاعتماد. يسجّل تسجيل الدخول الأول أيضًا توقيع خادم ضمن /etc/snx/، ولهذا قد يحتاج نص غير تفاعلي إلى تشغيل تفاعلي واحد قبل أن يعمل أصلًا. لا تحذف تلك الحالة إلا عندما تنوي إعادة اعتماد الخادم.

العرض الثالث: الأسماء تُترجم حتى يصعد النفق

هذا هو العطل الذي ينكسر بهدوء. يكتب snx خوادم DNS المدفوعة مباشرة في /etc/resolv.conf. وحيث يكون ذلك المسار رابطًا رمزيًا إلى /run/systemd/resolve/، يمكن أن يضيع التعديل عند حدث المُحلِّل التالي، وبعد قطع الاتصال يمكن أن تبقى المدخلات المدفوعة أيضًا.

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

• خذ الملف بالكامل: استبدل الرابط الرمزي بملف ثابت وثبّت libnss-resolve مع نسخته لـ i386، ليبقى لخدمة الأسماء بديل عندما يُعاد كتابة الملف من تحتك.
• أبقِ systemd-resolved مالكًا وسجّل رابط النفق: resolvectl dns tunsnx 10.0.0.10، ثم resolvectl domain tunsnx corp.example، وأكّد باستخدام resolvectl status.

سجّل خوادم الأسماء السابقة للـ VPN قبل الاتصال. إذا عدّلت الملف يدويًا، فإن إزالة المدخلات المدفوعة بعد ذلك جزء من الإجراء لا تنظيف اختياري، لأن حاسوبًا محمولًا يحتفظ بـ DNS المؤسسي بعد قطع الاتصال سيفشل في ترجمة أي شيء آخر.

العرض الرابع: البوابة تعمل وسطر الأوامر لا

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

ps ax | grep cshell
/usr/bin/cshell/launcher

سطر الأوامر مسار منفصل: snx -s vpn.example.com -u user، مع ~/.snxrc الذي يحتفظ بالخادم واسم المستخدم وتفضيل إعادة المصادقة. جلسة بوابة عاملة لا تقول شيئًا عن صحة تثبيت سطر الأوامر، والعميل المجرد لا يتعامل مع الرموز أحادية الاستخدام.

اختصار الحاوية الذي يكلّف أكثر مما يوفّر

يفحص snx وحدة tun، ويحمّلها عند غيابها، وينشئ واجهة نفق، ويعيد كتابة المسارات ويدفع حركة المرور عبرها. استنساخ ذلك داخل حاوية يعني تحميل /dev و /lib/modules و منح قدرات واسعة، وهو ما يمنح الحاوية معظم إدارة شبكة المضيف.

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