VPN מת אחרי שינה: מנהרה שאבדה או אפליקציה מיושנת?

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

שלושה דברים יכולים להישבר אחרי היקיצה

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

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

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

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

ראשית: האם המנהרה חזרה?

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

ip -brief addr show
wg show
ip route show table all | head -20

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

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

שנית: האם משהו ביקש ממנה לחזור?

כאן ההשוואה מצדיקה את עצמה. פרופיל תוסף OpenVPN וחיבור WireGuard מקורי מטופלים אחרת ב-NetworkManager, וכן עיון הגדרות החיבור מבהיר ש-connection.autoconnect אינו מפעיל פרופילי VPN; המנגנון להעלאת VPN עם חיבור הוא connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

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

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

שלישית: האם האפליקציה מחזיקה מצב ישן?

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

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

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

הפכו את ההשוואה לניתנת לשחזור

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

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

ה-keepalive המתמשך של WireGuard שייך לתמונה הזאת רק כ-keepalive של מיפוי NAT. הוא שולח מנות כדי להחזיק מיפוי פתוח; הוא לא מונע מהמכונה להירדם ולא יכול להמשיך לשלוח בזמן שהתהליך מושהה.

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