בדיקת התאוששות שרת VPN לאחר אתחול: מה לבדוק קודם

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

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

לפני האתחול, תנו שם למה שאמור להחזיר את המנהרה. הבדיקה שאתם מריצים והתיקון שאתם מיישמים תלויים שניהם בתשובה הזו, ויש ארבעה בעלים נפוצים: יחידת systemd לשירות ה-VPN, יחידת מופע wg-quick לממשק WireGuard, סביבת הרצה של מכולות, או פרופיל של מנהל הרשת. אם אינכם יכולים לתת שם לבעלים, עצרו ומצאו אותו, כי בדיקת אתחול בלי נתיב הפעלה צפוי רק אומרת לכם שמשהו קרה.

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

קו בסיס קודם, אחרת לתוצאה אין משמעות

תעדו את המצב העובד כל עוד הוא עובד: כתובות על המנהרה, מסלולים לרשת המשנה של הלקוחות, כללי NAT או העברה, השקע המאזין, וה-sysctl של ההעברה. ip addr show wg0, ip route, nft list ruleset או iptables-save, ss -lunp ו-sysctl net.ipv4.ip_forward מספיקים ברוב המארחים.

תעדו איך השירות מוגדר להתחיל, לא רק שהוא פועל. systemctl is-enabled wg-quick@wg0 ו-systemctl is-active wg-quick@wg0 עונים על שאלות שונות, ומצב ההפעלה הוא זה שחשוב באתחול, כמתואר ב-systemctl(1). עבור OpenVPN, בדקו באיזו תבנית המארח משתמש, כי openvpn@server ו-openvpn-server@server הן יחידות שונות עם ברירות מחדל שונות.

הריצו את האתחול וקראו את הכשל הראשון

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

שירות יכול להיות פעיל בזמן שהמנהרה אינה שמישה, וזהו המעבר הכוזב הנפוץ ביותר. ההפעלה יכולה להסתיים לפני שהרשת מקוונת אם היחידה ממתינה רק ל-network.target במקום ל-network-online.target. קבצים שאליהם מפנים, כמו תעודות, מפתחות או CRL, יכולים להיות בלתי קריאים באותו רגע כי עיגון או נתיב סודות עדיין לא מוכנים. אף אחת מהבעיות לא מופיעה ב-systemctl status עד שתקראו את היומן של היחידה.

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

שלושת התנאים שקובעים את התיקון שלכם

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

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

תעדו את התוצאה ב-runbook

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

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