Check Point VPN در لینوکس: SNX دانلودی نیست که نصبش کنید

دنبال کلاینت Check Point برای لینوکس می‌گردید و صفحه‌ای برای دانلود با نصب‌کننده پیدا نمی‌کنید. این نبود، شکاف بسته‌بندی نیست. کلاینت دسترسی از راه دور Check Point برای لینوکس همان SSL Network Extender، یعنی SNX، است و دروازه آن را پس از احراز هویت در مرورگر به شما می‌دهد. وقتی این جا بیفتد، بقیه سردرگمی معنا پیدا می‌کند، از جمله اینکه چرا تقریباً هر مطلبی درباره‌اش سال‌ها قدیمی است.

افسانه: کلاینتی هست که دانلود و نصب می‌کنید

این انتظار از هر فروشنده دیگری می‌آید. OpenVPN، WireGuard و بیشتر کلاینت‌های تجاری یک بسته یا مخزن منتشر می‌کنند و نصب آن تصمیمی محلی است که خودتان می‌گیرید. Check Point در لینوکس این‌طور کار نمی‌کند. در دانلودهای رسمی برای نسخه‌های کنونی دروازه، نصب‌کننده مستقل وجود ندارد، پس جست‌وجو برای آن فقط رشته‌های قدیمی انجمن و آینه‌های شخص ثالث را بیرون می‌آورد.

آن آینه‌ها از بی‌فایده هم بدترند، چون بیلد باید با دروازه‌ای که آن را سرو می‌کند بخواند.

SNX واقعاً چیست و از کجا می‌آید

SNX کلاینتی خط فرمان است که باینری‌اش snx نام دارد و از طریق نشستی نصب می‌شود که در مرورگر مقابل دروازه شروع می‌کنید. در گذشته یک Java applet پس از پذیرفتن اعلان، آن را دانلود و نصب می‌کرد. سازوکار در طول سال‌ها عوض شده، منبع نه. دروازه همان بیلدی را سرو می‌کند که با خودش می‌خواند، به همین دلیل نسخه‌های کلاینت و دروازه همگام‌اند و به همین دلیل کلاینتی که از بسته قدیمی کپی شده فقط تا وقتی کار می‌کند که دروازه هنوز با آن حرف می‌زند.

این یعنی دروازه باید پیش از آنکه هر کاری روی کلاینت معنا پیدا کند آماده باشد. 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 server در حال اجرا. همین تفاوت، تمام تفاوت میان کلاینتی است که روی هاست بی‌نمایشگر از طریق SSH کار می‌کند و کلاینتی که بی هیچ خروجی‌ای گیرکرده به نظر می‌رسد. بسته کتابخانه‌هایی را نصب کنید که توزیع‌تان فراهم می‌کند، نه بسته‌ای کپی‌شده از نسخه دیگر، و کلاینت را از همان نشستی اجرا کنید که تونل می‌خواهد.

پس از اتصال،پیش از اعتماد به هر یک، رابط و مسیرها را بخوانید:

ip -brief addr show
ip route show

SNX یک رابط تونل می‌سازد و مسیرهایی را نصب می‌کند که پورتال تعریف می‌کند. آن مسیرها تصمیم دروازه‌اند نه شما، پس پیشوند غایب یک مشکل پروفایل در سمت دروازه است نه باگ کلاینت. هم‌زمان DNS را هم بررسی کنید، چون پروفایل‌های split-tunnel اغلب resolver ای را هل می‌دهند که انتظارش را نداشتید.

وقتی SNX کاملاً پاسخ اشتباه است

دروازه‌های Check Point می‌توانند اتصال‌های IPsec وL2TPرا هم از کلاینت به سایت پایان دهند، و آن‌ها با strongSwan یا Libreswan یا افزونه L2TP در NetworkManager کار می‌کنند. این پیکربندی دروازه است، نه ترفند کلاینت. اگر دروازه فقط پورتال Mobile Access را منتشر می‌کند،کلاینت IPsec چیزی برای مذاکره ندارد، و لاگ به‌جای شکست احراز هویت، timeout نشان می‌دهد. پیش از نصب هر چیز دیگری بپرسید کدام bladeهای دسترسی از راه دور فعال‌اند.

هر محدودیتی اینجا سمت دروازه است: blade، لایسنس، بیلد کلاینت و پروفایل مسیرها. CLI سال‌هاست کار می‌کند. آنچه می‌شکند این فرض است که پشتیبانی لینوکس یعنی بسته‌ای که مالک و کنترل‌کننده آن شمایید.