SNX בלינוקס: ספריות 32 סיביות ומפענח שמתאפס

SSL Network Extender של Check Point נכשל בלינוקס בארבע דרכים מזוהות, ושלוש מהן נקראות בטעות כבעיית התחברות. או שהבינארי לא עולה, או שהוא עולה ולא משאיר נתיב, או שהוא מתחבר ופתרון השמות מת, או שפורטל הדפדפן עובד בעוד שורת הפקודה לא. עברו עליהם בסדר הזה, כי כל אחד הוא תנאי הכניסה לבא אחריו.

סימפטום ראשון: הטוען מסרב לפני ההתחברות

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

סימפטום רביעי: הפורטל עובד וה-CLI לא

גרסאות חומת אש אחרונות העבירו את תוכנת הביניים מהדפדפן לדמון Java מקומי, כך שהפורטל מדבר עם סוכן מקומי בפורט 14186. הכתובת הזו צריכה חריגת תעודה בדפדפן ותהליך פועל.

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

שורת הפקודה היא נתיב נפרד: snx -s vpn.example.com -u user, כאשר ~/.snxrc מחזיק את השרת, שם המשתמש והעדפת האימות מחדש. הפעלת פורטל עובדת לא אומרת דבר על כך שה-CLI מותקן כראוי, והלקוח החשוף לא מטפל בקודים חד-פעמיים.

קיצור הדרך עם המכולה שעולה יותר ממה שהוא חוסך

snx בודק את מודול tun, טוען אותו כשהוא חסר, יוצר ממשק מנהרה, כותב מחדש נתיבים ודוחף דרכו תעבורה. שחזור זה בתוך מכולה פירושו לעגן את /dev ואת /lib/modules ו-להעניק יכולות רחבות, מה שמעביר למכולה את רוב ניהול הרשת של המארח.

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