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

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

בדיקה 1: תנו שם לשלב שנכשל

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

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

בדיקה 2: גרסת השער ומצב המנהרה

מצב המנהרה נעלם בשערים הנוכחיים, וטבלת האינטגרציה של FortiClient 7.4.4 עם לינוקס היא המקום שבו זה כתוב: FortiOS 7.6.3 ואילך אינם מציעים עוד מצב מנהרה של SSL VPN ומפנים מנהלים ל-IPsec. הצמידו את המוצר, הגרסה והמצב למשפט הזה כשאתם חוזרים עליו. הוא אינו אומר דבר על כל מוצר של Fortinet, ואינו אומר דבר על תכונות גישה לאינטרנט שעדיין קיימות. תאימות גרסאות כללית וזמינות של מצב מנהרה אחד הן בדיקות נפרדות.

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

בדיקה 3: מהדורת הלקוח שבעל השער מאשר

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

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

בדיקה 4: בקשו את פרופיל ההחלפה

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

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

בדיקה 5: תלויות מקומיות, ואז אמתו ותעדו

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

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

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