Keyfile או Netplan: היכן פרופיל ה‑VPN באמת נשמר?
VPN שמור יכול לחיות בקובץ keyfile או בקובץ Netplan שנוצר. התאימו את ה‑UUID של החיבור לבעלים האמיתי שלו לפני שאתם עורכים משהו שנכתב מחדש.
מציאת הקובץ שייבאתם היא החלק הקל ולעיתים קרובות ההתחלה הלא נכונה. מה שחשוב הוא איזה קובץ NetworkManager קורא היום כחיבור השמור, וזה תלוי במזהה חיבור ובבקאנד התצורה שהחבילות המותקנות באמת משתמשות בו. עריכת היבוא לפני שמענים על השאלה הזו היא הדרך שבה VPN עובד הופך לשתי תצורות חצי נכונות.
הקובץ המיובא אינו הפרופיל השמור
שלושה שמות מרחפים סביב כל בעיית VPN: שם החיבור, שם הקובץ שייבאתם והממשק הווירטואלי שמופיע כשהמנהרה עולה. אף אחד מהם אינו מזהה את התצורה השמורה, ואפשר לערוך שם חיבור בעוד הקובץ שמאחוריו שומר על המזהה המקורי שלו.
התחילו במלאי לקריאה בלבד ובחרו את ה‑VPN המבוקש לפי מזהה ולא לפי תווית:
nmcli -f NAME,UUID,TYPE connection showהשאירו שמות מארח של נקודות קצה ותוויות זהות מחוץ לכל מלאי שאתם מדביקים בכרטיס. החלק השימושי הוא הסוג והמזהה; השאר הוא הקשר שזר לא צריך. השחרו את השאר לפני השיתוף ואמרו שעשיתם זאת, כדי שאיש לא יתהה מה משמעות החסרים.
מיקומי keyfile אינם אומרים את אותו הדבר
עם תוסף ה‑keyfile המקורי, קובצי חיבור יכולים להופיע בשלושה ספריות, וההבדל ביניהן הוא התמדה ולא נוחות.
| Location | Role |
|---|---|
/etc/NetworkManager/system-connections/ | Administrator-owned persistence |
/usr/lib/NetworkManager/system-connections/ | Package-supplied defaults, replaced on upgrade |
/run/NetworkManager/system-connections/ | Runtime state, regenerated and not durable |
עריכת עותק זמן הריצה נראית מוצלחת עד האתחול הבא, ואז השינוי מתאדה והקובץ נראה כאילו הוחזר באופן מסתורי. עריכת העותק שסופק על ידי החבילה עובדת עד שעדכון מחליף אותו, וזו גרסה איטית ומבלבלת יותר של אותו לקח.
התיעוד של keyfile מוסיף פרט שראוי לכבד: הקבצים האלה יכולים להכיל מפתחות פרטיים וביטויי סיסמה, ו‑NetworkManager מתעלם מכל keyfile שמשתמשים שאינם root יכולים לקרוא או לכתוב. הרחבת הרשאות הספרייה כדי לחפש הגדרה שוברת את התנהגות הטעינה שביקשתם לבדוק.
כאשר Netplan בעל ההתמדה
באובונטו, שילוב ה‑NetworkManager המתואר בתיעוד של Netplan, הזמין מ‑23.10 ואילך, משנה היכן העותק הקבוע נמצא. עבור חיבורים לא זמניים הוא כותב /etc/netplan/90-NM-<connection UUID>.yaml ומייצר פרופיל NetworkManager ארעי תחת /run/NetworkManager/system-connections/.
זהו שילוב של הפצה, לא כלל לכל התקנת NetworkManager. ודאו שהחבילות המותקנות באמת משתמשות בו לפני שאתם יוצאים לחפש קובץ YAML. זכרו גם שפרופיל זמן ריצה יכול להיות ייצוג מחולל של משהו אחר ולא המקור שראוי לערוך. שתי פקודות בדיקה חוסכות שעה של עריכת הקובץ הלא נכון.
הדוגמה המתועדת שומרת חיבור OpenVPN דרך סוג Netplan nm-devices עם נתוני העברה של NetworkManager. העובדה של‑Netplan אין פרשנות ייעודית לשדה VPN מסוים אינה אומרת שה‑VPN השמור שלכם אבד; היא אומרת שהשדה נוסע כנתונים אטומים.
ממשקים זמניים אינם פרופילים
הפעלה יוצרת חיבורים וממשקים וירטואליים זמניים שמעולם לא נועדו להישמר. השילוב בכוונה אינו כותב קובץ YAML חדש לכל אחד מהם, ולכן היעדרם מ‑/etc/netplan אינו אומר דבר על האם פרופיל האב שמור.
אם אתם רודפים אחרי קובץ שמופיע ונעלם, כנראה שאתם מסתכלים על אחד מאלה ולא על התצורה שלכם. בדקו אם הוא שורד הפעלה מחדש לפני שאתם מסיקים משהו מתוכנו. קובץ זמן ריצה שנעלם באתחול אומר לכם שהוא מעולם לא היה המקור, והתצפית הבודדת הזו מפנה את כל החקירה. היא גם מסבירה למה עריכה נראתה מוצלחת באותו רגע.
סודות ובעלות
פרופיל יכול להפנות לתעודה או למפתח שנשמרים במקום אחר לגמרי, וסיסמה יכולה להיות של NetworkManager, להיות מסופקת על ידי סוכן סודות של הפעלת משתמש, או להישאר לא שמורה בכוונה. לכן איתור קובץ בודד מכריע מעט מאוד לגבי מה שנדרש באתחול ללא השגחה.
בדקו את ההפניות ואת דגלי הסודות בלי להדפיס ערכים סודיים. התחברות לשולחן עבודה יכולה להפוך סוכן לזמין שלא היה שם בזמן האתחול, והעתקת קובץ זמן ריצה מחולל אינה משחזרת את אותו סוכן. הסימפטום המעשי הוא מנהרה שמתחברת כשאדם מתחבר ונכשל כשהמכונה עולה לבד. התבנית הזו מצביעה על בעלות על סודות, לא על ניתוב.
בצעו שינויים מאושרים דרך המנהל שבעל החיבור, ואחר כך אמתו גם את המזהה השמור וגם את החיבור האפקטיבי. החזיקו בעלים קבוע אחד, כי עריכת היבוא, keyfile מחולל ומקור YAML בנפרד מותירה שלושה הסברים מתחרים לגבי מה ההתחברות הבאה תשתמש בו. בחרו בזה שבאמת נשמר, ערכו רק אותו, ורשמו בכרטיס איזה קובץ התייחסתם אליו כסמכותי. האדם הבא יודה לכם על שורה אחת של מקור.