רוטר - עזרה לגבי TCP עם time to live exceeded fragment reassembly

יומן פעילות	לוח שנה	מבזקי חדשות	תקנון	RSS	כותרות	כותרות לפי תגובה	ניקוי קוקיז	IP	להורדת אפליקציה
eBay	AliExpress	GearBest	Amazon	Booking	Kiwi	SkyScanner	Trip Advisor

"עזרה לגבי TCP עם time to live exceeded fragment reassembly"

גירסת הדפסה

קבוצות דיון חומרה, רשתות ואבטחת מידע נושא #24782	מנהל סגן המנהל מפקח Winner צל"ש מומחה

אשכול מספר 24782

eli-15

חבר מתאריך 25.9.03
19179 הודעות, 1 פידבק

22:53 19.07.17

עזרה לגבי TCP עם time to live exceeded fragment reassembly

אהלן,
הבעיה היא כזאת:
Client: 172.16.8.1
GW: 216.198.248.242
Server: 211.169.247.198
זה בעיקרון אתר HTTP כשאני ניגש אליו מהקליינט, שנמצא מאחורי הGW כמובן,
הGW עושה VPN לטראפיק הזה
בזמן התקשורת, יש Fragments, אך בשלב מסויים הקליינט שולח ICMP עם ההודעה:
Time to live exceeded, Fragment reassembly time exceeded
אם אני יוצא ישירות (ללא VPN), הכל עובד מעולה (אבל אין Fragments),
הפרגמנטציה נגרמת בעקבות הוספה של מידע VPN בתוך הESP, שמעלה את גודל הפקטה ל1508
ללא VPN יש עדיין פרגמנטציה.
מה שעשיתי, אפשרתי MSS CLAMP בצד של הCLIENT וגם בGW ועכשיו זה תקין מהצד שלי,
השרת, מצידו, ממשיך לשלוח פרגמנטציות...
לי, זה נראה כמו בעיית ROUTE אבל כשאני בלי VPN הכל עובד והFLOW שלי זהה, חוץ מעוד HOP אחד בדרך.
הTTL כמובן לא נגמר (לא מגיע ל0)
למה זה קורה? הפכתי את גוגל ללא מוצא.
מצורף קובץ PCAP עם הטראפיק.

www.facebook.com/tnagarut

תעשיות נגרות
עיצוב וייצור ריהוט בהזמנה

שתף

מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

האשכול	מחבר	תאריך כתיבה	מספר
ההצעה הכי טובה שלי היא להקטין MTU על הממשק חייגן של ה VPN	code_blue	19.07.17 23:24	1
הלינק לקובץ לא תקין	E-do	20.07.17 10:28	2
הוא העלה תקין יש בעיה באוטומציה של האתר	code_blue	20.07.17 14:42	3
צודק, הזוי...	E-do	20.07.17 16:44	4
די הזוי, אבל לא קשור בכלל לפרגמנטציה	E-do	20.07.17 17:13	5
זאת הבעיה, שאין לי אפשרות - תיקון קטן + מידע	eli-15	24.07.17 20:49	6
...	E-do	25.07.17 04:39	7
זה בדיוק מה שחשבתי...	eli-15	25.07.17 23:45	8

code_blue

חבר מתאריך 5.7.06
21280 הודעות, 7 פידבק

23:24 19.07.17

1. ההצעה הכי טובה שלי היא להקטין MTU על הממשק חייגן של ה VPN
בתגובה להודעה מספר 0

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

ברשתות הנוכחיות לETHERNET ה MTU הוא 1500
כשאתה משתמש בחייגן של בזק PPPOE החייגן בד"ג מוגדר עם MTU של 1492 מפאת 8 ביית
של ה PPP
כמו שיש את הגודל של הPPP שתופס יש את הגודל של הVPN שהקמת
אתה צריך לבדוק איזה סוג VPN וכמה ה OVERHEAD שלו , כלומר כמה הוא תופס בנוסף ל DATA המקורי
ואז בחייגן לוודא שה MTU הוא 1492 פחות הגודל הזה (במידה וזה בזק) במידה וזה כבלים אז 1500 פחות הגודל הזה
מה גם שMSS משפיע רק על תעבורת TCP ולא UDP שם אין בכלל HANDSHAKE

(ניהול: מחק תגובה)

מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

E-do
חבר מתאריך 29.10.03
2160 הודעות

10:28 20.07.17

2. הלינק לקובץ לא תקין
בתגובה להודעה מספר 0

נשמע שהICMP שאתה רואה לא קשור לTTL, הוא קשור לזה שלא הגיעו כל הfragments.

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

-----------------
בברכה,
e-do

(ניהול: מחק תגובה)

מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

code_blue

חבר מתאריך 5.7.06
21280 הודעות, 7 פידבק

14:42 20.07.17

3. הוא העלה תקין יש בעיה באוטומציה של האתר
בתגובה להודעה מספר 2

אל תלחץ על הלינק פשוט תעתיק לדפדפן

(ניהול: מחק תגובה)

מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

E-do
חבר מתאריך 29.10.03
2160 הודעות

16:44 20.07.17

4. צודק, הזוי...
בתגובה להודעה מספר 3

@אורי@ לטיפולך

-----------------
בברכה,
e-do

(ניהול: מחק תגובה)

מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

E-do
חבר מתאריך 29.10.03
2160 הודעות

17:13 20.07.17

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

יש כמה קונקשנים, ולא לגמרי ברור איזה רלוונטיים, אבל לקחתי 1 לדוגמא:
(ip.addr eq 172.16.8.1 and ip.addr eq 211.169.247.198) and (tcp.port eq 52636 and tcp.port eq 80)
זה שהcapture נלקח מפיירוול על "all interfaces" במקום על אינטרפייס ספציפי די מסבך את החיים, אבל לעניינינו, אחרי ה 3-way handshake אנחנו רואים את הGET REQUEST מהקליינט (Frame 1105), אחרי 270ms מגיע ACK מהשרת ללא נתונים (Frame 1109), ומיד לאחר מכן "נעלמים" בערך 24K, שים לב להבדל בין ה tcp sequence number לפאקט אחריו.
למרות שSACK נתמך, הקליינט בוחר לא להשתמש בו, ובFrame 1165 הוא שולח ACK 352, כלומר קורים פה 2 דברים:
1. הtcpdump לא תפס חלק מהפקטות
2. חלק מהפקטות באמת הלכו לאיבוד
אחרי זה הקליינט גם שולח FIN, לא ברור למה.
השרת מנסה לשלוח מחדש את הפאקט הראשון שהלך לאיבוד, אבל הקליינט מתעלם מזה לחלוטין.
אחרי דקה הקליינט צועק Fragment reassembly time exceeded, זה לא רלוונטי לשום דבר יותר.
סיפור דומה אם אתה מסתכל על פורט 52325.
אמרת שיש VPN, האם אתה יכול לאסוף tcpdump גם בצד המרוחק? אם כן יהיה אפשר לבדוק קצת יותר לעומק מה קורה.

-----------------
בברכה,
e-do

(ניהול: מחק תגובה)

מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

eli-15

חבר מתאריך 25.9.03
19179 הודעות, 1 פידבק

20:49 24.07.17

6. זאת הבעיה, שאין לי אפשרות - תיקון קטן + מידע
בתגובה להודעה מספר 5

@E-do@
אין לי אפשרות להביא TCPDUMP מהצד השני כי זה או הISP או איפה שהאתר יושב (קוריאה, אתר פאבליק - ראה למטה)
א. הקליינט עושה VPN לGW והGW יוצא לאינטרנט בלי VPN, אז:
Client>VPN-to-GW>GW>Internet
במקרה שלי:
Client מותקן עם END POINT VPN, מתחבר לGW (כSITE) ומקבל IP ממנו (office mode IP)
לקחתי tcpdump על internal וגם על external interface ביחד.
המצורף בראשית הפוסט זה FW MONITOR (firewall monitor
אני רואה את אותה ההתנהגות, אבל:
1. בשני הצדדים מופעל SACK וMSS CLAMPING כי יש SLE SRE בתוך הTCP.
2. MSS שהGW שולח הוא 1310
3. MSS שהשרת שולח בSYN-ACK הוא 1360
2+3 יוצרים מצב לא הגיוני, ע"פ RFC הערך של הMSS הוא הנמוך מבין 2 הצדדים.
בכל אופן, כשאני עושה CLEAR TRAFFIC ז"א ללא VPN אני כן רואה פרגמנטציות, אבל משום מה במצב הנוכחי, לא רואים אותם בTCPDUMP...
אין לי מושג מה קורה שם - נראה ממש הזוי, כנראה בעיית ISP או בצד של האתר הזה (הוא פאבליק - http://compuzone.kr

העברתי את זה לחקירה של MIS אצלנו בחברה...

www.facebook.com/tnagarut

תעשיות נגרות
עיצוב וייצור ריהוט בהזמנה

(ניהול: מחק תגובה)

מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

E-do
חבר מתאריך 29.10.03
2160 הודעות

04:39 25.07.17

7. ...
בתגובה להודעה מספר 6

לגבי 2+3, זה מצב תקין לחלוטין, למעשה בהרבה מקרים הMSS יהיה שונה (למשל במקרים בהם הMTU שונה בין הקליינט והשרת), הערך שמופיע שם הוא הכרזה של מה המקסימום שצד יכול לקבל, זה ממש לא אומר שהערך הנמוך הוא זה שיהיה בשימוש, תקרא את הRFC שוב
השרת אגב בוחר להתעלם מהערך שנשלח ע"י הקליינט (1310), ושולח 1360, אבל מאחר וזה מגיע לקליינט עושה רושם שזו לא הבעיה.
חוץ מזה שמתי לב עכשיו לעוד משהו מוזר, הפאקטות בעצם כן מגיעות, במקור הוספתי פילטר לפי הכיוון של ה fw.monitor כדי לסנן תעבורה "כפולה" ולכן לא ראיתי את זה, אבל אם אתה מסתכל החל מפאקט 1138 נראה שהכל שם, ועדיין בשום מקום הקליינט לא שולח ACK של מעבר ל352, כלומר הVPN client מחרבש לך משהו.

@eli-15@

-----------------
בברכה,
e-do

(ניהול: מחק תגובה)

מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

eli-15

חבר מתאריך 25.9.03
19179 הודעות, 1 פידבק

23:45 25.07.17

8. זה בדיוק מה שחשבתי...
בתגובה להודעה מספר 7

אחרי שבדקתי יותר לעומק (לקחנו טראפיק על הVNA interface) רואים בהחלט שהפקטות מגיעות (כולן, כולל הגדולות) והם FRAGMENTED...משהו כמו 24 פרגמנטס...
הקליינט לא שולח עליהם ACK - זה גם נכון, אבל לא ברור לנו בדיוק למה.
ואני דיי בטוח - הMSS חייב להיות הנמוך ביותר מבין הSYN לSYN-ACK...
נכון - השרת לא חייב לעשות אכיפה לMSS, אבל זאת הסיבה שיש בגללה FRAGMENTS.
בכל מקרה, הבעיה כנראה בדרייבר של הCLIENT...עכשיו כבר RND חוקרים
תודה וסליחה על הטרחה - אני אעדכן (אם זה מעניין אותך/מישהו) ברגע שיהיה פתרון עם הסבר למה זה קרה

@E-do@

www.facebook.com/tnagarut

תעשיות נגרות
עיצוב וייצור ריהוט בהזמנה

(ניהול: מחק תגובה)

מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד