למה חסימה של כל ה-ICMP שוברת נתיב VPN שעובד
הודעות משוב על גודל אינן תשובות ping. כשהן לא מגיעות לעולם, מנות קטנות עוברות, גדולות נעלמות, והמנהרה נראית כמהבהבת.
מנהרה שמבצעת אימות, נושאת ping ואז נתקעת בהעברה הגדולה הראשונה היא הסימן הקלאסי להודעת ICMP חסרה ולא ל-VPN שבור. השולח לעולם לא לומד שהמנה הייתה גדולה מדי, מנסה שוב באותו גודל, והאפליקציה ממתינה. תיקון זה הוא החלטת מדיניות של חומת האש, לא התקנה מחדש של הלקוח. הסדר חשוב: מדדו היכן נמצא גבול הגודל, ואז צמצמו את הכלל שבלע את הדוח.
מה ICMP באמת נושא בנתיב הזה
גילוי MTU של נתיב IPv4 נשען על כך שנתב מדווח שמנה עם סיבית don't-fragment לא ניתן היה להעביר. הדוח הזה הוא הודעת ICMP Fragmentation Needed, ובלעדיו אין לשולח סיבה להקטין את גודל המקטע שלו. IPv6 מחמיר יותר: נתבים אינם מפצלים בתעבורה, ולכן הודעת ICMPv6 Packet Too Big היא האות היחיד שמגרום לשולח להתכווץ.
שתי ההודעות הן משוב של מישור הבקרה, ואף אחת מהן אינה הד תיעודי. מדיניות שחוסמת ping ומדיניות שחוסמת את כל ה-ICMP נראות דומות ברשימת כללים אך מתנהגות אחרת לגמרי ברשת. השנייה יכולה להפוך מנהרה בגודל נכון לנתיב חד-כיווני לכל דבר הגדול מהחוליה הקטנה בשרשרת.
חלק מהתעבורות מיישמות גילוי משלהן עם מנות בדיקה, כפי ש-RFC 4821 מתאר, והן תלויות פחות במשוב הזה. זהו נימוק לבדוק איזו תעבורה אתם מריצים, לא להניח שכל מנהרה חסינה.
| הודעה | מטרה בנתיב | אם נחסמת |
|---|---|---|
| ICMPv4 סוג 3 קוד 4 | המנה הייתה גדולה מדי לחוליה הבאה | השולח ממשיך לנסות ונתקע |
| ICMPv6 סוג 2 | Packet Too Big, המקבילה ב-IPv6 | אותה תקיעה, בלי חלופת פיצול |
| ICMP סוג 11 | הזמן חרג, משמש את traceroute | האבחון מאבד קפיצות, התעבורה ממשיכה לזרום |
| בקשת הד ICMP ותשובה | בדיקת נגישות | ping נכשל, הנתיב עשוי להיות תקין |
הכשל תלוי בגודל
שאלו אם הכשל מתואם עם גודל המנה. דף התחברות, שאילתת DNS וקריאת API קצרה עוברים, בעוד העלאת קובץ, תשובה גדולה או הורדת תמונה נתקעות. התבנית הזו מצביעה על מגבלת גודל אי שם בין שני הקצוות, לא על אימות או ניתוב. ping קטן מוצלח כמעט אינו אומר דבר על מקום הגבול הזה.
בתוך מנהרה יש שתי שכבות לשקול: מנת המטען ומנת המעטפת החיצונית. השולח הפנימי יכול להתנהג נכון בעוד הנתיב החיצוני קטן ממה שהמנהרה מניחה, ולכן גם הגדרת ה-MTU של המנהרה עצמה וגם החוליה הפיזית שמתחתיה חשובות.
מדדו לפני עריכת כללים
בדקו עם סיבית don't-fragment ועם גודל מטען שאתם בוחרים, מהלקוח הכושל לעבר כתובת מוגנת:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7מטען של 1472 בתים ועוד 28 בתים של כותרות הוא מנה של 1500 בתים. אם הבדיקה הגדולה נכשלת עם שגיאת פיצול והקטנה עוברת, מצאתם את הגבול; התאימו לתקורת המנהרה וחזרו עד שהגודל העובד יציב.
אחר כך ודאו שהפער הוא הדוח עצמו. אם הבדיקה נכשלת בשקט, בלי שגיאה ובלי תשובה, ההודעה כנראה נזרקת ולא נמסרת, והכלל הוא החשוד.
צמצמו את הכלל, ואז בדקו שוב את המשימה
התיקון צריך לאפשר את הודעות הבקרה הספציפיות, לא את כל הפרוטוקול. במארח iptables הצורה היא אישור לפי סוג; התאימו את התחביר למה שמנהל את חומת האש בפלטפורמה שלכם:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTהשאירו את תשובות ההד חסומות אם זו המדיניות המקומית, כי הנתיב לא זקוק להן. אחר כך בדקו שוב את ההעברה שנכשלה במקור, מחיבור חדש, וודאו שמוני הכלל מראים את ההודעות מגיעות.
אם ההעברה הגדולה עדיין נתקעת לאחר שההודעות הותרו, המגבלה שנותרה נמצאת במקום אחר: MTU של מנהרה שהוגדר גבוה מדי, פרוקסי שמשכתב מנות, או תיבת ביניים שזורקת במקום לדווח. כלל ה-ICMP היה הכרחי, לא מספיק.