כשל DNS או בעיית MTU? היכן הבקשה באמת נעצרת

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

שני כשלים בשכבות שונות

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

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

אם התסמין שלכם חלקי, הפסיקו להסתכל על DNS.

שלב 1: האם השם נפתר בכלל

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

שאלו את הפותר שמערכת ההפעלה הייתה משתמשת בו, ואז השוו:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

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

שלב 2: היכן ההעברה נעצרת

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

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

תקיעה אחת שניתן לחזור עליה שווה יותר מעשר אנקדוטות.

למה MTU מזיק רק אחרי לחיצת היד

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

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

מדדו את הגודל במפורש במקום להסיק אותו:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

שנו שכבה אחת, ואז הוכיחו את זה

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

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

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