OpenVPN לא עולה: קראו את השורה הראשונה, לא את התצורה

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

שלוש פקודות לקריאה בלבד מביאות אתכם לשם: תחילה journalctl -u openvpn@server -b --no-pager, אחר כך systemctl status openvpn@server, ו-ss -lunp עבור מאזיני UDP והבעלים שלהם.

השורה הראשונה בוחרת את הענף

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

שימו לב ללולאת הניסיונות החוזרים שמסתירה את השורה המקורית. יחידה עם מדיניות הפעלה מחדש יכולה לקבור את הכשל הראשון תחת תריסר זהים, ולכן journalctl -b מסונן לפי היחידה ונקרא מלמעלה עדיף על הזנב.

מי עוד מחזיק ביציאה 1194

האשם בדרך כלל אינו שרת שני שמישהו הגדיר בכוונה. צפו ללקוח שהופעל ביד ועודו חי במסוף אחר, לפרופיל שני שבחר במקרה באותה יציאה, או לחבילת ספק שהמנהרה שלה עצמה מחזיקה ב-1194. בעל ה-socket מופיע ב-ss -lunp; העבירו את ה-PID הזה ל-systemctl status כדי לדעת אם יחידה אחראית. הורידו אותו דרך נתיב הבקרה שלו ולא בעזרת אות.

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

יחידות שנותרו אחרי הסרה

הסרה מוחקת קבצים בינאריים; קובצי יחידה שנכתבו ביד, בדרך כלל תחת /etc/systemd/system, שורדים אותה. אז Systemd מנסה שוב יחידה שמצביעה על נתיב שאינו קיים עוד, וההודעה נוגעת בקובץ החסר הזה ולא בהסרה של אתמול. systemctl status מציג את נתיב השבר של היחידה סמוך לראש, לכן בדקו אותו עם dpkg -S לפני שתמחקו משהו. לאחר שהיתום נעלם, systemctl daemon-reload ו-systemctl reset-failed מנקים את המצב; אחרת כל בדיקת מצב מאוחרת יותר יורשת אותו.

כאשר which openvpn עונה במשהו תחת /usr/local, הקובץ הבינארי שבמשחק הגיע ממתקין ספק ולא מ-apt. מתקין כזה מביא בדרך כלל מאזין משלו, רשומת אתחול משלו ותיקיית תצורה משלו, ולכן הסרת הפקודה הנראית לעין משאירה את ה-socket תפוס.

הסירו אותו כפי שהספק מתעד, ודאו שהיציאה פנויה עם ss -lunp, והוסיפו את לקוח ההפצה רק אם אתם זקוקים לו.

סדרו את המצב לפני ניסיון חוזר

נקו את מצב הכשל לפני הסקת מסקנות ממנו: systemctl reset-failed מסיר את המונים, ואז systemctl status מדווח על מצב היחידה הנוכחי ולא על ההיסטוריה שלה. הפעילו אותה פעם אחת וקראו את היומן של אותה הרצה ולא את המצב המצטבר של המכונה. יחידה שמדווחת שהיא פעילה בזמן שהמנהרה לא נושאת דבר היא בעיה נפרדת, ונפוצה הרבה יותר. השתיים מתמזגות בדוחות באגים כי שתיהן מסתיימות בכך שהמשתמש אומר שה-VPN לא עובד.

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