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

ארבעה מועמדים וצורה אחת

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

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

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

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

חצה את הגודל לפני שנוגעים במדיניות

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

ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/upload

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

CandidateObservation that confirms itObservation that rules it out
Path MTU or blocked ICMP feedbackStall at a consistent size; large do-not-fragment probes failSmall and large transfers both complete
Name resolutionThe connection never opens for that nameThe connection opens and then stalls mid-transfer
Application or proxy limitA clean rejection at a documented sizeNo log entry on the server at all
Tunnel instabilityReconnects or rekeying during the transferThe tunnel uptime is unchanged across the failure

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

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

החלט בין תיקון לבין עקיפה

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

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

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

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

תעד את ההחלטה כדי שתשרוד את התקרית הבאה

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

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

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

מאמרים קשורים