NM OpenVPN: הפרופיל השמור אינו קובץ ה-.ovpn שלכם

אותו .ovpn קובץ מתחבר ממעטפת ופוג תוקף לאחר ייבוא ל-NetworkManager. המסקנה הטבעית היא שה-VPN שבור. ההסבר הסביר יותר קטן: NetworkManager לא שמר את הקובץ, הוא ייבא חלק ממנו לחיבור שמור, והמנהרה הרצה משתמשת במקום זאת בנתונים השמורים האלה. מה שהקובץ אומר כעת אינו רלוונטי למה שהפרופיל מכיל.

הקובץ אינו הפרופיל

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

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

קראו את הפרופיל השמור, לא את תיבת הדו-שיח

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

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

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

שני מפתחות, וכיוון אחד שחשוב

עבור חיבור שמשתמש באימות TLS, התוסף שומר את נתיב המפתח המשותף ב ta ואת הכיוון ב ta-dir, כאשר הפריסה משתמשת באחד. שניהם חיים במילון הנתונים של הפרופיל, ושניהם חייבים להתאים למה שהשרת מצפה לו.

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

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

עדכנו רשומה אחת, לא את המילון

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

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

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

אל תערבבו בין מצבי ערוץ הבקרה

tls-auth, tls-crypt, וכן tls-crypt-v2 הם סידורים שונים. קובץ מפתח שנראה דומה אינו הופך אותם לברי החלפה, ומילוי שדות TLS-Auth מפני שפרופיל אחר מכיל מפתח בפורמט מייצר פרופיל שנכשל באופן שמזכיר מפתח שגוי.

השתמשו במיפוי התוסף שמתאים למצב בתצורת השרת. כשהמצב אינו ברור, שאלו את בעל השרת במקום לנחש מהשורה הראשונה של הקובץ.

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