הייבוא ב-NetworkManager נכשל בקבצי OpenVPN ו-WireGuard

בחרתי ייבוא מקובץ… בהגדרות GNOME, בחרתי פרופיל שעובד עם הלקוח של הספק, והדיאלוג נסגר בלי להוסיף דבר לרשימה. במחשב נייד שני הייבוא הושלם, החיבור הופיע בשם הפרופיל ואז נכשל בבקשת האימות הראשונה. NetworkManager אף פעם לא מריץ את קובץ .ovpn או wg-quick שלכם כפי שהוא. הוא מוסר את הקובץ לפרסר, הפרסר ממיר אותו לפורמט החיבור של NetworkManager עצמו, ומכאן והלאה המנהרה נבנית מהאובייקט המפוענח הזה — סודות, מסלולים, DNS וכל השאר. לכן השאלה המועילה אינה למה הקובץ שבור, אלא אם הפיענוח התרחש ומה הוא שמר.

מה הייבוא באמת עושה עם הקובץ

עבור OpenVPN הפרסר חי בחבילת התוסף, והחיבור שהוא יוצר מצביע על שירות D-Bus כמו org.freedesktop.NetworkManager.openvpn. אין תוסף, אין פרסר: הסוג אינו מוכר ל-nmcli, ורשימת ההוספה הגרפית של VPN עשויה לא להציג כלל רשומת ייבוא. WireGuard שונה בנקודה חשובה — ל-NetworkManager יש הגדרות WireGuard משלו מאז סדרת 1.30, כך שאין חבילת תוסף נפרדת, אבל קורא ה-wg-quick קיים רק בגרסאות שמספקות אותו.

כך או כך, הקובץ נקרא פעם אחת. התוצאה נכתבת כ-keyfile תחת /etc/NetworkManager/system-connections/, על שם החיבור, בבעלות root ובלתי קריא למשתמשים אחרים כי הוא מחזיק את חומר המפתח. ה-keyfile הזה הוא עכשיו החיבור; עריכת קובץ .ovpn המקורי לאחר מכן לא משנה דבר.

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

ודאו את התוסף לפני שאתם מאתרים תקלות בפרופיל

תוסף חסר נראה בדיוק כמו פרופיל פגום, לכן בדקו קודם את החבילה. ב-Debian וב-Ubuntu תמיכת OpenVPN מגיעה כ-network-manager-openvpn ועוד עוזר שולחני; ב-Fedora החבילות הן NetworkManager-openvpn ו-NetworkManager-openvpn-gnome; ב-Arch זה networkmanager-openvpn.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

לאחר מכן ייבאו מנתיב מוחלט: nmcli connection import type openvpn file /home/you/profile.ovpn. נתיבים יחסיים בדרך כלל עובדים, אבל קונכייה שהחליפה ספרייה הופכת ייבוא מהיר לעיקוף. עבור WireGuard בדקו את nmcli --version וודאו שצד הליבה קיים עם modprobe wireguard; ייבוא שמצליח במכונה בלי המודול משאיר אתכם עם חיבור שהתקן שלו לא מופיע לעולם. מדריך nmcli מתעד את תת-הפקודה import ואת שמות הסוגים המתקבלים. אם type wireguard נדחה על הסף, הבנייה קודמת לתכונה, והצעד הנכון הוא חבילת הפצה או backport — לא להעתיק את התצורה לספרייה שרירותית בתקווה שמשהו יקרא אותה.

קראו את חיבור OpenVPN, לא את ה-.ovpn

לאחר שהחיבור קיים, קראו את ההגדרות המפוענחות במקום לקרוא את הקובץ שוב: nmcli connection show "Work VPN" | grep -E '^vpn\.'. אתם רוצים את ה-remote והפורט, את התעבורה, את חומר הזהות — ca, cert, key, tls-auth או tls-crypt — ואת שיטת האימות. בפרופיל עם סיסמת מפתח פרטי הוסיפו sudo nmcli --show-secrets connection show "Work VPN" והביטו בדגלי secret: 0 הוא none, כלומר הסוד נמצא ב-keyfile; 1 הוא agent-owned; 2 הוא not-saved, כלומר הוא לעולם לא נכתב ל-keyfile; 4 הוא not-required, כלומר אין צורך בסוד כלל. אלה ביטים, לא סקאלה, ולכן 3 הוא פשוט agent-owned ועוד not-saved. סוד שנשאל פעם בסשן הוא agent-owned (1), כשהסוכן מבקש אותו; אין מספר דגל נפרד לכך. אי-התאמת דגלים היא הסיבה הרגילה לכך שפרופיל מתחבר מאפליקציית שולחן העבודה ונכשל מסקריפט או באתחול.

הדרך המהירה ביותר לראות מה הפרסר זרק היא לבקש מהתוסף לכתוב את הקובץ חזרה ואז להשוות: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. הנחיות שנעלמות בהשוואה הזו לא יהיו קיימות בזמן החיבור. Hooks הם החשודים הרגילים — script-security, up, down ו-route-up מצפים לסקריפט שרץ בהרשאות מוגברות ובמכוון אינם מועברים. אל תורידו את האימות ואל תיתנו הרשאות נוספות כדי שייבוא יצליח; אפשרות לא נתמכת משקפת בדרך כלל את סט התכונות של התוסף ולא שרת בלתי נגיש. העבירו את ההתנהגות הזו לסקריפט dispatcher של NetworkManager או למדיניות בצד השרת.

ודאו גם ששדות הזהות שרדו: הפניית CA, remote-cert-tls וכל בדיקת שם שהפרופיל הסתמך עליה. חיבור שעולה בלעדיהם מדבר אולי עם כל מה שעונה בכתובת הזו.

קראו את חיבור WireGuard, לא את קובץ ה-wg-quick

קובץ wg-quick הוא פורמט עם סמנטיקת shell; החיבור המיובא הוא סט הגדרות. PrivateKey הופך למפתח הפרטי של הממשק, Address הופך לכתובת IPv4 ו-IPv6 אחת או יותר, DNS ממופה למאפייני ה-resolver של NetworkManager, MTU ממופה ל-wireguard.mtu (ברירת המחדל של wg-quick עצמו היא 1420), וכל בלוק peer הופך לרשומת peer עם מפתח ציבורי, endpoint, כתובות IP מותרות ו-persistent keepalive. הדפיסו את מה שנשמר עם nmcli --show-secrets connection show wg0; אם רשימת ה-peers לא מופיעה בפלט הזה, קראו את ה-keyfile:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

מה שלא שורד הוא חצי ה-shell של wg-quick. PreUp, PostUp, PreDown, PostDown ו-Table הם התנהגות של הכלי הזה, לא מאפיינים של ממשק WireGuard, ולכן שום דבר לא מריץ אותם אחרי ייבוא. אם המקור השתמש ב-Table = off כדי להשאיר את המסלול המוגדר כברירת מחדל בשקט, גרסאות NetworkManager חדשות חושפות למטרה זו את ip4-auto-default-route ו-ip6-auto-default-route; הגדירו אותם במפורש במקום להניח שהחיבור מתנהג כמו הסקריפט. Hook שדחף מסלול מותאם צריך את המסלול הזה בהגדרות הניתוב של החיבור, אחרת הוא פשוט יחסר.

תנו לחיבור בדיוק בעלים אחד

הכשל הקלאסי שאחר כך הוא חיבור שעובד עד האתחול הבא ואז נכנס ללופ. בדרך כלל [email protected] עדיין היה מופעל מניסוי קודם, או שלקוח של הספק הפעיל דמון משלו, ו-שני בעלים כתבו מסלולים ו-DNS לאותו יעד. NetworkManager מגדיר את ה-resolver בדרך שלו, wg-quick כותב דרך resolvconf, והכותב האחרון מנצח — כך שפתרון שמות עובד, ואז נעצר, ואז עובד שוב. בדקו את systemctl status wg-quick@wg0, nmcli connection show --active ו-ip link show type wireguard, ואז השביתו את הבעלים השני במקום לכוונן את ה-metric שלו.

אם באמת צריך את שניהם, תנו להם ממשקים נפרדים וכתובות IP מותרות זרות, ותנו בדיוק לאחד מהם להתקין את המסלול המוגדר כברירת מחדל. שני מסלולי ברירת מחדל עם metrics שונים אינם split tunnel; זהו מרוץ שהשירות שעולה שני מכריע. ואחרי התחברות מחדש, בדקו שוב את המצב המיושם — עריכת resolver ידנית חד-פעמית שמותירה שהדברים עובדים אינה הוכחה שהייבוא שלם.

אמתו עם תעבורה ותשרדו אתחול

העלו את החיבור עם nmcli connection up "Work VPN", ואז קראו מצב, כתובת ומסלולים במקום לסמוך על הסמל: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default ושאילתה אמיתית של שם שנפתר רק בתוך המנהרה. Handshake או ping מוצלח מוכיחים רק שההצפנה עובדת; הם לא אומרים דבר על העברה, קידומות split tunnel או DNS פרטי, ואלה החלקים שבדרך כלל נשברים.

אחר כך אתחלו וחזרו על כך. התנהגות autoconnect, ממשק ששמו שונה ותוסף שנטען אחרי ההתקן הם כולם כשלים שרואים רק באתחול נקי. journalctl -u NetworkManager -b --no-pager | tail -n 40 מראה מה הדמון עשה עם החיבור הזה באתחול הזה. למחשב שני העתיקו את ה-keyfile ושמרו אותו בבעלות root עם מצב 600, או השתמשו ב-nmcli connection export עבור OpenVPN וייבאו מחדש את ה-.ovpn שנוצר — לנתיב הייצוא אין מקבילה ב-WireGuard, ולכן הכיוון הזה הוא העתקת קובץ או ייבוא חדש מהמקור המוגן.

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