איזה קובץ openvpn רץ בפועל? בדקו את נתיב ההפעלה

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

התחילו מהנתיב שהשירות מפעיל

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

שאלו את היחידה מה היא מריצה, כולל תוספות ה-drop-in שמשנות אותה, וקראו את שורת ExecStart המתקבלת ולא את הקטע שאתם מניחים שהוא הסמכותי. אחר כך עקבו אחרי הנתיב דרך כל קישור סמלי עד לקובץ הסופי. עטיפה שמסתיימת ב-exec אל תיקייה מוסתרת היא סידור נפוץ מהתיקונים הישנים האלה.

רשמו את הנתיב שנפתר לפני שאתם משנים משהו.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

השוו את שם הפקודה לנתיב השירות

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

מה שחשוב הוא לדעת איזה בעלים מפעיל את התהליך שמשרת את התעבורה. אם היחידה מריצה /usr/local/sbin/openvpn-wrapper בעוד ה-shell שלכם פותר /usr/sbin/openvpn, תיקון הקובץ השני לא משנה דבר בשירות.

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

תנו למסד נתוני החבילות לדבר על קובצי החבילה

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

הריצו את האימות וקראו את הפלט במקום להתייחס לתוצאה ריקה כהוכחה למשהו.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

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

תעדו את המצב לפני התיקון

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

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

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

אמתו את ההפעלה ואז הסירו את העטיפה

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

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

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