למה לקוח ה-Linux של GlobalProtect נכשל ב-Ubuntu חדשות יותר

ההנחה הסבירה היא שקובץ ה-.deb מפורטל ה-GlobalProtect שלכם פגום, או שהספק הוציא build לקוי. בדרך כלל זה לא המצב. ממשק ה-Linux של הספק עדיין מקשר ל-Qt5 WebKit, וגרסאות Ubuntu החדשות יותר כבר לא מספקות אותו, ולכן החבילה מבקשת ספרייה שההפצה שלכם הסירה בכוונה. זו אי-התאמה באריזה, לא הורדה פגומה, וההבדל הזה קובע אם תבזבזו אחר צהריים על כפיית חבילות או עשר דקות על בחירת לקוח אחר.

קובץ ה-.deb לא פגום

תלות שההפצה כבר לא נושאת היא תוצאה רגילה של הוצאת ספרייה משירות. Qt5 WebKit הוסר מארכיוני Ubuntu מאוחרים יותר ומ-Debian, והסיבה הייתה תחזוקת אבטחה ולא חוסר ביקוש. כשזה קורה, כל חבילה שעדיין מקשרת אליו מפסיקה להיות ניתנת להתקנה, טוב ככל שנבנתה.

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

אמתו את התלות במקום לכפות אותה

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

sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5

אם apt-cache policy לא מדווח על שום מועמד, הפסיקו לנסות להתקין אותו והתחילו לבחור חלופה. המעניין אינו שם החבילה החסרה; המעניין הוא שגרף התלויות של הספק לא זז יחד עם ההפצות שהמשתמשים שלכם מריצים.

מה כפיית חבילות ישנות עושה לשולחן העבודה

העקיפה שמסתובבת היא למשוך את הספרייה מגרסה ישנה יותר. ב-Ubuntu עדכני זה מסתיים בהתנגשות גרסת משנה של Qt5: החבילות הישנות מושכות libqt5core5t64 אחורה, ואז חבילות KDE ו-PyQt המותקנות מתחילות לדרוש גרסת ABI שהספרייה שהונמכה כבר לא מספקת. התוצאה היא שדרוג חלקי ששובר יישומים לא קשורים, וזה אחר צהריים גרוע בהרבה מזה שהתחלתם בו.

התוצאה הזו צפויה ולא מזל רע. ציפיות ה-ABI של Qt לגרסאות משנה נוקשות, והפצה מספקת מערך אחד עקבי. ערבוב ספרייה אחת מגרסה אחרת אינו תיקון ממוקד; זהו שדרוג שני, פחות מבוקר.

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

openconnect מדבר את הפרוטוקול

OpenConnect מיישם ישירות את פרוטוקול GlobalProtect; הערות הפרוטוקול מתארות גם את הקריאה וגם את הפיצול בין שני ממשקי השרת. הפורטל מחלק הגדרות ואת רשימת השערים; השער מסיים את המנהרה:

openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com

אם הפורטל משמיט את השער שאתם צריכים, --usergroup=gateway או כתובת URL שמסתיימת ב-/gateway מדלגת על שלב הפורטל. כשמוצעים כמה שערים, --authgroup=NAME בוחר מביניהם. האימות הוא שם משתמש וסיסמה, ולחלופין תעודת לקוח, ושערי SAML עובדים בפועל דרך network-manager-openconnect ולא דרך שורת פקודה שהוקלדה ביד.

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

אמתו את המנהרה, ודעו מה openconnect לא יתקן

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

ip -4 addr show
ip route
resolvectl status

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

IPv6 הוא שוב עניין נפרד. PAN הוסיף אותו ב-GlobalProtect 4.0, והתמיכה של OpenConnect מתוארת כניסיונית מגרסה 9.0, ולכן אל תניחו שמשפחת הכתובות מתנהגת כמו IPv4 רק מפני שהמנהרה עלתה. ואם השער כופה בדיקת posture שהלקוח בקוד פתוח לא יכול לעמוד בה, הריצו את לקוח הספק על גרסת LTS נתמכת, במכונה וירטואלית אם תחנת העבודה שלכם כבר התקדמה. זה משאיר את שולחן העבודה שלם ושם את התלות הישנה בתוך גבול שאפשר לבנות מחדש.