IPIP בתוך WireGuard: 20 הבתים הנוספים שאיש לא תקצב
IPIP עולה 20 בתים נוספים בתוך WireGuard. עשו את התקציב בשכבה הנכונה לפני שמאשימים את הפיצול בהעברה שנתקעה במנהרה חיה.
פינגים קטנים חוצים את המנהרה כל היום, באנר ה-SSH מגיע, ואז הסשן קופא ברגע שבו מתחילה העברת קובץ. הדפוס הזה מצביע על תקציב בתים שנספר בשכבה הלא נכונה, שבה המנהרה החיצונית תומחרה לפי התקורה של עצמה ואיש לא החסיר את הפנימית. חבילת IPIP מקוננת היא עבור WireGuard רק עוד חבילת IP, וזו בדיוק הסיבה שהיא צורכת בתים שמעולם לא הקציתם. התיקון הוא אריתמטיקה, והוא נכנס לשלוש פקודות ולטבלה אחת.
התסמין שמסגיר את זה
בעיות פיצול מכריזות על עצמן דרך גודל, אף פעם לא דרך כתובות. העמית שלכם עונה ל-ping בגודל 56 בתים במשך שעה ואז משתתק ב-1400 בתים בזמן שהמנהרה נשארת למעלה ואף מסלול לא השתנה. לחיצת היד נכנסת, חלון ה-TCP המלא הראשון לא, וההעברה נתקעת שניות אחרי שהיא נראתה בריאה.
מדדו את התקרה לפני שאתם עורכים משהו, כי תקרה שלא נמדדה היא זו שתרדפו אחריה פעמיים. שלחו בדיקה אחת מתחת לגודל החשוד עם סיבית do-not-fragment מופעלת, ping -M do -s 1000 10.9.0.2, ואז חזרו עליה בגודל שאתם כבר יודעים שהוא גדול מדי. כשההיפוך עוקב אחרי גודל המטען בעוד היעד נשאר ללא שינוי, הניתוב עושה את עבודתו וחסר כותרת בתקציב.
ספרו כל כותרת פעם אחת, בשכבה הנכונה
התחילו מה-MTU הקטן ביותר במסלול ולא מממשק המנהרה, כי הקיר נמצא מעל שתי הקצוות. WireGuard מבזבז 60 בתים על תעבורת IPv4 חיצונית: 20 ל-IP, 8 ל-UDP ו-32 לכותרת שלו עצמו, ו-80 בתים כשהתעבורה הזו היא IPv6. wg0 בגודל 1420 בתים שומר 20 בתים של מרווח מתחת ל-1440 שמסלול בגודל 1500 באמת יכול לספק, ולכן המספר שהועתק מוויקי עדיין מתאים כאן. ציירו את כל המחסנית על התרשים, כי מי שישנה את ה-MTU לאחר מכן יבחר אחרת מספר עגול חדש ויירש את הבאג שלכם.
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
השורה החמישית היא המקום שבו תקציבים משתבשים, כי 1400 הבתים שממשק מקונן נושא כבר כוללים את 40 הבתים של כותרות החבילה המקורית. רק 1360 מהבתים האלה מגיעים לתהליך שקורא את הקובץ. התייחסו ל-1400 כמטען יישום, כפי שכל תרשים בלי העמודה הזו מזמין אתכם, והמכשיר הפנימי נגמר 40 בתים נדיב מדי מול קיר שלא זז.
הגדירו את שני ה-MTU בנפרד
הנשא והמכשיר המקונן הם עצמים נפרדים, ולכן כל אחד צריך ערך משלו. החילו אותם בסדר הזה, כי המכשיר המקונן לא יורש דבר מהנשא:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400הכלל ששווה לזכור: MTU פנימי = MTU חיצוני - 20 כאשר החבילה שהמנהרה IPIP נושאת היא IPv4, ו-40- כאשר כל צד של החבילה הפנימית הוא IPv6, כי הכותרת המקוננת גדלה מ-20 בתים ל-40. שום דבר אחר לא שייך לחיסור הזה. התקורה של WireGuard כבר נוצלה כשבחרתם 1420, וגבייה כפולה שלה מייצרת מנהרה שעובדת באופן מושלם ונשארת איטית כל עוד איש לא מודד אותה. פריסה שבה שני המכשירים נושאים 1400 עגול היא טביעת האצבע של הטעות הזו בדיוק.
IPv6 בכל צד של החבילה המקוננת מבטל כל מספר למעלה, אז חשבו מחדש במקום להעתיק מספר מאתר דומה. הכותרות הנגרעות הן 40 בתים כל אחת ברגע ש-IPv6 מופיע במסלול החיצוני או בדאטגרם המקורי, ומספר המטען יורד בדיוק באותו שיעור.
כלל חומת האש שככל הנראה אינכם צריכים
בין שני עמיתי WireGuard הדבר היחיד על החוט הוא UDP, ולכן כלל נכנס לפרוטוקול 4, המספר ש-RFC 2003 מקצה לעיטוף IPv4-בתוך-IPv4, לא יוצר את המסלול המקונן ולא מחזיק אותו בחיים. כותרת IPIP חיה בתוך המטען המוצפן, שם שום חומת אש קצה לא רואה אותה. פתיחת פרוטוקול 4 בכל זאת לא קונה דבר מלבד דרך מורשית נוספת אל המארח.
מדיניות שמזכירה את המקורות והיעדים של החבילה המקורית שייכת אחרי ביטול העיטוף, על ממשקי המנהרה ובטבלת הניתוב. שימו אותה שם וכלל הקצה יכול להישאר סגור.
מה WireGuard באמת מאמת
AllowedIPs שופט את המקור של החבילה ש-WireGuard נושא, ומה שהוא נושא הוא החבילה שעוטפה ב-IPIP. מקור IPIP מורשה מתקבל גם כשהכותרת שבפנים מציינת מארח שהייתם מעדיפים לא לנתב אליו. לכן המקור המקורי אינו מה שהעמית בדק עבורכם, וזוג הכתובות הפנימי הזה צריך אכיפה משלו אחרי ביטול העיטוף.
העוטף מספק מבנה ניתוב, לא שכבה שנייה של הצפנה. לקרוא ל-IPIP הגנה נוספת בתוך WireGuard מתאר תכנון אחר.
אמתו בסולם, לא בפינג אחד
בדקו גדלים שמקיפים את הגבול שחישבתם, ואז אשרו מה הליבה חושבת על שני המכשירים. עם 1360 בתים של מטען ועוד 40 בתים של כותרות שנותנים 1400, ההד הראשון למטה נכנס והשני יושב בית אחד מעבר לתקרה:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0מעבר נקי מתחת לתקרה וכישלון בגודל הראשון מעליה פירושם שהאריתמטיקה מחזיקה מקצה לקצה. אחר כך הריצו שוב את ההעברה שנתקעה במקור, כי בדיקה מלאכותית מוכיחה את התקציב ואינה אומרת דבר על גדלי הכתיבה של השולח עצמו. אם המסלול המקונן עדיין נשבר בגודל שהוכחתם שנכנס, בדקו את ביטול העיטוף והמסלולים של הקצה הרחוק לפני שמורידים עוד עשרה בתים מה-MTU.