מה באמת שורדים persist-tun ו-persist-key ב-OpenVPN
שתי האפשרויות מכסות אתחול רך בתוך תהליך חי. הן אינן שומרות על הממשק לאחר עצירה, ואינן מדיניות של חסימת תעבורה.
עצירת השירות מסירה את הממשק גם כאשר persist-tun מוגדר. זו האפשרות שפועלת כמתועד, ולא כשל. האפשרות מתארת נתיב אתחול אחד בתוך תהליך פועל, ו-systemctl stop אינו הנתיב הזה.
קראו את שני השמות יחד והתכנון נעשה ברור. האחד שומר מתאר, השני שומר חומר מפתח, ושניהם קיימים בגלל מה שקורה לאחר השלכת ההרשאות.
שני המשאבים והאתחול שאליו הם שייכים
OpenVPN מאותת על אתחול משלו בשני מצבים רגילים. SIGUSR1 מפורש עושה זאת, ו-ping-restart שנגרם על ידי עמית מת עושה את אותו הדבר. שניהם משאירים את התהליך חי ומריצים מחדש את הגדרת החיבור, ושם האפשרויות זוכות במקומן.
| Event | TUN/TAP device | Key and auth files | Addresses and routes | up/down hooks |
|---|---|---|---|---|
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itself | survives only with persist-tun | survive only with persist-key | survive with the device, otherwise rebuilt | run again only when restart hooks are enabled |
Configuration reload, SIGHUP | recreated | re-read from disk | rebuilt once the device returns | run again |
| Service stop | lost | re-read at the next start | removed | run at the next start |
רק שורת האתחול הרך היא מה ששתי האפשרויות האלה משנות, והעבודה שהן מדלגות עליה היא החלק היקר בקישור עמוס. פתיחה מחדש של התקן תולשת את הכתובות והנתיבים המחוברים אליו, ובנייה מחדש שלהם עלולה להפיל מנות שהיו בדרכן כשהאתחול החל. עצירה הורסת את אותם אובייקטים בלי שום אפשרות לשמר אותם.
למה האפשרויות בכלל קיימות
שרת OpenVPN מוקשח מתחיל בדרך כלל כ-root, פותח את המפתחות ואת ההתקן שלו, ואז יורד למשתמש חסר הרשאות. לאחר הירידה הזו כמה פעולות פשוט נעלמו. קריאת קובץ מפתח במצב 0600, יצירת ממשק רשת או שינוי נתיבים עלולים כולם להידחות.
בלי אפשרויות persist, עמית ששותק מספיק זמן כדי להפעיל ping-restart היה כופה בדיוק את הפעולות האלה. החיבור מחדש היה נכשל למרות ששום דבר בהגדרה לא השתנה. התהליך היה נראה כאילו הוא מת בלי סיבה, והיומן היה מציג שגיאת הרשאה במקום שגיאת רשת.
איתן, האתחול הרך עושה שימוש חוזר במה שהשלב בעל ההרשאות כבר השיג. אין כאן קסם והתהליך לא שורד דבר. רכישת משאבים פשוט נדחית.
קראו את השגיאה הראשונה, לא את האחרונה
כשאתחול נכשל, קראו את השגיאה הראשונה ולא את האחרונה. מפתח מוגן, קובץ auth, ioctl של ממשק ו-hook חיצוני הם ארבעה משאבים שונים. שמירה על אחד אינה אומרת דבר על גישה לאחרים. hook שקורא לכלי חומת אש עדיין זקוק להרשאות שכלי זה דורש.
ל-hooks יש מתג משלהם. המדריך של OpenVPN מצמיד את אפשרויות persist ל-up-restart, שקובע אם סקריפטי up ו-down ירוצו שוב לאחר אתחול. ממשק שנשאר למעלה אפוא אינו אומר לכם דבר על כך שאינטגרציית ה-resolver שלכם התרעננה.
# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'
# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0צמד הפקודות הזה מפריד בין שני מצבי הכשל בשניות. ממשק שקיים אך חסרים בו נתיבים הוא בעיית hook או נתיב. ממשק שנעלם פירושו שהתהליך באמת הסתיים.
ממשק שנשמר אינו kill switch
אם הדרישה היא שהתעבורה לעולם לא תצא מחוץ למנהרה, התקן נשמר אינו מספק זאת. נתיבים למשפחת הכתובות השנייה, נתיב ברירת מחדל שני, והמקרה שבו התהליך יוצא לגמרי נשארים כולם מחוץ לתחום האפשרות.
טפלו בשתי הדרישות בנפרד. שמירה על אובייקט המנהרה בין חיבורים מחדש היא נוחות עבור הדמון. חסימת יציאה כשהמנהרה למטה היא מדיניות חומת אש עם כללים משלה ובדיקה משלה. ערבוב ביניהן מייצר הגדרה שנראית הגנתית ומתנהגת כמו חיבור מחדש במאמץ מרבי.
תנו שם לאירוע לפני שאתם מאבחנים אותו. אתחול רך, ניסיון חיבור שנכשל ועצירת שירות הם שלושה אירועים עם שלושה התנהגויות, ורק הראשון הוא מה שהאפשרויות האלה מתארות.