תיקון נפילות VPN בזמן חוסר פעילות: רשימת בדיקה לחיסכון בחשמל של Wi-Fi

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

בדיקה ראשונה: האם הנפילה עוקבת אחרי חוסר הפעילות?

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

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

בדיקה שנייה: האם זו רק תעבורת VPN?

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

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

בדיקה שלישית: קראו את מצב חיסכון החשמל

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

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

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

ב-Windows powercfg /q SCHEME_CURRENT מדפיס את הסכימה הפעילה, ועץ המשנה של מתאם האלחוט מראה אם אפשר להורות למתאם לחסוך בחשמל; אותה אפשרות נמצאת גם ב-Device Manager בלשונית ניהול החשמל של המתאם. ב-macOS חיסכון החשמל של 802.11 לכל ממשק אינו חשוף לכם, אז הביטו במקום זאת ב-pmset -g להתנהגות שינה והמתנה. שם התקלה מתגלה בדרך כלל בנתיב השינה וההתעוררות ולא בהתנהגות חוסר הפעילות של הרדיו.

בדיקה רביעית: שנו דבר אחד, ואז בדקו שוב

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

השארת החיבור בחיים היא המשתנה הבלתי תלוי השני והיא מוטעית כל הזמן עם חיסכון בחשמל. ה-PersistentKeepalive = 25 של WireGuard שומר על מיפוי NAT חם;OpenVPN בשני הקצוות keepalive ו-ping-restart משתמש. שניהם מייצרים תעבורה במנהרה שאחרת שקטה, כך שהשארת חיבור בחיים שנראית כאילו היא מתקנת את הנפילה עשויה להסתיר בעיית רדיו במקום לפתור אותה. בדקו אותם בנפרד, אחד בכל פעם:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

בדיקה חמישית: כשהרדיו חף מפשע

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

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

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

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

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

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