מנהרות VPN מקוננות: מדוע הפנימית נתקעת בחבילות גדולות
כל מנהרה מוציאה חלק מתקציב החבילות של הנתיב לפני שהבאה מתחילה. חברו את הכותרות והפעלת הפנים נכשלת בחבילות גדולות.
DNS נפתר, הפעלת SSH נשארת, ואז העלאה גדולה קופאת בעוד ping לאותו מארח עדיין עונה. הפיצול הזה מצביע על גודל החבילה ולא על מנהרה שבורה. מנהרות מקוננות מגיעות לכך בגדלים שאף אחת מהמנהרות לא הייתה מגיעה אליהם לבדה. הפעלת הפנים תקינה; פשוט מוסרים לה חבילות שכבר לא נכנסות.
לאן באמת הולך ה-MTU של הנתיב
כל עטיפה מוציאה בתים לפני שהשכבה הבאה מקבלת תור. נתיב Ethernet מציע 1500 בתים לחבילה החיצונית, והמנהרה החיצונית לוקחת את חלקה לפני שאפשר להפנות משהו שבתוכה. ערך תקורה משוער אחד יהיה שגוי בדיוק בכמות שקובעת.
רשמו את השכבות לפי הסדר: נתיב גישה, תעבורה חיצונית, מנהרה חיצונית, תעבורה פנימית, מנהרה פנימית, יישום. ספרו כל כותרת פעם אחת, והפרידו את UDP מהכותרת והתג של המנהרה עצמה.
שתי שכבות WireGuard, נספרות פעם אחת
קחו נתיב גישה IPv4 עם מנהרת WireGuard אחת בתוך אחרת. השכבה החיצונית עולה 20 בתים של IPv4, 8 של UDP ו-32 עבור כותרת הנתונים של WireGuard בתוספת תג האימות שלה. בתוכה, המנהרה הפנימית צריכה כותרת IPv4 משלה בת 20 בתים וכותרת UDP בת 8 בתים לפני 32 הבתים השניים של תקורת WireGuard. מה שנשאר מכיל כותרת IPv4, כותרת TCP והנתונים. נתיב חיצוני IPv6 עולה 40 במקום 20 ומשאיר 1320.
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
החשבון נוחת על 1340 בתים. שכבה אחת לפי אותם כללים משאירה 1400 למטען השימושי של TCP, כלומר 1500 פחות 20, 8, 32, 20 ו-20, וההפרש של 60 בתים הוא בדיוק העטיפה הפנימית שהמנהרה השנייה מוסיפה.
החילו 1400 על נתיב מקונן והמנהרה הפנימית חסרה 60 בתים, באופן בלתי נראה עד שהחבילה גדולה מספיק כדי להזדקק להם. ריפוד ואפשרות הפיצול של הפרוטוקול עצמו מזיזים את המספרים שוב, אז סמכו על הטבלה.
MTU, MSS ופיצול פועלים במקומות שונים
ה-MTU של הממשק מגביל את מה שהממשק יפלוט, בעוד הידוק ה-MSS של TCP משנה את מה שעמית TCP מוכן לשלוח. הידוק מתקן הפעלות TCP ואינו עושה דבר לדאטגרם UDP גדול, וכך תיקון נראה מוצלח ליישום אחד ומפספס בשקט את הבא. אפשרות הפיצול של הפרוטוקול עצמו היא מנוף שלישי עם כשלים משלו. ה-MTU של הממשק הוא הצעד הראשון הנפוץ והגס ביותר.
מנהרות מגושרות ומנותבות נושאות מסגרות שונות, ולכן מספרים מפריסה אחרת כמעט אינם עוברים. גילוי ה-MTU של הנתיב, המתואר ב RFC 8201, עוזר רק כל עוד הודעות ה-ICMP שהוא תלוי בהן מורשות לעבור.
למצוא את השכבה שחסרה
אמתו כל מנהרה בנפרד לפני קינון, אם הדרישות מאפשרות השוואה. בדיקה בגודל קבוע מכריעה את זה: ping -M do -s 1472 -c 3 10.8.0.1 שולחת חבילת IPv4 מלאה של 1500 בתים בתוך אותה שכבה. הוסיפו את השכבה השנייה וחזרו על אותה בדיקה, כך שכל כשל שייך לשינוי ידוע.
כשהעברה נתקעת, שנו פרמטר מתועד אחד בכל פעם ורשמו את הגודל שנכשל. בדקו גם את נתיב החזרה, כי רקורסיית מסלולים מקוננת יכולה לחקות בעיית גודל חבילה קרוב מספיק כדי לעלות אחר צהריים שלם. תגובת ICMP מסוננת יכולה להסתיר את הגבול האמיתי, ולכן הבדיקה חשובה יותר מההיסק.
כתבו את התקציב במקום שבו האדם הבא ימצא אותו
טבלה עם שורה לכל שכבה שורדת יותר מכלל אצבע. החזיקו אותה ליד תרשים המנהרה כדי שלא ייחשב שוב החשבון תחת לחץ.
יותר מנהרות משמעותן יותר תלויות, ולכן תוכנית נסיגה זוכה למקומה לצד התקציב. אם המספרים עדיין לא מסתדרים, מדדו את הנתיב במקום לנחש שוב. המטרה היא מספר שתוכלו להגן עליו, לא לזכור.