WireGuard עובד רק אחרי שהשרת שולח: ידיעת נקודת הקצה
הצלחה שתלויה בכיוון בדרך כלל אומרת שצד אחד מעולם לא למד את הכתובת של האחר. השוו נקודות קצה, ואז בדקו אם מיפוי תרגום פג.
נראה שהמנהרה עובדת רק אחרי שהשרת שולח משהו קודם. התחילו מהלקוח ושום דבר לא קורה, המתינו כמה שניות, נסו שוב וזה מצליח. האבחנה הרגילה היא NAT שבור, והאבחנה הרגילה שגויה. מה שהשתנה הוא שצד אחד למד איפה השני גר.
ידיעת נקודת הקצה, לא נגישות
צד ב-WireGuard לא יתחיל לחיצת יד עד שהוא יודע לאן לשלוח אותה. התצורה מספקת זאת כנקודת קצה של כתובת ופורט, והמצב בזמן ריצה עוקב אחרי נקודת הקצה שהוא מאמין בה כעת.
wg show מדפיס את שני הצדדים של התמונה הזאת, וצד בלי נקודת קצה בפלט לא יכול להתחיל דבר, עד כמה שהמפתח הציבורי והקידומות המותרות שלו נכונים. השוו את תפיסת הלקוח לזו של השרת לפני שתשנו כלל, כי השניים לעתים קרובות אינם מסכימים מי יודע מה.
איך צד לומד נקודת קצה
WireGuard שקט במכוון. כשהופך חבילה מאומתת כהלכה מגיעה מכתובת שהצד לא ציפה לה, המימוש מעדכן את נקודת הקצה של אותו צד למקור החדש, וכך עובד נדידה במחשב נייד שמחליף רשתות. ההתנהגות הזאת מסבירה את התלות בכיוון: אם השרת שולח ראשון והחבילה שלו מגיעה ללקוח, הלקוח לומד את הכתובת הנוכחית של השרת ויכול לענות. עד אז אין לו לאן לשלוח. המנגנון הוא נדידה מאומתת ולא קיצור דרך של אמון בשימוש הראשון, כי החבילה הייתה חייבת להיות תקפה לפני שנקודת הקצה זזה.
התיעוד של הכלים עבור wg מתאר את העדכון הזה, וכדאי לקרוא אותו פעם אחת אם אתם מתכננים סביבו.
תרגום עם מצב מוסיף כיוון משלו
כשה-UDP עובר דרך שער שמתרגם, השער יוצר מצב עבור החבילה הראשונה שהוא רואה. RFC 4787 מתאר את ההתנהגות הזאת ואת פסקי הזמן שבסופו של דבר מסירים את המיפוי. מיפוי לא פעיל פוג, וחבילה נכנסת מהצד הרחוק נזרקת אז על ידי השער לפני שהיא מגיעה למארח. מנהרה שעבדה כל הבוקר מפסיקה לענות אחר הצהריים בדיוק מהסיבה הזאת.
זהו מנגנון שני ועצמאי שמייצר את אותו סימפטום כיווני. גם ידיעת נקודת הקצה וגם מצב התרגום חייבים להיות נכונים, ותיקון אחד לא מתקן את השני.
הגדירו את הכיוון שאתם באמת רוצים
עבור לקוח שחייב להתחיל את החיבור, שימו את נקודת הקצה של השרת בקטע הצדדים של הלקוח והשאירו אותה שם. הסתמכות על כך שהשרת ישלח ראשון היא הסתמכות על מקרה בסדר התעבורה שישתנה ברשת שקטה. התצורה צריכה להצהיר על הכיוון המיועד, לא לגלות אותו.
עבור צד מאחורי תרגום שחייב להישאר נגיש, הפעילו keepalive מתמשך בצד הזה. keepalive כל 25 שניות הוא ערך ההתחלה הרגיל, ומטרתו להחזיק את המיפוי פתוח ולא לבחון את המנהרה. בחרו צד אחד שיישא אותו, כי הפעלה בשני הצדדים מכפילה את התעבורה ואת הרעש ביומן בלי לשפר את התוצאה.
השוו את המצב לפני ואחרי הטריגר
תעדו את שתי התצוגות ברגע שנכשל, ואז שוב אחרי שהשרת שולח. הפקודה הראשונה מציגה נקודות קצה ואת גיל לחיצת היד. השנייה מראה אם קיים רשומת תרגום עבור הפורט. הלכידה מראה איזה כיוון באמת חצה את הכבל, ובדיקת המסלול מאשרת שהלקוח לא שולח את התעבורה הזאת למקום אחר לגמרי.
wg show conntrack -L -p udp 2>/dev/null | grep 51820 tcpdump -ni any -c 20 'udp port 51820' ip route get 198.51.100.7
רשמו את עמודת נקודת הקצה ואת רשומת התרגום יחד. צד בלי נקודת קצה ושער בלי מיפוי הם שני כשלים שונים. רק אחד מהם מתוקן על ידי keepalive.