OpenVPN בעת האתחול ב-Ubuntu: NetworkManager או systemd?

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

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

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

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

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

חיבור ה-VPN לחיבור אינו ערובה לאתחול

ב-nm-connection-editor, בחרו בחיבור הקווי או האלחוטי ולא ב-VPN, פתחו את הכרטיסייה General, סמנו את האפשרות להתחבר ל-VPN אוטומטית ותנו שם לפרופיל. לאחר מכן NetworkManager מפעיל את ה-VPN כחיבור משני כאשר החיבור הראשי מגיע למצב מחובר. זו תלות, לא כלל חומת אש. חבילות עדיין יכולות לצאת בשניות שלפני עליית המנהרה, וסוד שמור שלא נפתח משאיר את המכונה מקוונת בלעדיו.

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

מופע systemd זקוק לשם קובץ תואם

שימו את הפרופיל בתיקיית הלקוח שהחבילה מצפה לה, כגון /etc/openvpn/client/office.conf, והפנו מתוכו לקובץ האישורים עם auth-user-pass office.cred. שם המופע הוא שם הקובץ בלי הסיומת, ולכן openvpn-client@office קורא את office.conf. הפעילו אותו עם sudo systemctl enable --now openvpn-client@office ואמתו את המיפוי עם systemctl cat openvpn-client@office במקום לסמוך על דוגמה מבלוג.

נתיבים בתוך הפרופיל נפתרים יחסית לתיקיית העבודה של היחידה, לא יחסית לפרופיל עצמו, ולכן שורה יחסית של ca או auth-user-pass עלולה להיכשל באתחול בעוד שהיא עובדת בבדיקה ידנית. השתמשו בנתיבים מוחלטים לכל מה שהיחידה צריכה למצוא. לאחר מכן קראו את journalctl -u openvpn-client@office -b אחרי אתחול אמיתי; יחידה שמדווחת פעילה בלי מנהרה בדרך כלל מציינת קובץ חסר ביומן הזה.

חבילות ישנות יותר מספקות שם תבנית אחר, ולכן systemctl list-unit-files 'openvpn*' קובע איזה מהם קיים במארח הזה.

התנהגות ההתחברות מחדש היא החלטה נפרדת

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

עצירה היא ממש באותה מידה: sudo systemctl disable --now openvpn-client@office עוצר את המופע הרץ ומסיר את קישור האתחול. השבתה בלבד משאירה את המנהרה פועלת עד ההפעלה מחדש הבאה, מה שמפתיע כל מי שבודק על ידי השבתה ורואה שהממשק נשאר למעלה.

הפעילו מחדש, ואז בדקו ארבעה דברים לפי הסדר

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

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

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