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 על מה לנהל משא ומתן, והיומן מראה פסק זמן במקום כשל אימות. שאלו אילו להבי גישה מרחוק מופעלים לפני שאתם מתקינים משהו אחר.

כל מגבלה כאן נמצאת בצד השער: הלהב, הרישיון, בניית הלקוח ופרופיל המסלולים. ה-CLI עובד כבר שנים. מה שנשבר הוא ההנחה שתמיכת לינוקס פירושה חבילה שבבעלותכם ובשליטתכם.