כוונון MSS של TCP בשער IPsec של לינוקס: מה הוא מתקן

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

התסמין שמרמז על MSS

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

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

מה כלל TCPMSS עושה ומה הוא לא עושה

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

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

שימו את הכלל בנתיב ה-TCP הפנימי

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

במונחים של iptables, הכלל שייך לטבלת mangle בנתיב ההעברה, מוגבל לחבילות לחיצת יד: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. המספר הוא דוגמה, לא קבוע אוניברסלי; גזרו אותו מעומס העטיפה ומה-MTU האמיתי של הנתיב. מקבילה ב-nftables קובעת את גודל המקטע המרבי בשרשרת forward או postrouting.

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

כבדו את הבעלים של חומת האש ואת סדר ה-NAT

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

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

אמתו באופן צר, ואז עצרו

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

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