openvpn3 session-start מתעלם מקובץ האישורים שלך
לקוח 3.x מקבל אישורים בפתיחת סשן ולא יקרא קובץ שמור. השתמשו בהנחיה או בנתיב הטעינה האוטומטית, וקבלו את מה שכל אחד מהם שומר.
התחברו עם לקוח 2.x והפרופיל עובד; תנו את אותו קובץ ללקוח 3.x והוא נעצר בהנחיית סיסמה. מסרו --auth-user-pass creds.txt ל-openvpn3 session-start והתוצאה זהה, כי ללקוח החדש אין שלב שקורא את הקובץ. הסירוב מכוון: אישורים שייכים לסשן, וסשן נוצר על ידי שירות, לא על ידי התהליך במסוף שלכם. בחרו בין ההנחיה האינטראקטיבית לעוזר הטעינה האוטומטית, ודעו מה כל אחד מהם שומר.
למה לקובץ השמור אין לאן ללכת
בעיצוב החדש, ניהול התצורה וניהול הסשנים הם שירותים נפרדים שמדברים דרך אפיק המערכת. ההפרדה הזו היא שמאפשרת למשתמש רגיל להתחיל סשן בלי שדמון בעל הרשאות יקרא בשמו קובץ סיסמאות מוגן. אישורים מבוססי קובץ אינם מתאימים למודל הזה, כי אין אתחול בצד הדמון שיקרא אותם. הסירוב הוא תוצאה של הארכיטקטורה, לא תכונה חסרה.
כדאי לתת שם לתבנית הישנה כדי שיהיה קל יותר לשכוח אותה: פרופיל מפנה לקובץ אישורים, והדמון קורא אותו כשהמנהרה מתחילה. במודל החדש, אישורים שייכים לסשן ומסופקים כשהסשן הזה מתחיל. openvpn3 session-start --config work.ovpn מבקש אותם, ו---auth-user-pass creds.txt נדחה כי שום דבר בנתיב הזה לא היה פותח את הקובץ. כל מתכון 2.x שתמצאו מניח שלב שכבר אינו קיים.
גם התצורה וההגדרות המקומיות של האתר נפרדות, וזה מסביר הפתעה שנייה. פרופיל יכול להיראות שלם בזמן שהחיבור שהוא מייצר חסר תצורת ניתוב ופותרן. החלקים האלה מיושמים כהגדרות מקומיות של האתר, בנפרד מהקובץ המיובא.
מסלול ההנחיה והסשן שהוא משאיר
אספקת הסיסמה עם תחילת הסשן היא זרימת העבודה המיועדת. הלקוח מבקש פעם אחת, מוסר את האישורים לחלק האחורי של הסשן וממשיך:
openvpn3 session-start --config work.ovpn
openvpn3 sessions-list
במסלול הזה לא נכתב שום דבר לדיסק. הסשן ממשיך לרוץ גם אחרי שהמסוף נסגר, וזה מפתיע אנשים שמצפים שהתהליך ימות עם המעטפת שלהם. בדיוק זו הנקודה של העברת ניהול הסשנים לשירות. הסשן שורד את המסוף שביקש אותו, ויש לעצור אותו במפורש.
בתחנת עבודה עם אדם מולה, זו גם האפשרות הבטוחה ביותר, כי אין סוד שמור שצריך להגן עליו או לשכוח. היא אינה מתאימה רק במקום שאין מי שיקליד.
אוטומציה בלי אדם במקלדת
כשמכונה צריכה להתחבר בלי אדם, הפרויקט מספק את openvpn3-autoload. הוא קורא ספריית פרופילים ותיאור מתאים לכל פרופיל, והתיאור מספק את האישורים בטקסט פשוט. העוזר הוא קובץ בינארי נפרד, בדרך כלל ב-/usr/sbin/openvpn3-autoload, לא דגל של session-start. התקנה פירושה יצירת הספרייה, העתקת הפרופיל בשם שהתיאור מצפה לו, וכתיבת התיאור.
התקנה לכל משתמש נראית כך, ומופעלת בחשבון שיהיה הבעלים של הסשן. מצב הספרייה מרחיק משתמשים מקומיים אחרים:
mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload
התיאור נוקב בשמות האישורים ומבקש הפעלה אוטומטית. החזיקו את ערך הסיסמה מחוץ לבקרת גרסאות:
{
"autostart": true,
"user-auth": {
"autologin": true,
"username": "svc-vpn",
"password": "change-this-value"
}
}
לאחר מכן הפעילו את העוזר פעם אחת ואמתו שהסשן מופיע. הפקודה השנייה היא הבדיקה, לא עוד שלב התקנה:
/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list
בעת האתחול, יחידה ארוזה בשם openvpn3-autoload.service משתמשת בספרייה המערכתית /etc/openvpn3/autoload, לא בזו שלכל משתמש. המיקום הזה דורש בעלות root ומצב מחמיר יותר, והתיאור עדיין מחזיק את הסיסמה בטקסט גלוי. הפשרה מפורשת: הסיסמה יושבת כעת על הדיסק, אז התייחסו לספרייה הזו כאל סוד, הוציאו אותה מגיבויים מחוץ למארח, ובחרו במסלול האינטראקטיבי בכל פעם שאדם נמצא.
כשלי אפיק שנראים כמו כשלי סיסמה
חלק מהכשלים המיוחסים לאישורים אינם כאלה כלל. שגיאת הרשאה שמציינת את נתיב הפעלת השירות משמעה אחד משניים: החלק האחורי לא פועל, או שלקורא אין הרשאה להפעיל אותו. שום עריכת פרופיל לא תשנה אף אחד מהם. בדקו את מצב השירות ואת מדיניות האפיק המסופקת לפני שתיגעו בתצורה.
הפקודות שלמטה מפרידות בין השניים. הראשונה מדווחת אם החלק האחורי פועל; השנייה מציגה שגיאות אפיק אחרונות:
systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20
אי-הקריאה הנפוצה האחרת היא סשן שמופיע ואז נעלם מיד. התבנית הזו בדרך כלל אומרת שההגדרות המקומיות של האתר לא הוחלו מעולם, כך שהמנהרה עלתה בלי שינויי הניתוב והפותרן שעושים אותה שימושית. קראו את הרצף ולא את השורה האחרונה: אם הסשן נוצר, אם הגיע למצב מחובר ואם שרד הם שלושה עובדות נפרדות.
כשהלקוח הישן עוד בשימוש
לקוח 2.x עדיין מקבל קובץ אישורים, ומחזיק מפתחות יכול לענות על ההנחיה שלו בלי שהסוד יגיע אי פעם לדיסק. עטיפה פותרת את הרשומה, כך שהקובץ נוקב בשם החיפוש ולא בסיסמה. הסידור הזה תלוי במחזיק מפתחות פרום, מה שקונטיינר בלי סשן התחברות או יחידה שעולה לפני שמישהו מתחבר אינם יכולים לספק. אז כלי החיפוש מדווח על אוסף שאינו יכול לכתוב אליו, כך שהשגיאה נראית כמו תקלת אישורים כשהיא תקלת מחזיק מפתחות.
לפני שתבנו משהו מזה, בדקו אם הגדרת keepalive בפרופיל מסירה לגמרי את הצורך בהפעלה מחדש. סשן שנשאר למעלה לא מגיע לעולם להנחיה שאתם מנסים להפוך לאוטומטית.