Access Server איבד את הקישור לאחר שינוי שם ממשק הרשת: תקנו את המפתחות

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

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

מה הסימפטום באמת אומר

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

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

שאלו את התצורה לפני עריכתה

Access Server חושף את תצורת השר שלו דרך ה-CLI שלו. התצוגה המתועדת היא:

sacli ConfigQuery

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

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

קבעו איזה מאזין שבור

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

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

שנו את ההגדרה הנקובה, לא את השורות המתאימות

המדריך מתעד ConfigPut על מפתחות ספציפיים, כגון vpn.daemon.0.server.ip_address ו-vpn.daemon.0.listen.ip_address. השתמשו בשיטה של המוצר עצמו עם שם המפתח והערך החדש, בתחביר המתועד לגרסה שלכם, ושנו רק את המפתחות של המאזין שאותו אבחנתם.

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

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

החילו אותו, ואז הוכיחו שהנתיב עובד

לאחר תיקון הערך, החילו אותו דרך מחזור החיים המתועד של המוצר ( מחזור חיים ). המדריך משתמש ב-sacli start לאחר קביעת המפתחות; זה אינו אתחול מלא של המארח ולא איפוס מסד הנתונים.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

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