Check Point VPN على لينكس: SNX ليس حزمةً تنزّلها وتثبّتها

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

الأسطورة: عميل تنزّله وتثبّته

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

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

ما هو SNX حقًا، ومن أين يأتي

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

هذا يعني أيضًا أن البوابة يجب أن تكون جاهزة قبل أن يعني أي عمل على العميل شيئًا. يجب ترخيص Mobile Access Software Blade وتهيئته، فبدونه لا توجد بوابة يُثبَّت منها. ولا يُنتج أي قدر من الجهد على جهة العميل جلسةً مقابل بوابة لا تقدّم واحدة.

وجّه العميل إلى البوابة بمستخدمك، واقرأ ما يبلّغ عنه:

snx -s vpn.example.com -u your.name

دعم التوزيعات هو القيد، لا المُثبِّت

قائمة التوزيعات المدعومة من البائع لـ SNX قصيرة وقديمة. في المقال المنشور تتوقف عند حدود Ubuntu 17.04، إلى جانب بضعة إصدارات من openSUSE وـ Fedora وـ RHEL من الحقبة نفسها، وما زالت تذكر Ubuntu 12.10. هذا يخبرك كيف تشيخ القائمة، لا بما تحتاجه آلتك. التوزيعة الحالية ببساطة ليست عليها.

توقّع تعارضًا في المكتبات قبل أن تتوقع نفقًا يعمل. الثلاثة المعتادة هي مكتبات 32 بت الغائبة على نظام 64 بت، وإصدار من OpenSSL لم يُربط به الملف التنفيذي قطّ، ووحدة نواة يحاول العميل بناءها. اقرأ الرموز الغائبة بدلًا من التخمين في الحزم:

ldd $(command -v snx) | grep "not found"

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

تفصيل X11 الذي يجعل العمل بلا شاشة ممكنًا

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

بعد أن يتصل،اقرأ الواجهة والمسارات قبل أن تثق بأي منهما:

ip -brief addr show
ip route show

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

حين يكون SNX جوابًا خاطئًا تمامًا

تستطيع بوابات Check Point أيضًا إنهاء اتصالات IPsec وـL2TPمن العميل إلى الموقع، وهذه تعمل مع strongSwan أو Libreswan أو إضافة L2TP في NetworkManager. ذلك تهيئة بوابة، لا حيلة عميل. وإذا كانت البوابة تنشر بوابة Mobile Access وحدها،فليس أمام عميل IPsec ما يتفاوض عليه، ويُظهر السجل مهلة بدلًا من فشل مصادقة. اسأل عن أي وحدات الوصول البعيد المفعّلة قبل أن تثبّت أي شيء آخر.

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