WireGuard PersistentKeepalive: שמרו על מיפוי NAT חי
אם החיבור ההפוך עובד רק מיד אחרי שהעמית שולח תעבורה, המיפוי פג. הגדירו keepalive מאחורי הנתב ואז קראו את פסק הזמן האמיתי.
תיבת הבית פותחת את המנהרה ומגיעה לשרת הענן בלי בעיה. שרת הענן יכול להגיע לאפליקציית הבית במשך דקה או שתיים אחרי שתיבת הבית שלחה משהו לאחרונה, ואז הוא מפסיק. שום דבר לא מופיע ביומן של WireGuard, לא מדווחת שגיאת לחיצת יד, והפעלה מחדש של המנהרה מתקנת את זה לזמן קצר. התבנית הזו היא מיפוי שפג, לא מנהרה שבורה, והמדריך למטה מאשר זאת לפני שמשנים משהו.
אשרו שהתבנית היא פקיעת מיפוי בחוסר פעילות
הפרט המבחין הוא התזמון. אם החיבור ההפוך עובד מיד אחרי שעמית הבית שולח תעבורה ונכשל אחרי מרווח שקט, הנתיב תקין והמצב באמצע אינו. אם הוא מעולם לא עבד, אפילו מיד אחרי תעבורה, זו אבחנה שגויה.
sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transferהריצו את שתי הפקודות הראשונות מיד אחרי שעמית הבית שולח משהו, המתינו חמש דקות והריצו אותן שוב. חתימת זמן של לחיצת יד שמתחדשת לפי לוח הזמנים בלי נקודת קצה חדשה אומרת לכם שהמנהרה חיה. מה שהשתנה הוא היכולת של מנות לא מבוקשות להגיע מבחוץ, וזו תכונה של הנתיב ולא של המנהרה.
אחר כך נסו ניסיון הפוך וצפו במוני ההעברה. אם צד הענן שולח בייטים וצד הבית לא מקבל אף אחד, המנה עזבה את הענן ומתה בהתקן ששומר מצב בדרך. זו החתימה שאתם מחפשים. אם שני המונים זזים, המנהרה מסרה את המנה והאפליקציה היא החשודה.
שימו את ה-keepalive על העמית שמאחורי הנתב
keepalive מתמשכים שומרים על מיפוי NAT ועל כל מצב חומת אש חיים על ידי שליחת מנה קטנה מאומתת לפי לוח זמנים. ההגדרה שייכת למכונה שמאחורי הנתב, בערך שלה עבור העמית המרוחק, כי זה הצד שהמנה היוצאת שלו יוצרת את המצב.
[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25מזגו אותו לסעיף העמית הקיים. הוספת בלוק שני עם אותו מפתח ציבורי אינה דרך תקפה להוסיף אפשרויות, ו-wg-quick לא ימזג אותן עבורכם. 25 השניות המתועדות הן דוגמה שנבחרה כדי לשבת מתחת לפסקי הזמן הנפוצים של UDP, לא ערך עם משמעות מיוחדת.
הצבת אותה הנחיה בצד הענן לא עוזרת לבעיה הזו. המנות של העמית הזה כבר מגיעות מכתובת ציבורית, כך שאין מיפוי לשמר בכיוון שחשוב. זה מוסיף תעבורה ולא משנה דבר.
קראו את הטיימרים במקום לנחש מרווח
keepalive עובדים כי הם מגיעים לעתים קרובות יותר ממה שהמצב פג. זה הופך את פסק הזמן למספר שבאמת צריך, וב-Linux אפשר לקרוא אותו בהתקן שעושה את התרגום:
sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820הערך הראשון הוא פסק הזמן לזרם UDP שנראה רק בכיוון אחד, והשני חל לאחר שנצפו תגובות. שניהם בדרך כלל קצרים, ומיפוי שנשתתק ילך לפי מה שחל על הזרם שלכם.
השוו את המספר הזה למרווח שלכם. keepalive של 25 שניות תחת פסק זמן של 30 שניות עובד; אותו keepalive תחת פסק זמן של 15 שניות לא עובד. שום כמות של ניסיונות חוזרים לא משנה את החשבון הזה. חלק מהנתבים הביתיים ומהמפעילים הסלולריים משתמשים בערכים קצרים בהרבה מברירת המחדל של Linux, ולכן תצורה שעובדת ברשת אחת נכשלת ברשת אחרת.
| Observation | What it means | Reasonable response |
|---|---|---|
| Works after traffic, dies when idle | Mapping or firewall state expiring | Lower the keepalive interval |
| Never works, even immediately | No return route, listener or firewall | Stop tuning keepalive |
| Works for hours, then dies once | Carrier-side translation or address change | Check the endpoint and logs together |
בדקו את המאזין ואת חומת האש בנפרד
מיפוי חי הוא הכרחי ולא מספיק. האפליקציה בתיבת הבית חייבת להאזין בכתובת הנכונה, וחומת האש של המארח חייבת לאפשר את המנה לאחר פענוחה.
sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/healthאם השקע קשור רק לכתובת הממשק הפיזי ולא לכתובת המנהרה, מנות שמגיעות במנהרה נזרקות לפני שחומת האש נשאלת בכלל. הכשל הזה נראה מצד הענן בדיוק כמו בעיית מיפוי, והוא שורד כל התאמת keepalive.
בדיקת הרשימה המאושרת חשובה באותה מידה בכיוון השני. עמית הענן חייב לאשר את כתובת מנהרת הבית כמקור אם הוא עומד להשיב, ועמית הבית חייב לאשר את כתובת הענן כיעד. מנות keepalive הן תעבורה מאומתת והן מיישמות את אותם כללים, ולכן keepalive שנראה עובד יכול להתקיים לצד אפליקציה שאינה עובדת.
פרסו את השינוי והכירו את גבולותיו
החילו את ההגדרה, הפעילו מחדש את הממשק אם זו שיטת העדכון שלכם, ואז חזרו על מבחן חוסר הפעילות ולא על המבחן המיידי. המתינו יותר מפסק הזמן שקראתם קודם, בצעו בקשה הפוכה ואשרו שהמונים זזו בשני הקצוות.
רשמו את המרווח ואת פסק הזמן שמדדתם לצידו. שינוי עתידי בקושחת הנתב, או מעבר לחיבור סלולרי, יכול לשנות את פסק הזמן. ההערה היא מה שמאפשר למישהו לגזור את הערך מחדש במקום להעתיק אותו. שני מספרים בשורה חוסכים חקירה שלמה אחר כך.
keepalive מתמשכים מגנים על מצב. הם לא פותחים פורט, הם לא מוסיפים רשומה לרשימה המאושרת, והם לא גורמים למאזין להופיע. כשהחיבור ההפוך לא עובד בכלל, האשמה היא באחד משלושת אלה: המדריך המהיר של WireGuard מתאר את הגדרת ה-keepalive באותם מונחים צרים.