client-config-dir מתעלמים ממנו אחרי ש-OpenVPN הפך לשירות

המנהרה שלך עולה והלקוח מתחבר, אבל הכתובת הקבועה והנתיבים שנדחפו שהגדרת לאותו משתמש אחד חסרים. היומן לא אומר “file not found”, וזה בדיוק מה ששולח אנשים ליצור מחדש אישורים. ברוב המקרים האלה הדמון רץ מספרייה אחרת מזו של המעטפת שבדקת בה, ו-client-config-dir מעולם לא נפתר כפי שהנחת. התיקון הוא תיקון נתיב, לא איפוס פרטי התחברות.

קרא את היחידה לפני שאתה נוגע בקונפיגורציה

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

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

WorkingDirectory ריק פירושו שהיחידה מתחילה ב-/, ולכן client-config-dir ccd יחסי מתחפש ב-/ccd. הספרייה הזו כמעט אף פעם לא קיימת, והדמון לא רואה בהיעדרה משהו קטלני.

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

מול מה נפתר נתיב יחסי

מילת המפתח נפתרת מול ספריית העבודה של התהליך ברגע שבו משתמשים באפשרות. זה לא אומר “לצד קובץ הקונפיגורציה שהעברתי עם --config”. OpenVPN יקרא בשמחה קונפיגורציה מנתיב מוחלט ובכל זאת יפתור ערכים יחסיים במקום אחר, וזו בדיוק המלכודת כאן. המדריך של OpenVPN 2.6 מציין את הכלל תחת --client-config-dir ושוב תחת --cd.

מילת המפתח cd משנה את ההקשר הזה לפני שקבצים אחרים נקראים, ולכן יחידה שמגדירה cd /etc/openvpn/server ואז client-config-dir ccd נפתרת ל-/etc/openvpn/server/ccd. אם אתה מוסיף cd, בדוק את סדר ההוראות וזכור שהוא משפיע על כל התייחסות יחסית אחרת באותו קובץ.

עבור על הנתיב כחשבון הדמון

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

namei מדפיס את ההרשאות של כל רכיב לפי הסדר, וזה מהיר יותר מלבדוק ספריות אחת-אחת:

namei -l /etc/openvpn/server/ccd/client1

ואז בדוק את הקריאה כחשבון השירות ולא כעצמך:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

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

אמת את החיפוש במקום לנחש

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

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

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

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

תקן, אתחל מחדש, אמת

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

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

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

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