במקרים רבים, אנחנו רואים ב- Wireshark תופעה שנקראת TCP Reset (Display filter: tcp.flags.reset==1). על מה מדובר?
במצב רגיל, TCP פותח Connection ב- 3 Packets: היוזם שולח Packet עם SYN, מקבל חזרה SYN-ACK, שולח ACK וה- Connection נפתח. לסגירת ה- Connection באופן רגיל אחד הצדדים שולח FIN-ACK, ומקבל FIN כתשובה. סה"כ 3 מנות (Packets) לפתיחת Connection, ובד"כ 4 מנות לסגירה, כמו שאנחנו רואים בדוגמא הבאה:
SYN, FIN, RST וכד' הם "דגלים" ב- Header של ה- TCP, כלומר Bit שאותו אנחנו מדליקים כשהוא "1". הסבר מפורט על אופן עבודת TCP יינתן במאמר נפרד. בקצרה נסביר שבסגירת Connection בצורה מסודרת, הצד היוזם את הסגירה שולח הודעה לצד השני – אני מעוניין לסגור את הקישור, סיים מה שאתה עדיין עושה ותודיע לי (FIN-ACK), הצד המקבל מסיים לעבד את המידע שעדיין נמצא אצלו ועונה חזרה: סיימתי (FIN), ואז אותו תהליך קורה גם בכיוון השני.
TCP Reset נועד למצב שבו אחד הצדדים מעוניין לסגור את ה- Connection באופן מידי, ולא בצורה מסודרת על ידי FIN-ACK כפול. החיסרון הינו כמובן סגירה לא מסודרת של תהליך, לעומת היתרון שהינו המהירות והחיסכון במנות המשודרות.
Reset יכול להיות כחלק מתהליך תקין. אם תכנסו למשל לאתרי חדשות רבים, תראו שבכניסה לעמוד הבית ייפתחו כמה עשרות קישורים (לפעמים הרבה עשרות). כשמסתיימת העלאת העמוד, אם כל הקישורים היו נסגרים בצורה רגילה, כלומר 4 מנות לסגירת כל קישור, היינו מקבלים מאות מנות רק עבור סגירת העמוד. במקרה זה, בהרבה מאוד אתרים תראו מצב שהשרת המאכסן את האתר מעבר אלינו את כל המידע שבדף, ואז שולח Resets לסגירת כל הקישורים שנפתחו.
זה היה מצב תקין. מהם המצבים שאינם תקינים? במצבים אלו אחד הצדדים מזהה שמשהו לא תקין, ושולח Reset לצד השני. מה זה אותו "משהו" לא תקין? בואו נראה.
אפשרות ראשונה: אם אתם רואים שעל SYN שנשלח מצד ה- Client מתקבל Reset מהצד השני, כנראה שמישהו חוסם את הניסיון לפתיחת Connection, בד"כ Firewall. בדוגמא הבאה אנחנו רואים שמחשב שכתובתו 10.0.0.3 מנסה לפתוח Connection לכתובת 82.80.120.135 ועבור כל SYN שהוא שולח מתקבל חזרה RST-ACK, כלומר Reset.
אפשרות שניה: אחד הצדדים מגלה בעיה בקישור (ב- TCP Connection), ושולח Reset לצד השני. בעייה יכול להיות מספר דברים.
בצילום מסך הבא אנחנו רואים דוגמא לתגובת Reset של מחשב מספר 10.0.0.7, שהוא ה- Client שפתח את הקישור. אנחנו רואים כאן תקשורת ב- FTP, שנפתחה מה- Client 10.0.0.7 ל- Server 15.192.45.26. אם נדלג ל-Packet מספר 2057 אנחנו רואים פקודה של ה- Client – CWD (Change Working Directory). ה- Server עונה ב- CWD Command Successful, ואז ה- Client שולח פקודת LIST (ls ב- Linux), ומסיבה כלשהי מיד אחריה במנה 2063 מבקש לסגור את הקישור. ה- Server שמסיבה כלשהי לא קיבל בשלב זה את הבקשה, שולח תשובה ב- Packet מספר 2065, וה- Client שלא מבין איך הוא מקבל תשובה אחרי ששלח FIN-ACK, שולח Reset ב- Packet מספר 2066.
ובדוגמא הבאה אנחנו רואים בעיה שיכולה לנבוע מ- Client שהתנתק מה- Server. במקרה הזה ללא Reset, אבל יכול לבוא גם עם Reset.
אם אתם רואים מקרה כזה – חמש פעמים Retransmission בזמנים עולים (ניתן לראות בעמודת ה- Time), יכול להיות 1) נתק בקו תקשורת, ואז תראו את התופעה קוראת מול כל הכתובות, 2) נפילת שרת, ואז תראו את התופעה מול כתובת IP אחת, 3) תקלת תוכנה, שבה ה- Server "קופא" ולא מחזיר תשובה ל- Client. במקרה הזה תראו את התופעה רק בכתובת השרת המסויים עליו מותקנת התוכנה, על TCP Port מסוים עליו עונה התוכנה, ומה שיראה המשתמש של התוכנה זה "קפיאה" של המסך בתוכנה, ואחרי כמה שניות או כמה עשרות שניות (ואז יכול להיות שתראו גם Keep Alives) התוכנה תשתחרר.
ולפעמים רואים גם דברים מצחיקים. תראו למשל את הדוגמא הבאה, שבה ה- Server מקבל חמש Resets, אבל פשוט לא מוכן לשתוק…
לסיכום
מקווה שעזרתי ואשמח לענות לכל שאלה או בעייה.
להעשרה והרשמה לקורסים בנושא Wireshrak, עכשיו גם ב-Online:
מאמר מושקע ומחכים,
תודה נשמח לעוד,
האם הספר שלך קיים גם בעברית ?
עוד מאמרים על WIRESHARK ?
תודה רבה.
גיא