TCP Reset ב-Wireshark: מתי RST זה תקין לגמרי, ומתי זו תקלה שמפילה לכם את האפליקציה

כל מי שפתח פעם Capture ב-Wireshark מכיר את הרגע הזה: אתם מחפשים למה האפליקציה נתקעת, מקישים בשורת הפילטר ‎tcp.flags.reset==1‎, ופתאום חצי מהמסך נצבע באדום. השאלה המיידית היא תמיד אותה שאלה — האם ה-RST-ים האלה הם הבעיה, או שהם סתם רעש רקע נורמלי?

התשובה, כמו הרבה דברים ברשתות, היא "תלוי". וכדי להבין במה זה תלוי צריך לרדת רגע לאיך TCP באמת עובד — לא ברמת השקף, אלא ברמת המנה.

רגע של רענון: איך נפתח ואיך נסגר Connection

במצב הרגיל, TCP פותח קישור בשלוש מנות — מה שמוכר כ-Three-Way Handshake: היוזם שולח SYN, מקבל בחזרה SYN-ACK, מחזיר ACK, וה-Connection פתוח. הסגירה המסודרת עולה בדרך כלל ארבע מנות: כל צד שולח FIN-ACK ומקבל ACK בתגובה.

SYN, FIN ו-RST הם לא הודעות — הם דגלים (Flags) ב-Header של TCP. כלומר ביט שמודלק ל-1. זה הכל. סגירה מסודרת היא בעצם שיחה מנומסת: הצד שרוצה לסיים אומר "אני מעוניין לסגור, תסיים מה שאתה עושה ותעדכן אותי", הצד השני מסיים לעבד את מה שנשאר אצלו בבאפר ועונה "סיימתי" — ואז אותו תהליך בדיוק חוזר גם בכיוון ההפוך.

לחצו להגדלה

אז מה זה TCP Reset?

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

FIN הוא "נעים היה, נסגור יפה". RST הוא "סגור. עכשיו." שניהם לגיטימיים — השאלה היא מי אמר את זה, למי, ולמה.

מקרה ראשון: RST שהוא לגמרי תקין

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

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

מקרה שני: RST על SYN — מישהו חוסם אתכם

זה הדפוס הכי קל לזיהוי והכי שימושי בפתרון תקלות. אם אתם רואים שה-Client שולח SYN, ובמקום SYN-ACK חוזר RST-ACK — כמעט תמיד מישהו באמצע חוסם את הניסיון לפתוח קישור. ברוב המקרים זה Firewall, לפעמים זה ACL על נתב, ולפעמים זה פשוט שרת שאין לו שירות מאזין על אותו Port.

לחצו להגדלה

• ▸RST חוזר מהיעד עצמו ומיד (מילישניות בודדות) — בדרך כלל אין שירות מאזין על ה-Port הזה
• ▸RST שחוזר מהר מדי ביחס למרחק הרשת — סימן שהוא נוצר על ידי ציוד ביניים, לא על ידי היעד האמיתי
• ▸אין תשובה בכלל, רק SYN חוזר ונשנה — זה כבר Drop שקט של פיירוול, לא Reset
• ▸השוו את ה-TTL של ה-RST מול תעבורה תקינה מאותה כתובת — הפרש משמעותי מסגיר מי באמת שלח אותו

מקרה שלישי: אחד הצדדים מזהה שמשהו לא הגיוני

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

דוגמה אמיתית מהשטח: תעבורת FTP בין Client‏ 10.0.0.7 לשרת 15.192.45.26. ב-Packet מספר 2057 ה-Client שולח פקודת CWD (החלפת ספרייה), השרת עונה CWD Command Successful, ה-Client ממשיך לפקודת LIST — ומיד אחריה, במנה 2063, מבקש פתאום לסגור את הקישור ב-FIN-ACK. השרת, שבשלב הזה עוד לא עיכל את הבקשה, שולח תשובה במנה 2065. ה-Client לא מבין איך הוא מקבל תשובה על קישור שהוא כבר סגר — ובמנה 2066 יורה RST.

השורה התחתונה: ה-RST הוא לא הסיפור. הוא הסימפטום. הסיפור האמיתי מתחיל שלוש-ארבע מנות לפניו, וזו בדיוק המיומנות שמפרידה בין מי שמסתכל על Wireshark לבין מי שיודע לקרוא אותו.

מקרה רביעי: חמישה Retransmissions — הצד השני נעלם

לפעמים בכלל אין RST, ודווקא זה מה שמסגיר את התקלה. אתם רואים את אותה מנה נשלחת שוב ושוב, כשהמרווחים בעמודת ה-Time גדלים בכל פעם (מנגנון Exponential Backoff של TCP). אחרי חמישה ניסיונות כאלה — הקישור נופל, ולפעמים גם מגיע RST בסוף.

לחצו להגדלה

איך מבדילים בין הסיבות האפשריות? לפי הפיזור:

• ▸נתק בקו התקשורת — התופעה תופיע מול כל כתובות היעד, לא רק אחת
• ▸נפילת שרת — התופעה תופיע מול כתובת IP אחת ויחידה, בכל הפורטים
• ▸תקלת תוכנה — התופעה תופיע מול אותו שרת אבל רק על Port מסוים, זה שהאפליקציה מאזינה עליו

המקרה השלישי הוא הכי מתסכל למשתמשים: המסך בתוכנה "קופא", ואחרי כמה שניות או כמה עשרות שניות (ואז לרוב תראו גם Keep-Alives בתוך ה-Capture) הכל משתחרר לבד. המשתמש יגיד "המחשב איטי". ה-Capture יגיד לכם בדיוק על איזה שרת ואיזה Port לשים את האצבע.

ולפעמים פשוט רואים דברים מצחיקים

יש מקרים שבהם השרת חוטף חמישה RST-ים ברצף — ופשוט ממשיך לדבר, כאילו כלום. אחד משניים: או שלכדנו את התעבורה בצד ה-Client וה-RST-ים בכלל לא הגיעו לשרת (מישהו בדרך בלע אותם), או שיש באג ב-Stack או באפליקציה שגורם לשרת להתעלם מהם.

וזה מוביל לכלל ברזל שכדאי לכתוב על הקיר: תמיד תשאלו את עצמכם איפה בדיוק ביצעתם את ה-Capture. מה שנראה כמו "השרת מתעלם" הוא לעיתים קרובות "אנחנו מסתכלים מהמקום הלא נכון ברשת".

ערכת עבודה מהירה: פילטרים שכדאי לשמור

• ▸tcp.flags.reset==1 — כל ה-Resets ב-Capture
• ▸tcp.flags.syn==1 && tcp.flags.ack==0 — כל ניסיונות פתיחת הקישור
• ▸tcp.analysis.retransmission — שידורים חוזרים
• ▸tcp.analysis.flags — כל מה ש-Wireshark חושב שבעייתי, בבת אחת
• ▸ip.addr==10.0.0.7 && tcp.port==21 — מיקוד בשיחה אחת ספציפית
• ▸Statistics ← Conversations, ומיון לפי מספר מנות — כך מוצאים את הזוג הבעייתי בשניות

למה זה בכלל חשוב לקריירה שלכם

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

כדי להגיע לשם צריך שני דברים. הראשון הוא בסיס רשתי מוצק — להבין באמת מה זה Port, מה זה טבלת ניתוב, איך VLAN מתנהג ואיפה ACL יכול לחתוך לכם את התעבורה. זה בדיוק מה שקורס ניהול רשתות תקשורת CCNA של מכללת נטמי בונה, שלב אחרי שלב, עם מעבדות מעשיות והכנה לבחינת Cisco CCNA 200-301. השני הוא היכולת לקרוא את זה על החוט — וזה קורס Wireshark, שבו יושבים על Captures אמיתיים ומפרקים תקלות אמיתיות.

מי שיש לו את שניהם מפסיק לנחש. הוא פשוט פותח Capture ורואה.

לסיכום

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