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

שלב ראשון: לתעד את המרווח ואת טקסט השגיאה

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

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

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

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

שלב שני: לשנות משתנה אחד, לא את הפרופיל

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

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

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

שלב שלישי: למפות את המרווח לשכבה

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

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

במקרה של חוסר פעילות, ההגדרות תלויות בפרוטוקול ושתי הקצוות חשובים. keepalive 10 60 של OpenVPN בשרת שולח פינג כל 10 שניות ומפעיל מחדש את הקישור אחרי 60 שניות בלי אחד; לקוחות WireGuard מאחורי NAT משתמשים ב-PersistentKeepalive = 25 בבלוק העמית. OpenVPN גם מנהל מחדש את ערוץ הנתונים לפי טיימר, reneg-sec, שב-2.x ברירת המחדל שלו היא 3600 שניות.

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

שלב רביעי: להשוות חלופה נתמכת אחת

אם המפעיל מפרסם גם פרופיל UDP וגם פרופיל TCP, הריצו את אותו מכשיר ואותה רשת מול האחר. השתמשו בקובץ המתאים האמיתי במקום לערוך את התעבורה בפרופיל מועתק. פרופיל TCP יציב בנתיב שבו UDP מתאפס מצמצם את הבעיה לנתיב הזה; הוא לא מוכיח ש-TCP הוא התעבורה הטובה יותר בכל מקום.

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

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

לאמת את התיקון, ולשמור את האפשרות לחזור

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

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

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

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

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