ה-Ping של ה-VPN עובד אבל האתר קופא: בדקו את הגודל

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

עברו מהשאלה הקטנה ביותר לגדולה ביותר, ורשמו מה כל שלב באמת הוכיח.

תשובת הד עונה על שאלה קטנה בהרבה

תשובת הד אומרת שמחסנית ה-IP של היעד ענתה לבקשת ICMP מהמקור שלכם. היא לא אומרת דבר על קיומו של מאזין TCP בפורט שאתם צריכים, על כך שמדיניות מתירה את הפורט הזה, או על כך שמארח היעד מסנן תנועה באופן בלתי תלוי בשער. שער שמתיר שירות אחד יכול להפיל אחר בשעה ששתי המטרות עונות ל-ping. קראו את התשובה כעובדה אחת על חבילה אחת וכיוון אחד.

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

גלו אם החיבור התחיל

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

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

מדדו גודל עם מספר מוצהר

כשהתקיעה מופיעה תחת עומס, בדקו גודל חבילה אחד עם ביט איסור הפיצול מופעל והצהירו על החשבון כדי שתוצאה תאמר משהו. בלינוקס עם iputils, מטען של 1392 בייטים בתוספת כותרת ICMP של 8 בייטים וכותרת IPv4 של 20 בייטים יוצר חבילה פנימית של בדיוק 1420 בייטים. הצהירו על החשבון הזה בטיקט, כי ping חשוף שמגיע לשער אינו מוכיח דבר על אפליקציה.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

חשבו את המסלול החיצוני

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

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

שנו מספר אחד ובדקו את האפליקציה שוב

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

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

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