WireGuard שולח נתונים אך לא מקבל דבר בחזרה: איזה צד?
מונה שליחה שעולה הוא כיוון, לא אבחון. החליטו אם הבקשה מעולם לא יצאה מהמנהרה או שהתשובה מעולם לא חזרה, לפני שאתם משנים משהו.
מוני שליחה שעולים בזמן שמונה הקליטה נשאר באפס מתארים כיוון, לא אבחון. אותה קריאה מופיעה כשהעמית מעולם לא השלים לחיצת יד, כשהמטרה בחרה בעמית הלא נכון, כשבצד המרוחק אין נתיב חזרה, וכשמסנן מפיל את התשובה בדרכה הביתה. כל אחד מאלה מתוקן במקום אחר.
ההשוואה שמקצרת את העבודה היא בין בקשה שמעולם לא יצאה מהמנהרה לתשובה שמעולם לא חזרה. לכידה אחת בממשק הנכון מכריעה ביניהן.
המונים מתארים נפח, לא את כיוון התקלה
המונים של WireGuard רושמים מה הממשק מסר לעמית ומה קיבל ממנו. הם אינם אומרים איזו מטרה, איזה עמית או איזה חצי מחילופין נכשל. תנועת רקע הופכת את הסכומים לפחות מאלפים עוד יותר, שכן חלק מהבתים עשויים להיות הודעות שמירת קשר או זרמים לא קשורים. קראו אותם כסימן שהממשק פעיל, ואז הפסיקו להתייחס אליהם כראיה.
העובדה השימושית הראשונה היא אם לחיצת היד עדכנית. בלעדיה לא הוצפן דבר עבור העמית הזה ולמונה הקליטה אין סיבה לזוז.
בחירת עמית או נתיב התשובה: שני הסברים
ההסבר הראשון הוא שהמנותב לא הגיע מעולם לעמית המיועד, משום שהנתיב הצביע למקום אחר או שהקידומות המותרות של העמית לא כיסו את המטרה. השני הוא שהמנותב הגיע והתשובה לא יכלה לחזור, וזו בעיית ניתוב בקצה המרוחק. הטבלה מפרידה ביניהם לפי מה שתצפו בכל נקודה.
| Observation | Points to |
|---|---|
| No handshake while transmit climbs | Peer selection or endpoint |
| Handshake current, request visible on the server | Reply path or far-side route |
| Request never visible on the server | Allowed prefixes or local route |
| Both packets visible, nothing reaches the client | Return filter or translation |
קראו את הטבלה מלמעלה. לחיצת יד חסרה שולחת אתכם למפתחות, לנקודות קצה ולנתיב החיצוני, משום שעדיין אין שום דבר אחר לבחון. לחיצת יד עדכנית כשהבקשה נראית בשרת מעבירה את הבעיה לכיוון החזרה, שם מכריעה טבלת הניתוב של המטרה עצמה. בקשה שלעולם אינה מופיעה בשרת היא בעיית בחירה, והקידומות המותרות בשני העמיתים הן הדבר הראשון שיש להשוות.
שתיים מארבע השורות האלה מתוקנות בלקוח ושתיים בשרת. הידיעה באיזה זוג אתם נמצאת היא רוב העבודה.
היכן נעלמות התשובות
תשובה יוצאת מהמטרה, מגיעה לממשק המנהרה של השרת ומוצפנת עבור העמית שכתובותיו המותרות תואמות לכתובת הפנימית של הלקוח. אם ההתאמה הזו נכשלת, התשובה נזרקת בשקט, מה שנראה מצד הלקוח בדיוק כמו תקלת רשת. אם התשובה מוצפנת והמסנן של הלקוח עצמו דוחה אותה, התסמין שוב זהה. שני המקרים זקוקים ללכידה ולא למונה.
הצורה החזקה ביותר של הטעות הזו היא שרת שמעביר מנות עבור הלקוח אך אין לו נתיב חזרה לטווח הפנימי של הלקוח. הוא מקבל את הבקשה, שולח את התשובה לעבר שער ברירת המחדל שלו, והמנהרה לעולם אינה רואה אותה. כלל תרגום רחב שנוסף לשרת מסתיר את התקלה במקום לתקן את הנתיב.
בדקו מטרה אחת מקצה לקצה
בחרו מטרה אחת בתוך הטווח של העמית, ובדקו אותה כשהלחיצה מוכחת כעדכנית. הפקודות שלמטה קוראות את מצב העמית, את הנתיב הנבחר ואת שני צדי החילופין. הריצו את הלכידה בממשק שבו המנות המוצפנות משתמשות בפועל.
wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5לכידה שמראה את הבקשה בממשק המנהרה בלי שום דבר שחוזר היא תשובה מצד השרת, ואילו טבלת הניתוב של המטרה היא המקום הבא להסתכל בו. אם לא מופיע דבר כלל, המנותב עבר בנתיב אחר, ולכן הנתיב המקומי הוא החשוד. חילופין שנראים בשתי הלכידות בלי התקדמות ביישום מעבירים את השאלה לגודל המנות או למסנן שסטטיסטיקת הממשק אינה מראה לעולם. השאירו מטרה אחת ולקוח אחד בבדיקה, כי משתנה שני הופך ראיה חזרה לרושם.
אם שמות נכשלים בזמן שכתובת מורשית עובדת, התשובה נמצאת ב-DNS ולא במנהרה. אם רק העברות גדולות נתקעות, בחנו את גודל המנות בנפרד.