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

קודם כל, החלט איזה פרוטוקול באמת קיבלת

הבנייה מחדש הזו מכנית ברגע שאתה מפסיק להתייחס ללקוח של הספק כאל מימוש הייחוס.

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

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

ארבעה סודות נוסעים בארבעה שדות שונים

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

שני הערכים האחרים קלים יותר לפספוס. מזהה הקבוצה הוא המחרוזת שהאשף כתב לאובייקט קבוצת ה-IPsec, ו-0 הוא ערך חוקי ולא שדה ריק. ההצעה מכסה הצפנה, גיבוב וקבוצת Diffie-Hellman לכל שלב, בתוספת הגדרת PFS, וכל פריט בה חייב להתאים לשער. כשחיבור נכשל בשלב 1, כמעט תמיד אחד מארבעת אלה הוא האשם, אז רשום אותם בנפרד במקום לזרוק אותם לתיבה אחת.

מה כל שדה של vpnc חייב להכיל

התקן את הלקוח יחד עם ממשק העריכה, ואז צור חיבור VPNC:

sudo apt install vpnc network-manager-vpnc network-manager-vpnc-gnome

הגדר את השער לכתובת הציבורית של FortiGate, ואת שם הקבוצה בדיוק למזהה מהשער, כולל אפס חשוף. Group password מקבל את המפתח המשותף מראש, ואילו שם המשתמש והסיסמה מקבלים את החשבון שלך, עם כל אסימון שצורף כפי שהשער מצפה. בתיבת הדו-שיח המתקדמת, בחר את קבוצת Diffie-Hellman שההצעה מציינת, התאם PFS לאותה קבוצה, הפעל מעבר NAT כשהלקוח נמצא מאחורי נתב ביתי, והשאר את זיהוי העמית המת באותו קצב כמו השער.

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

אותו פרופיל שנכתב עבור strongSwan

strongSwan הוא המכל לטווח ארוך הטוב יותר לערכים האלה, מכיוון שהתצורה היא קובץ טקסט שאתה יכול לעבור עליו ולשמור:

conn office-fw
    keyexchange=ikev1
    aggressive=yes
    left=%any
    leftauth=psk
    leftauth2=xauth
    xauth_identity=YOUR_USER
    right=GATEWAY_ADDRESS
    rightauth=psk
    rightsubnet=OFFICE_SUBNET
    ike=aes128-sha1-modp1536!
    esp=aes128-sha1-modp1536!

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

שתי שורות האימות אינן מיותרות. ה-PSK מוכיח את העמית, בלוק XAuth מוכיח את המשתמש, והשמטת כל אחד מהם מותירה שלב שהשער לא יסיים.

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

עבוד מהתסמין לאחור במקום להגריל את תיבת הדו-שיח מחדש. IKE SA שעולה בלי כתובת מוקצית פירושו שחילוף אימות המשתמש נכשל או מעולם לא רץ, אז בדוק את החשבון ואת הטיפול באסימון. שלב 1 שלעולם לא מסתיים מצביע על ההצעה, מזהה הקבוצה או המצב התוקפני, וכל אחד מהם מושווה לשער, לא רק ללקוח Windows.

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

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

מאמרים קשורים