למה VPN נתקע בהעברות גדולות אבל לא בקטנות

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

שלושה מספרים שאנשים קוראים להם MTU

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

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

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

בדקו את הנתיב עם מטען שאתם שולטים בו

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

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

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

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

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

כיווץ MSS עוזר רק ל-TCP

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

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

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

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

OpenVPN חושף אפשרויות כמו tun-mtu, mssfix והגדרות הקשורות לפיצול, וההתנהגות שלהן תלויה בגרסה ובשאלה אם ערוץ הנתונים הוא AEAD. קראו את המדריך של הגרסה שבשימוש, ושנו אפשרות אחת בכל פעם.

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

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

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

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