OpenVPN: הכריכה המקומית נכשלת באתחול — להמתין או לנסות שוב

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

שתיהן עדיפות על שינה קבועה, שאינה ממתינה לדבר ואינה מדווחת למה חיכתה.

מה אפשרות local באמת דורשת

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

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

להמתין לכתובת או לנסות שוב את הכריכה

המתנה משמעה ExecStartPre שמתשאל עד שהכתובת מופיעה, עם מספר ניסיונות מוגבל ויציאה שאינה אפס כאשר הזמן נגמר. ניסיון חוזר משמעו לתת לתהליך הראשי להיכשל ולבקש ממנהל השירות להפעיל אותו שוב, למשל Restart=on-failure עם RestartSec=5. הראשון מדווח על תנאי מוקדם חסר כיחידה שנכשלה, בעוד השני מדווח עליו כסדרת הפעלות מחדש שבסופו של דבר נעצרת, וזה רועש יותר ביומן אך שורד כתובת שמגיעה באיחור מסיבות שאינכם יכולים לחזות.

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

מדוע network-online.target אינו מספיק

network-online.target מבטיח את מה שהמימוש הפעיל של הרשת מתכוון ב-online, ולא מעבר לכך. עם systemd-networkd, systemd-networkd-wait-online קובע מתי היעד הזה מושג, והתפיסה המוגדרת כברירת מחדל שלו של online יכולה להתקיים לפני שהכתובת הספציפית שלכם קיימת. תחת NetworkManager, שירות wait-online מיישם כללים משלו. סידור אחרי היעד הוא קו בסיס סביר, לא ערובה לכך שכתובת אחת, תשובת DNS או עמית מרוחק מוכנים.

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

בדקו את הכריכה לאחר אתחול קר

אמתו באתחול קר אמיתי ולא בהפעלה מחדש של השירות, מפני שהפעלה מחדש יורשת כתובת שרצף האתחול היה חייב ליצור. לאחר האתחול, ss -lntp או ss -lunp מציג את הכתובת המקומית שכל מאזין באמת נכרך אליה, והרצת journalctl -b -u openvpn-server@server מראה אם הניסיון הראשון נכשל. השוו את הכתובת הנכרכת לזו שבפרופיל, ואז חזרו על ההשוואה לאחר חיבור מחדש לרשת.

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

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