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

תעדו נקודת ביקורת שבאמת תוכלו לשחזר

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

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

שמרו את הביטולים בנפרד מהתצורה

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

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

הגיעו למארח כשהמנהרה נכשלת

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

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

החילו מהדורה אחת ודעו מתי היא נכנסת לתוקף

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

בדקו את הגדרת היחידה לפני הבחירה: systemctl show -p ExecReload openvpn@server אומר לכם אם קיים בכלל וו reload. אחר כך החילו את המהדורה וקראו ביומן את השגיאות החדשות הראשונות לפני שתשנו משהו אחר.

אמתו, תעדו וחקרו לאחר מכן

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

systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager

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

מאמרים קשורים