בנייה ל-ARM אינה תמיכת FortiClient ב-Raspberry Pi שלך

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

צעד ראשון: קרא את שורת הערות השחרור של החבילה המדויקת שלך

הצהרות תמיכה כבולות לגרסה, לכן התחל בהערות השחרור של החבילה שהארגון שלך מאשר. כדוגמה קונקרטית, הטבלה של FortiClient Standalone 7.4.7 מפרטת את Ubuntu 22.04 ו-24.04, Red Hat 9 ו-CentOS Stream 9 עם GNOME. דרישת המעבד ל-Linux מנוסחת כ-Intel או מקבילה.

Raspberry Pi OS אינו אחד מאותן סביבות Linux המפורטות. זו אינה פסיקה לגבי כל מהדורה של FortiClient ולא תחזית לגבי שחרורים מאוחרים יותר; זו הצהרה על אותה שורה באותו מסמך. קרא את המטריצה של הגרסה שאתה באמת מתכוון לפרוס.

אל תעביר הערות מעבד משורות Windows או macOS לשורת Linux. ספקים מתעדים פלטפורמות לפי מהדורה ולפי שחרור, והערה שחלה על שורה אחת אינה הוכחה לגבי אחרת.

צעד שני: אמת מה ה-Pi מריץ

שלוש פקודות מיישבות את העובדות המקומיות לפני כל הורדה:

uname -m
cat /etc/os-release
dpkg --print-architecture

הראשונה אומרת לך את ארכיטקטורת הקרנל, השנייה את ההפצה והשחרור, והשלישית את ארכיטקטורת מרחב המשתמש שלשמה נבנות החבילות. קרנל של 64 סיביות עם מרחב משתמש של 32 סיביות אפשרי, וזה משנה איזו חבילה אתה צריך.

לאחר מכן בדוק מה באמת זמין לאותה פלטפורמה. טבלת החבילות המפורסמת של Debian trixie כוללת בניות arm64 ו-armhf של openfortivpn. זה מבסס זמינות ארכיטקטורה באותה הפצה. הוא אינו מבסס ש-Fortinet מכשיר FortiClient על נגזרת, ואינו מבסס שהשער של הארגון שלך מקבל את הלקוח.

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

צעד שלישי: בדוק את השער לפני שאתה מאשים את הלקוח

Upstream מתאר את openfortivpn כלקוח PPP ו-TLS שמפעיל את pppd. זו מימוש מסוים, והוא דורש שהשער יציע מצב תואם. שם מותג של שרת אינו הסכם פרוטוקול.

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

נסה את החיבור עם החשבון שהונפק לך, לא עם חשבון של מנהל, כי הרשמה ומדיניות בדרך כלל קשורות למשתמש:

sudo openfortivpn vpn.example.com:443 -u <username>

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

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

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

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

אם המעסיק דורש סביבת FortiClient מנוהלת שה-Pi אינו יכול לעמוד בה, בקש נקודת קצה מאושרת או מארח גישה מאושר. אל תשבית אימות עמיתים, אל תחקה בדיקות מצב ואל תחליף את השער של הארגון כדי להתאים מכונה אחת. המסקנה שצריך לכתוב היא איזה שילוב נתמך מורשה, ולא שתוכנה בקוד סגור לעולם אינה יכולה לכוון ל-ARM.