WireGuard נתקע: מגבלת MTU או כלל העברה חסר?
כל דבר מעבר לשרת הוא בעיית העברה או נתיב חזרה. בקשות קטנות שעובדות בעוד גדולות נתקעות הן החתימה של גודל החבילה.
ההרגל הוא להוריד את ה-MTU ברגע ש-WireGuard מתנהג רע, וההרגל הזה מסתיר תקלה אחרת. שער שאינו מעביר ונתיב שאינו נושא חבילות גדולות יוצרים תבניות מובחנות: האחד נכשל בשני הכיוונים ובכל גודל, האחר שורד בקשות קטנות ומת בגדולות. זהה איזו צורה יש לך לפני שתשנה מספר כלשהו. הבדיקה זולה והיא מסירה מחצית מהגורמים האפשריים.
שני כשלים, שתי צורות שונות
בעיית העברה מופיעה מיד מעבר לשרת. לחיצת היד מצליחה, כתובת המנהרה עונה, ושום דבר מאחורי השער אינו נגיש אפילו בבקשה זעירה. החבילה הגיעה לשרת ולא הועברה, או שלתשובה לא היה נתיב חזרה.
בעיית גודל מופיעה רק מעל סף. DNS, לחיצת יד TCP וקריאת API קטנה עובדים, בעוד הורדת קובץ או תשובה גדולה נתקעות. החבילות שהתאימו עברו מקצה לקצה, ואלה שלא התאימו נזרקו במקום כלשהו בלי דוח שימושי.
התיאורים האלה מצביעים על אנשים שונים וקבצי תצורה שונים, ולכן מדידת הצורה שווה יותר מניחוש. פינג בודד לשער אינו יכול להפריד ביניהם.
שלול העברה לפני שאתה מקטין משהו
בדוק יעד מעבר לשער, לא את השער עצמו. פינג לכתובת המנהרה של השרת מוכיח רק שהממשק פעיל ושהוא מגיע למכונה שמסיימת את המנהרה. התעבורה לרשת הרחבה תלויה בהפעלת העברת IP באותה מכונה ובחומת אש שמתירה את הזרימה המועברת. שניהם חייבים להיות נכונים, ואם אחד מהם שקרי נוצר אותו שקט.
ניתוב החזרה חשוב באותה מידה. אם רשת היעד אינה יודעת כיצד להגיע לכתובת המנהרה של הלקוח, הבקשה מגיעה והתשובה נעלמת, והלקוח מדווח על פסק זמן שנראה זהה להעברה שנזרקה.
במקום שבו התכנון משתמש בתרגום כתובות, כלל התרגום הוא חלק מנתיב החזרה הזה. הסרתו בזמן מרדף אחר בעיית MTU הופכת תכנון עובד לתכנון שבור, לכן קרא את הכללים הקיימים לפני שתערוך אותם.
מדוד היכן מתחיל השבר
קרא קודם את מצב ההעברה ואת כללי הסינון. אלה בדיקות לקריאה בלבד והן עונות על השאלה הזולה:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9לאחר מכן בדוק גדלים עם סיבית don’t-fragment, מהלקוח, לעבר מארח מעבר לשער:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9אם הבדיקה הראשונה עובדת והשנייה נכשלת בשגיאת פיצול, הנתיב אומר לך את הגודל השמיש שלו. אם אף אחת אינה עובדת, אתה מסתכל על העברה או ניתוב, וה-MTU אינו המשתנה שיש לשנות.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
תקן את השכבה שהוכחת
כשההעברה היא התקלה, התיקון הוא כלל העברה או נתיב, בניסוח צר ככל שהתכנון מאפשר. כשהגודל הוא התקלה, התיקון הוא MTU שמתחשב בעטיפה בנתיב המסוים הזה, ומוחל על הממשק שזקוק לו ולא על כל מתאם בצי.
בכל מקרה, חזור על אותה משימה מול אותו יעד לאחר מכן. אם ההעברה הגדולה המקורית מושלמת כעת, השינוי טיפל בשכבה שנכשלה. אם רק הבדיקה הקטנה השתפרה, טיפלת בסימפטום והמגבלה האמיתית עדיין במקומה.
רשום איזו צורה ראית לפני השינוי. השורה האחת הזו, שנרשמת לצד התיקון, היא מה שמונע מהאדם הבא להוריד MTU שמעולם לא היה הבעיה.