חבילת IPv6 גדולה מדי: מדוע העברות VPN גדולות נתקעות

הפינג עובד, הדפדפן טוען עמוד קטן והעברת הקובץ נתקעת, הכול דרך IPv6 באותה מנהרה. דפוס כזה בדרך כלל אומר שהשולח מעולם לא למד את גודלו האמיתי של המסלול, ולא שהמנהרה איטית. IPv6 מצפה שהנתבים ידווחו על הבעיה בהודעת Packet Too Big, והעטיפה מוסיפה תקורה לפני שהחבילה בכלל מגיעה לרשת החיצונית. אם ההודעה הזו מסוננת, השולח ממשיך לחזור על גודל שלא יכול לעבור.

בקשות קטנות, תקיעות גדולות

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

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

Packet Too Big הוא משוב, לא תעבורה

הודעת ICMPv6 Packet Too Big נושאת את הגודל שהצעד הבא יכול לקבל, והשולח משתמש בה כדי להוריד את ההערכה שלו. סינון שלה שקול להסרת תמרור ואז האשמת הנהגים. כלל שמפיל את כל ICMPv6 נראה מחמיר ובמקביל שובר גילוי מסלול בכל קישור שזקוק לו. ההודעה היא מידע בקרה על המסלול, לא מטען יישום.

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

בדקו את שתי משפחות הכתובות בנפרד

בדקו IPv6 בנפרד: העברת IPv4 מוצלחת אינה מוכיחה דבר על מסלול IPv6. לאחר מכן לכדו הודעות בקרה בזמן שההעברה הגדולה נתקעת. שתי הרשומות יחד או מראות שהמשוב יוצא, או מוכיחות שהוא מעולם לא הגיע.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

הבדיקה שולחת חבילה עם סיבית do-not-fragment מוגדרת ומדווחת על הגודל שבו היא נכשלת, זה המספר שהמנהרה צריכה להכיל. שאילתת המסלול נוקבת בממשק שיוביל את היעד, כך שאתם יודעים איזה MTU של קישור חל. הלכידה מסננת ICMPv6 מסוג 2, הודעת Packet Too Big, ומראה אם היא מגיעה בכלל למארח הזה. אם ההודעה מופיעה בלכידה וההעברה עדיין נתקעת, השולח מתעלם ממנה, מה שמעביר את החקירה למחסנית ולא לרשת.

כווננו את גודל המנהרה רק לאחר הראיות

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

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