Windows L2TP טוען חלק מהאתרים: נקו את סיבית DF ב-pfSense

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

התחילו מהעמודים שנכשלים

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

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

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

מה סיבית DF עושה ביציאה

העמלה היא הסיבה לכך שהמספרים שונים. IPsec מוסיף ESP, ו-L2TP מוסיף כותרת נוספת, ולכן המנהרה נושאת פחות מטען מהקישור הפיזי. Windows עדיין מדווח 1500 בייט במתאם ומגדיר «אל תפצל» על מה שהוא שולח. כשחבילה כזו לא נכנסת, התשובה הנכונה מהשער היא הודעת ICMP שמבקשת מהשולח להקטין. לכן מנהרה שמעבירה פינגים קטנים עדיין עלולה להיכשל בהורדת קובץ.

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

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

אפשרות ה-pfSense, ומה היא לא עושה

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

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

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

תיקון צר יותר ששומר על TCP לא מפוצל

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

זה משאיר את UDP לגילוי או לאפשרות DF. כשהאתרים שנכשלים הם עמודי אינטרנט רגילים, ההגבלה היא השינוי שיש להעדיף.

הלקוח יכול לדווח על ה-MTU של המתאם שלו דרך netsh interface ipv4 show subinterfaces. השוו את המספר הזה למה שהשרת חושב שסוכם, כי השניים לא תמיד זהים. הערך הזה הוא מה שמערכת ההפעלה תשתמש בו בפועל, יהיה אשר יהיה מה שהמשא ומתן דיווח.

אמתו בצילום ואז אפסו את המצב

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

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