עמית WireGuard אינו נגיש בעוד אחר עובד: רשימת בדיקה

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

שלב 1: רשום את הנתיב שהחבילה אמורה לעבור

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

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

שלב 2: השווה AllowedIPs בשני הצדדים, לא רק באחד

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

קרא את המצב החי ולא את הקובץ, כי טעינה מחדש עשויה להיכשל בשקט: sudo wg show wg0 allowed-ips. בשרת הרשומה של העמית שנכשל חייבת לכלול את כתובת המנהרה שלו, למשל 10.90.0.3/32. בלקוח הרשומה של עמית השרת חייבת לכלול את היעד שאתה בודק, בין אם זו כתובת המנהרה של הרכזת ובין אם תת-הרשת המרוחקת. טווחים חופפים הופכים את החיפוש לדו-משמעי ועלולים לבחור עמית שלא התכוונת אליו, לכן שמור אותם נפרדים.

שלב 3: בדוק את כתובת המקור הפנימית

לקוח שמנתב את 10.90.0.3 דרך wg0 אך שולח חבילות מכתובת ה-Wi-Fi שלו יידחה בידי המקבל, כי המקור אינו תואם ל-AllowedIPs של העמית. אמת מה הגרעין באמת בוחר עם ip route get 10.90.0.3 from 10.90.0.2, ואמת את הכתובת שהוקצתה לממשק המנהרה עם ip -brief addr show wg0.

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

שלב 4: סקור את ההעברה ברכזת ואת נתיב החזרה

אם הרכזת צריכה להעביר בין עמיתים, הגרעין זקוק ל-net.ipv4.ip_forward=1, וחומת האש חייבת לקבל את הזרימה המועברת: כניסה ב-wg0, יציאה ב-wg0, מכתובת המנהרה של השולח לזו של המקבל. כשל נפוץ הוא כלל כניסה שמקבל UDP 51820 אך אין כלל העברה], ולכן לחיצת היד מצליחה והמטען מת. רשום את הכללים האפקטיביים עם sudo nft list ruleset או המקביל לו במנהל חומת האש שלך.

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

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

שלב 5: שנה דבר אחד ושמור על העמית שעובד ללא פגע

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

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