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

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

איזה כיוון נכשל?

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

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

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

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

שינה, רדיו ומצב האפליקציה

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

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

מה keepalive באמת עושה

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

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

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

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

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