Packet capture ב-Windows בפועל — איך בוחרים בין pktmon, netsh trace ו-Wireshark

«תקשורת השרת של אפליקציית העסק נכשלת כמה פעמים בחודש. לוג האפליקציה כותב רק ‘timeout’. אין שגיאה תואמת בלוג מצד השרת באותו זמן. אנחנו לא יודעים איך לשחזר» — בייעוצי חקירת תקלות הצורה הזאת עולה כל הזמן.

לוג אפליקציה שומר רק מה שהאפליקציה «החליטה לכתוב». רואים שהתוצאה timeout, אבל האם בקשת החיבור (SYN) לא קיבלה תשובה, האם החיבור הוקם ואז השרת הפסיק לענות, האם הוא נותק ב-RST, או האם ה-packet בכלל הגיע ליעד — חיים שכבה אחת מתחת ללוג — ב-packets שעברו באמת על ה-wire. אם Process Monitor הוא הדרך להסתכל שכבה אחת למטה על גישה לקבצים ול-Registry, packet capture הוא הדרך להסתכל שכבה אחת למטה על השיחה.

flowchart TB
    accTitle: ה-packets שכבה אחת מתחת ללוג האפליקציה
    accDescr: לוג אפליקציה שומר רק מה שהאפליקציה החליטה לכתוב; האם SYN בלי תשובה, שקט אחרי חיבור, RST שניתק, או האם ה-packet הגיע חיים רק ב-packets שעברו באמת על ה-wire
    log["לוג אפליקציה"] --> dec["נשאר רק מה שהוחלט לכתוב"]
    dec --> to["התוצאה timeout במילה אחת"]
    to -->|הסתכלו שכבה אחת למטה| pkt["packets שעברו באמת על ה-wire"]
    pkt --> q1["אין תשובה ל-SYN?"]
    pkt --> q2["שקט אחרי חיבור?"]
    pkt --> q3["נותק ב-RST?"]
    pkt --> q4["האם הגיעה ליעד?"]

איור 1: הלוג שומר רק את התוצאה; פירוק ה-timeout חי רק ב-packets שכבה אחת למטה.

המקום הטיפוסי שבו נתקעים הוא האילוץ «אי אפשר להתקין Wireshark בשרת הלקוח». אתרים שבקרת השינוי או מדיניות האבטחה שלהם לא מאשרים תוכנה נוספת לחקירה אינם נדירים. אבל Windows כבר שולח שני כלי packet capture: pktmon ו-netsh trace. לוכדים בכלי OS מובנים, לוקחים את הקובץ שמתקבל למחשב שלכם, וקוראים ב-Wireshark — בחלוקה הזאת עדיין רואים את ה-packets באתר שאוסר התקנות.

המאמר הזה מיועד לאנשי IT בחברות קטנות ובינוניות ולמפתחי אפליקציות Windows. הוא מסביר איך לבחור בין pktmon, netsh trace ו-Wireshark, ואת ההליך המעשי של כל אחד. מלכודות תעבורת loopback, ההחלטה אם ללכוד בלקוח או בשרת, איך לחיות עם TLS שמסתיר את ה-payload, וקישור ה-capture ללוג האפליקציה — כולם ממקורות ראשוניים מעודכנים לאוגוסט 2026.

1. קודם המסקנה

• «capture בכלי המובנה, קריאה ב-Wireshark» היא החלוקה הבסיסית בשטח. גם אם אי אפשר להתקין תוכנה בשרת הלקוח, pktmon ו-netsh trace מובנים ב-Windows. ממירים את הלוג שלכדתם ל-pcapng ומנתחים ב-Wireshark במחשב שלכם.¹²
• pktmon הוא כלי packet capture המובנה ב-Windows 10 / Windows Server 2019 ואילך. משתמשים בו בארבעה צעדים — רישום filter, התחלה, עצירה, המרה — והחוזק הייחודי שלו הוא לראות איזה רכיב ב-network stack זרק את ה-packet (drop reason).³⁴
• netsh trace הוא הכלי המובנה הישן יותר; הוא יכול להפעיל חבילת ספקי ETW כ«scenario». בנוסף ל-packets הוא שומר אירועים מתוך רכיבי Windows, ועם persistent=yes ה-capture יכול לשרוד reboot.⁵⁶
• שני הכלים כותבים ETL ש-Wireshark לא יכול לפתוח כמו שהוא. ממירים ל-pcapng ב-pktmon etl2pcap ל-pktmon, וב-etl2pcapng הקוד הפתוח של Microsoft ל-netsh trace.¹²
• Microsoft עצמה מצביעה על «קודם pktmon, אחר כך netsh trace אם זה לא מספיק, ו-Wireshark לניתוח פרוטוקול». החלוקה במאמר הזה עוקבת אחרי ההמלצה הרשמית הזאת.⁷
• כברירת מחדל pktmon רושם רק את 128 הבתים הראשונים של כל packet. אם אתם מתכוונים לקרוא את ה-payload ב-Wireshark, אל תשכחו --pkt-size 0 (לרשום את כל ה-packet) בהתחלה.⁸
• תעבורה ל-localhost לא מופיעה ב-capture רגיל. היא לא עוברת NIC. משתמשים במתאם ה-loopback של Npcap ב-Wireshark, או ב-capture בתוך ה-stack של pktmon עם הכלים המובנים.⁹
• גם כש-TLS מסתיר את ה-payload, עדיין אפשר ללמוד הרבה. הקמת חיבור, האם ה-TLS handshake הצליח, RST, ואיזה צד הפסיק לענות נשארים גלויים גם בהצפנה. פענוח דרך SSLKEYLOGFILE הוא טכניקה לסביבת פיתוח בלבד.¹⁰
• capture מכיל את התקשורת עצמה. מניחים שהוא יכול לכלול credentials ומידע אישי, ובונים capture במינימום הנחוץ וצמצום לפני מסירה לתוך ההליך.

2. שלושת כלי ה-capture ואיך בוחרים ביניהם

קודם, טבלה אחת של תפקידי שלושת הכלים.

במשפט אחד, pktmon ו-netsh trace הם כלי ה«capture», ו-Wireshark הוא כלי ה«קריאה». Wireshark יכול גם ללכוד, אבל אי אפשר להשתמש בזה במקום שאי אפשר להתקין. להפך, אפשר להמיר ETL של הכלים המובנים לטקסט ולקרוא, אבל בהייה בלי display filter ובלי ניתוח TCP היא סבל. «capture בשטח בכלי המובנה, המרה ל-pcapng, וקריאה ב-Wireshark במחשב שלכם» הוא הנתיב הקצר ביותר באתר מוגבל.

flowchart TB
    accTitle: capture בכלי המובנה, קריאה ב-Wireshark
    accDescr: בשטח לוכדים ETL ב-pktmon או netsh trace, ממירים כל אחד ל-pcapng בכלי ההמרה שלו, ומנתחים ב-Wireshark במחשב שלכם
    pk["pktmon (מובנה)"] --> etla["קובץ ETL"]
    ns["netsh trace (מובנה)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["נתחו ב-Wireshark במחשב שלכם"]

איור 2: בשטח לוכדים ETL בכלים המובנים, ממירים ל-pcapng, וקוראים ב-Wireshark במחשב שלכם.

מדריך חקירת packet loss של Microsoft בעל אותה צורה: לוכדים ומבודדים את הסיבה ב-pktmon קודם, אחר כך עוברים ל-trace ברמת רכיב כמו netsh trace start scenario=InternetClient אם זה לא מספיק, ומנתחים התנהגות פרוטוקול ב-Wireshark.⁷

כתנאי מקדים לקריאת מה ש-packet באמת מראה, עוזר גם תמונה של השכבות המוערמות — Ethernet, IP, TCP, נתוני אפליקציה. אנטומיית השכבות מאוירת ב«Getting a Real Feel for the OSI Model».

3. pktmon בפועל — filter, התחלה, עצירה, המרה

הזרימה הבסיסית של pktmon היא ארבעה צעדים. מריצים אותם במסוף מוגבה.

:: 1. רשמו תחילה מסנן כדי לצמצם את היעד (TCP 8443 בשרת 192.168.10.20)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. התחלת הלכידה. רישום חבילות שלמות, דריסה במאגר טבעתי של 1GB
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. שחזרו את האירוע. בזמן ההמתנה אפשר לבדוק נפח והשלכות עם counters
pktmon counters --drop-reason

:: 4. עצירה, ואז המרה ל-pcapng עבור Wireshark
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. ניקוי המסנן הרשום (מסננים נשארים עד שמוחקים אותם במפורש).
::    שים לב: filter remove אינו מקבל שם; הוא מוחק את «כל» המסננים הרשומים.
::    במחשב שעשויים להישאר בו מסננים מחקירה אחרת, בדקו תחילה עם pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: הליך pktmon הבסיסי
    accDescr: מצמצמים את היעד ב-filter, מתחילים capture, משחזרים את האירוע, עוצרים, ממירים ל-pcapng ב-etl2pcap, ולבסוף מסירים את ה-filter הרשום
    fa["1. צמצמו יעד ב-filter add"] --> st["2. התחילו capture ב-start --capture"]
    st --> re["3. שחזרו את האירוע"]
    re -.-> ct["בדקו נפח ו-drop ב-counters"]
    re --> sp["4. עצרו"]
    sp --> cv["המירו ל-pcapng ב-etl2pcap"]
    cv --> rm["5. נקו ב-filter remove"]

איור 3: pktmon מתחיל ברישום filter, אחר כך capture, עצירה והמרה, ומסירים את ה-filter במפורש בסוף.

נקודות לזכור:

• רושמים filters לפני שמתחילים capture. גם התיעוד של Microsoft ממליץ בתוקף להחיל filter לפני ההתחלה, כי capture של כל התעבורה רועש מדי. filters יכולים לציין כתובת IP, פורט, כתובת MAC, פרוטוקול, מזהה VLAN ועוד, ואפשר לרשום עד 32. כמה filters הם OR: packet נרשם אם הוא תואם אחד מהם.³
• filter של pktmon לא מבחין בין מקור ליעד. -i 192.168.10.20 פירושו «packets שבהם הכתובת הזאת מקור או יעד». מצמצמים כיוון אחר כך ב-display filter של Wireshark אחרי ההמרה.³
• גודל ה-packet כברירת מחדל הוא 128 בתים. זה מספיק לניתוח כותרות, אבל אם רוצים גם נתוני אפליקציה, רושמים את כל ה-packet ב---pkt-size 0.⁸
• הלוג כברירת מחדל במצב circular (ring buffer), גודל ברירת מחדל 512MB. אפשר לשנות את התקרה ב---file-size, ו---log-mode real-time מדפיס למסך בזמן אמת ולא יוצר קובץ לוג. מאשרים קודם במצב real-time שאתם באמת רואים את התעבורה שמעניינת, ואז מגדירים את capture הייצור, ותימנעו מלכידה ריקה.⁸

flowchart TB
    accTitle: איך filters של pktmon נכנסים לתוקף
    accDescr: כמה filters רשומים רושמים בהתאמת OR, הכתובת שצוינה לא מבחינה בין מקור ליעד, והכיוון מצטמצם אחר כך ב-display filter של Wireshark אחרי ההמרה
    f1["filter 1"] --> orc["רשמו אם אחד תואם"]
    f2["filter 2"] --> orc
    f3["filter 3 (עד 32)"] --> orc
    orc --> rec["נרשם בלוג ה-capture (OR)"]
    rec -.-> nodir["מקור ויעד לא מובחנים"]
    nodir -.-> ws["צמצמו כיוון ב-Wireshark אחרי המרה"]

איור 4: כמה filters פועלים כ-OR, והאם מארח הוא מקור או יעד מצטמצם ב-Wireshark אחרי ההמרה.

3.1. מה שרק pktmon יכול — לראות איפה packet נזרק

הערך הייחודי של pktmon מול Wireshark הוא שהוא לוכד packet בכמה נקודות בתוך ה-network stack, לא ב-NIC יחיד, ויכול לדווח איפה ולמה הוא נזרק (drop). כי אפשר לראות איזה רכיב ה-packet הגיע אליו ואיפה הוא נעלם, סיבות drop כמו «אי-התאמת MTU» או «VLAN filter» מביאות אתכם לסיבה בלי חיפוש כוח גס.⁴

flowchart TB
    accTitle: pktmon לוכד בכמה נקודות בתוך ה-stack
    accDescr: pktmon לוכד packet בכמה נקודות בתוך ה-network stack ולא ב-NIC יחיד, ולכן יכול לדווח עם סיבה איזה רכיב ה-packet הגיע אליו ואיפה הוא נזרק
    pin["packet"] --> p1["נלכד בנקודה 1"]
    p1 --> p2["נלכד בנקודה 2"]
    p2 --> p3["נזרק בנקודה 3"]
    p3 -.-> rz["מדווח מיקום drop וסיבה"]
    rz -.-> ex["למשל אי-התאמת MTU או VLAN filter"]

איור 5: capture בכמה נקודות בתוך ה-stack אומר עד כמה רחוק packet הגיע ואיפה הוא נזרק, עם סיבה.

• pktmon list מציג את רכיבי הרשת שאפשר לנטר (NIC, protocol stacks, filter drivers ועוד) ואת המזהים שלהם.
• pktmon counters --drop-reason מפרט מוני מעבר/drop לכל רכיב ואת סיבת ה-drop האחרונה. נוח כחיתוך ראשון לפני ניתוח הלוג.¹¹
• ממירים לטקסט ב-pktmon etl2txt ו-packets שנזרקו יוצאים עם drop ו-dropReason.³

החשד ש«משהו ב-OS זורק את זה לפני שהיא מגיעה לאפליקציה» לא נסגר בהייה ב-Wireshark לבד. היכולת הזאת עוזרת, למשל, בבידוד מקרה שבו Windows Firewall זורק כי חסרה inbound rule («Windows Firewall ואפליקציות עסקיות»).

הסתייגות אחת. pktmon רושם את אותו packet בכמה נקודות ב-stack, כך שהמרה כמו שהיא ל-pcapng יכולה לגרום לאותו packet להופיע יותר מפעם. pcapng לא נושא «איזה רכיב לכד את זה», ולכן אם קוראים ב-Wireshark המהלך הסטנדרטי הוא להמיר עם --component-id כדי לבחור נקודה אחת (או לשים drop בלבד בקובץ נפרד עם --drop-only).¹

flowchart TB
    accTitle: למה אותו packet יכול להופיע פעמיים אחרי המרת pcapng
    accDescr: pktmon רושם את אותו packet בכמה נקודות ב-stack, pcapng לא שומר איזה רכיב לכד אותו כך שכפילויות יכולות להופיע, והמהלך הסטנדרטי הוא להמיר אחרי צמצום הנקודה ב-component-id או לשים drop בלבד בקובץ drop-only
    same["אותו packet נרשם בכמה נקודות"] --> conv["המירו ל-pcapng כמו שהוא"]
    conv --> lost["מידע נקודת ה-capture לא עובר"]
    lost --> dup["אותו packet מופיע יותר מפעם"]
    dup --> c1["צמצמו נקודה ב--component-id"]
    dup --> c2["קובץ נפרד ב--drop-only"]

איור 6: מידע נקודת ה-capture לא עובר ל-pcapng, ולכן המהלך הסטנדרטי הוא לצמצם את הנקודה לפני ההמרה.

4. netsh trace בפועל — scenarios, ETL ו-captures ששורדים reboot

netsh trace הוא מנגנון ה-trace שנמצא ב-Windows יותר זמן מ-pktmon. המאפיין שלו הוא שכ«scenario» הוא יכול להפעיל בבת אחת את כל סט ספקי ה-ETW הקשורים לבעיה הזאת.⁶

:: List available scenarios and inspect the providers in a scenario
netsh trace show scenarios
netsh trace show scenario netconnection

:: Start the capture. Packet capture included, 1GB circular buffer
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Reproduce the incident, then stop (the merge takes a little time)
netsh trace stop

• מוסיפים capture=yes כדי להפעיל packet capture, ומצמצמים את היעד ב-capture filter כמו ipv4.address=192.168.10.20. רשימת ה-filters ב-netsh trace show capturefilterHelp.⁶
• העצירה מייצרת קובץ .cab בנוסף ל-ETL. ה-.cab מחזיק מידע מערכת כמו תצורת מתאם ו-build של ה-OS, כך שהוא משמש גם כאיסוף סביבה.⁶
• רק סשן trace אחד יכול לרוץ בבת אחת. לפני שמתחילים capture אחר, בודקים ב-netsh trace show status שלא נשאר סשן רץ.⁶
• מוסיפים persistent=yes והסשן שורד reboot. capture של «התקשורת נכשלת לרגע מיד אחרי reboot» או «חיבור השירות בהפעלה נכשל» — אירועים שאי אפשר להספיק להתחיל ביד — היא הקרקע הייחודית של netsh trace.⁵

flowchart TB
    accTitle: capture לפי scenario ב-netsh trace
    accDescr: התחלה עם scenario מפעילה סט ספקי ETW מאוגד, capture=yes לוכד גם packets, והעצירה מייצרת קובץ ETL וקובץ .cab
    sc["התחילו עם scenario"] --> pv["הפעילו את סט הספקים"]
    sc -->|capture=yes| pc["packets נלכדים גם"]
    pv --> re["שחזרו את האירוע"]
    pc --> re
    re --> sp["עצרו"]
    sp --> etl["קובץ ETL"]
    sp --> cab[".cab (מידע מערכת)"]

איור 7: התחלה עם scenario מפעילה סט ספקים מאוגד, והעצירה מייצרת ETL ו-.cab.

4.1. להפוך ETL לקריא ב-Wireshark —‏ etl2pcapng

ETL של netsh trace אי אפשר לפתוח ב-Wireshark כמו שהוא. etl2pcapng, כלי הקוד הפתוח ש-Microsoft מפרסמת ב-GitHub, ממיר packets בתוך ETL שלכדתם ב-netsh trace start capture=yes ל-pcapng.²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

בהמרה etl2pcapng כותב את מזהה ה-process המעורב בכל packet כהערת packet. היכולת לראות «של איזה process התעבורה הזאת» ב-Wireshark עוזרת כשכמה אפליקציות באותו שרת מדברות.²

צד אירועי ה-ETW (אירועים פנימיים של Windows שספקי ה-scenario רשמו) לא מומר ל-pcapng. אם רוצים גם את האירועים, ממירים לטקסט או דומה ב-netsh trace convert input=C:\temp\nettrace.etl, או פותחים את ה-ETL ב-Windows Performance Analyzer.⁵⁷

flowchart TB
    accTitle: קריאת ETL של netsh trace מתפצלת לשני נתיבים
    accDescr: packets בתוך ה-ETL מומרים ל-pcapng ב-etl2pcapng ונקראים ב-Wireshark; אירועי ETW לא מומרים ל-pcapng, ולכן קוראים אותם ב-netsh trace convert או ב-Windows Performance Analyzer
    etl["ETL של netsh trace"] --> pk["packets"]
    etl --> ev["אירועי ETW"]
    pk -->|etl2pcapng| pc["המירו ל-pcapng"]
    pc --> ws["קראו ב-Wireshark"]
    pc -.-> pid["מזהה process נשאר כהערה"]
    ev -.-> no["לא מומר ל-pcapng"]
    no --> alt["קראו ב-convert או WPA"]

איור 8: מה-ETL packets מומרים ל-pcapng לקריאה; אירועי ETW נקראים בדרך אחרת.

5. מבט ראשון על קריאה ב-Wireshark —‏ display filters וניתוח TCP

אחרי שפתחתם את ה-pcapng, קודם חותכים רעש ב-display filter. הנפוצים בטבלה.¹²¹³

tcp.analysis.* הם דגלי ניתוח ש-Wireshark מקצה במעקב אחרי מספרי רצף TCP. retransmissions, duplicate ACK, out of order, ZeroWindow וכדומה נאספים מכנית, ולכן הדרך הסטנדרטית להתחיל לקרוא היא להקליד קודם tcp.analysis.flags ולפרט את המקומות ש«נראים כמו בעיה».¹³

בחקירת timeout מחפשים את הצורות הבאות לפי הסדר.

1. האם ה-three-way handshake הושלם? האם שלושת ה-packets SYN → SYN/ACK → ACK כולן שם? אם SYN חוזר בלי תשובה, הוא לא הגיע לעמית, או שנזרק בשקט באמצע (התבנית הטיפוסית של firewall).
2. איזה צד שלח את ה-RST? RST מיידי ל-SYN אומר שאף אחד לא מאזין בפורט היעד; RST אחרי שהחיבור הוקם אומר שצד אחד כפה ניתוק. כתובת ה-IP של מקור ה-RST היא ראיה ישירה ל«מי חתך».
3. האם retransmissions ממשיכים? retransmission חוזר של אותו segment הוא סימן ש-האישור (ACK) לא חוזר לשולח. האם נתוני היציאה אבדו או שה-ACK החוזר אבד אי אפשר לסגור מ-capture חד-צדדי (לכן «capture בשני הצדדים» בפרק הבא חשובה). retransmissions ו-timeout מכוסים לעומק ב«הסיבה לכך ששידור חוזר ב-TCP עוצר תקשורת עם מצלמה תעשייתית, ואיך מבודדים אותה».
4. האם יש ZeroWindow? זה סימן שאפליקציית הקבלה לא קוראת מה-socket ו-receive buffer מלא. זה בסיס לחשוד בעיצוב אפליקציית הקבלה («The Misconception That TCP Lets You Receive in the Same Units You Send») ולא ברשת.

flowchart TB
    accTitle: סדר הצורות לחפש בחקירת timeout
    accDescr: מאשרים השלמת three-way handshake, נוכחות ומקור RST, retransmissions ממשיכים, אחר כך ZeroWindow, כדי לשים סימן ראשון על הסיבה
    hs{"האם SYN קיבל תשובה?"} -->|לא| ng["לא הגיע מעולם (firewall טיפוסי)"]
    hs -->|כן| rs{"יש RST?"}
    rs -->|כן| who["מקור RST חתך"]
    rs -->|לא| rt{"retransmissions ממשיכים?"}
    rt -->|כן| ack["ACK לא חוזר"]
    rt -->|לא| zw{"יש ZeroWindow?"}
    zw -->|כן| app["המקבל לא קורא"]

איור 9: חיפוש handshake, RST, retransmission ואחר כך ZeroWindow בסדר הזה מצמצם לאן להסתכל הלאה.

לפני שקוראים packets אחד-אחד, עוזר גם לקלוט את התמונה כולה ביכולות הסטטיסטיקה. [Statistics] → [Conversations] הוא רשימה של «איזה זוג IP / זוג פורטים דיבר, ממתי עד מתי, כמה», כך שמזהים את השיחה שמעניינת ואז מסננים רק אליה. [Statistics] → [I/O Graph] הוא גרף נפח לאורך זמן; צורות כמו «מהזמן הזה כיוון אחד הפסיק לענות» בולטות. לחיצה ימנית על שיחת ה-TCP שמעניינת ובחירה ב-[Follow] → [TCP Stream] מאפשרת לקרוא את חילופי החיבור הזה כטקסט גלוי.

flowchart TB
    accTitle: קלטו את התמונה בסטטיסטיקה, אחר כך צמצמו לשיחה
    accDescr: מפרטים אילו שיחות דיברו מתי וכמה ב-Conversations, תופסים את מרווח השקט מ-I/O Graph, מסננים לשיחה שמעניינת, וקוראים אותה כ-TCP stream
    ov["קלטו את כל התמונה בסטטיסטיקה"] --> cv["רשימת שיחות ב-Conversations"]
    ov --> io["ראו נפח ב-I/O Graph"]
    cv --> flt["סננו לשיחה שמעניינת"]
    io -.-> mute["מרווח השקט נראה"]
    flt --> fs["קראו כ-TCP stream"]

איור 10: לפני שקוראים packet-packet, קולטים את התמונה בסטטיסטיקה, מצמצמים לשיחה שמעניינת, ואז קוראים אותה.

6. מלכודת ה-loopback — תעבורה ל-localhost לא עוברת NIC

ניסיון לחקור תקשורת בין אפליקציות באותו מחשב — למשל אפליקציית עסק שמתחברת לשירות ביניים ב-localhost:8080 — והיתקעות ב«כלום לא מופיע ב-Wireshark» היא מלכודת קלאסית.

הסיבה ברורה. תעבורה ל-localhost (127.0.0.1) לא עוברת אף פעם NIC פיזי; היא חוזרת בנתיב loopback הפנימי של ה-OS. capture רגיל שמכוון למתאם פיזי לכן אף פעם לא רואה אותה.⁹

flowchart TB
    accTitle: למה תעבורה ל-localhost לא מופיעה ב-capture
    accDescr: תעבורה ל-localhost לא עוברת NIC פיזי וחוזרת בנתיב loopback הפנימי של ה-OS, ולכן אף פעם לא מופיעה ב-capture רגיל שמכוון למתאם פיזי
    app["אפליקציה"] --> stack["network stack"]
    stack -->|חיצוני| nic["NIC פיזי"]
    nic --> seen["נראה ב-capture רגיל"]
    stack -->|localhost| lo["חוזר בתוך ה-OS"]
    lo -.-> miss["לא ב-capture רגיל"]
    lo -.-> alt["loopback של Npcap או pktmon"]

איור 11: תעבורה ל-localhost חוזרת לפני ה-NIC, ולכן capture של מתאם פיזי אף פעם לא רואה אותה.

יש שתי דרכים להתמודד.

• כשלוכדים ב-Wireshark: בוחרים את «Adapter for loopback traffic capture» של Npcap כיעד ה-capture. מתקין Windows של Wireshark (3.0 ואילך) כולל Npcap, כך שאם Wireshark כבר מותקן אפשר להשתמש בלי עבודה נוספת.⁹
• כשלוכדים בכלים המובנים: pktmon לוכד בכמה נקודות בתוך ה-network stack ולא מחוץ ל-NIC⁴, ולכן יכול לצפות גם בתעבורת loopback. כדי להיות בטוחים, לפני שמגדירים המתנה לשחזור בייצור, מאשרים באותו מחשב ב-pktmon start -c -m real-time תצוגת real-time שתעבורת ה-loopback שמעניינת באמת נראית.

שימו לב גם לשני בלבולים.

• «localhost» יכול להתיישב ל-IPv6 ::1. האפליקציה מתחברת ל-IPv6 ::1, אבל החוקר מסתכל רק על 127.0.0.1 (IPv4) ומסיק בטעות «אין תעבורה». מתחים את ה-display filter על שניהם, כמו ב-ip.addr == 127.0.0.1 || ipv6.addr == ::1, או הופכים את הגדרת היעד של האפליקציה לכתובת מפורשת.⁹
• תעבורה ל-IP האמיתי שלכם גם לא יוצאת ל-wire. כשאותו מחשב מתחבר מ-192.168.10.5 ל-192.168.10.5, היעד הוא IP אמיתי אבל ה-OS עדיין מחזיר אותו פנימית. זוכרים ש«ציינתי IP אמיתי, אז זה חייב לעבור את ה-NIC» אינו מובטח.

flowchart TB
    accTitle: הבלבול כש-localhost מתיישב ל-IPv6
    accDescr: localhost של אפליקציה עשוי להתיישב ל-IPv6 ::1, ואם החוקר מסתכל רק על 127.0.0.1 הוא מסיק בטעות שאין תעבורה, ולכן מתחים את ה-display filter על שתי הכתובות או מאשרים את היעד ככתובת מפורשת
    app["האפליקציה מתחברת ל-localhost"] --> v6["בפועל מתיישב ל-::1 (IPv6)"]
    look["החוקר מסתכל רק על 127.0.0.1"] --> none["כלום לא מופיע במסך"]
    v6 --> none
    none --> fix1["מתחו את ה-filter על שתי הכתובות"]
    none --> fix2["הפכו את היעד לכתובת מפורשת"]

איור 12: שימו לב לבלבול שבו localhost מתיישב ל-::1 והסתכלות רק על 127.0.0.1 מובילה ל«אין תעבורה».

7. איפה ללכוד — צד אחד, שני צדדים, וסנכרון שעון

ערך ה-capture נקבע לפי «איפה לכדתם». כלל האצבע הוא כדלקמן.

capture חד-צדדי אומר רק «העובדות כפי שנראו מהעמדה שלי». retransmissions שממשיכים בלקוח לא מבחינים אם ה-packet שנשלח נעלם בנתיב, או שהגיע לשרת והתשובה נעלמה. לוכדים בשני הצדדים ומיישרים אותם, ותוכלו לסגור «הלקוח שלח / השרת לא קיבל» — איזה צד הפסיק לענות. כשצריך לסגור את גבול האחריות (האפליקציה, ה-OS, התקן רשת, או הצד השני), כדאי לבנות capture בשני הצדדים מההתחלה.

flowchart TB
    accTitle: מה capture חד-צדדי ודו-צדדי אומרים
    accDescr: capture חד-צדדי לא מבחין אם ה-packet היוצא נעלם או שהתשובה החוזרת נעלמה; capture בשני הצדדים ויישור שלהן סוגר איזה צד הפסיק לענות
    one["capture בצד אחד"] --> fact["עובדות מהצד שלכם"]
    fact --> und["יציאה או חזרה?"]
    both["capture בשני הצדדים"] --> mt["ישרו אותן"]
    mt --> fix["איזה צד הפסיק לענות"]
    mt -.-> pre["צריך סנכרון שעון"]

איור 13: צד אחד מראה רק את העובדות שראיתם; יישור שני הצדדים הוא מה שסוגר לראשונה את גבול האחריות.

7.1. הנחת היסוד של הקישור היא סנכרון שעון

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

:: Check time-sync status (sync source, last sync time)
w32tm /query /status

:: Measure the offset against the peer server (5 samples)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart היא הפקודה שמציגה את היסט הזמן ביניכם לבין המחשב העמית, והיא הופכת לבסיס לתיקון כמו «שעון השרת היה +0.8 שניות» כשמיישרים את ה-captures.¹⁴ בסביבה עם היסט גדול, תיקון סנכרון הזמן קודם ואחר כך capture הוא בסוף הנתיב הקצר יותר.

flowchart TB
    accTitle: הליך בדיקת היסט השעון לפני קישור
    accDescr: מאשרים את מצב סנכרון הזמן שלכם ב-w32tm, מודדים ורושמים את ההיסט מול שרת העמית ב-stripchart, משתמשים בהיסט הזה כבסיס לתיקון ביישור captures, ואם ההיסט גדול מתקנים סנכרון קודם ואז לוכדים
    st["בדקו מצב סנכרון ב-query"] --> mc["מדדו היסט ב-stripchart"]
    mc --> rc["רשמו את ההיסט"]
    rc --> use["בסיס לתיקון בזמן קישור"]
    mc -.-> big["אם ההיסט גדול, תקנו סנכרון קודם"]

איור 14: מודדים ורושמים את היסט השעון לפני ה-capture, ומשתמשים בו כבסיס לתיקון כשמיישרים את ה-captures.

7.2. ל«לא יודעים מתי זה יקרה» — ring buffer

לאירוע שתנאי השחזור שלו אינם יודעים, המהלך הבסיסי הוא להשאיר ring buffer רץ ולעצור אותו כשהאירוע קורה.

• pktmon: ברירת המחדל היא מצב circular. מגדירים את התקרה (MB) ב---file-size; packets ישנים יותר נדרסים.⁸
• netsh trace: מציינים כ-maxSize=1024 filemode=circular.⁵
• Wireshark: תחת [Capture] → [Options] → [Output] אפשר להגדיר «כמה קבצים + ring buffer». הוא מסתובב לפי גודל קובץ או זמן ושומר רק את N הקבצים האחרונים, כך שאפשר לרוץ זמן רב עם תקרת שימוש בדיסק.¹⁵

בכל מקרה, משתפים עם האדם בשטח את הכלל שכשהאירוע קורה, «רושמים קודם את השעה, ואז» עוצרים את ה-capture. ring buffer מוחק את העבר ככל שמחכים יותר, ולכן אם הנתיב מהתרחשות לעצירה ארוך, המרווח שמעניין נדרס.

flowchart TB
    accTitle: המתנה עם capture ב-ring buffer
    accDescr: לאירוע שתנאי השחזור שלו אינם יודעים משאירים ring buffer רץ, וכשהאירוע קורה רושמים את השעה ועוצרים מיד; אם עוצרים מאוחר, packets ישנים נדרסים והמרווח שמעניין נעלם
    st["התחילו capture ב-ring buffer"] --> wt["השאירו רץ והמתינו"]
    wt --> ev["האירוע קורה"]
    ev --> memo["רשמו את השעה"]
    memo --> sp["עצרו מיד"]
    wt -.-> ow["packets ישנים נדרסים"]
    ow -.-> late["עצירה מאוחרת מוחקת את המרווח שמעניין"]

איור 15: ring buffer מוחק את העבר ככל שמחכים יותר, ולכן אחרי שרשמתם את השעה עוצרים מיד.

8. הבעיה ש-TLS מסתיר את ה-payload — מה עדיין אפשר לראות

רוב תעבורת העסקים היום היא TLS (HTTPS). נוטים לחשוב «אם זה מוצפן, capture חסר תועלת», אבל רוב מה שרוצים בחקירת timeout עדיין גלוי עם ההצפנה במקומה.

• האם חיבור ה-TCP הוקם (three-way handshake)
• עד כמה רחוק הגיע ה-TLS handshake — האם ServerHello חזר ל-ClientHello, האם נחתך ב-RST או בהתראה במהלך ה-handshake
• שם המארח היעד ב-ClientHello (SNI), וגרסת ה-TLS שסוכמה
• אחרי שהחיבור עומד, איזה צד הפסיק לשלוח. מיקום השקט, retransmissions, RST, או סגירה נקייה (FIN)

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

flowchart TB
    accTitle: מה capture של TLS יכול ולא יכול להראות
    accDescr: הצפנה מסתירה רק את ה-payload של נתוני האפליקציה; הקמת חיבור TCP, הצלחה או כישלון של TLS handshake, SNI וגרסת TLS, RST, ואיזה צד הפסיק לענות נשארים גלויים עם ההצפנה במקומה
    tls["capture של תעבורת TLS"] --> vis["גלוי"]
    tls --> hid["לא גלוי"]
    vis --> v1["הקמת חיבור TCP"]
    vis --> v2["תוצאת TLS ו-SNI"]
    vis --> v3["RST / מי הפסיק לענות"]
    hid --> h1["payload של נתוני אפליקציה"]

איור 16: ההצפנה מאבדת רק את ה-payload; שלד השיחה עדיין קריא עם TLS במקומו.

כשעדיין צריך את ה-payload, Wireshark יכול לפענח TLS עם מפתחות סשן שנכתבים דרך משתנה הסביבה SSLKEYLOGFILE. התמיכה מוגבלת לחלק מהמימושים כמו Firefox, Chrome, Edge מבוסס Chromium וספריות משפחת OpenSSL; SChannel המובנה של Windows (אפליקציות שמשתמשות ב-WinHTTP או WinINET) אינו תומך במנגנון הזה.¹⁰ כי «מפתח הסשן נכתב לקובץ» אומר שמי שיש לו את הקובץ יכול לפענח את כל השיחה, זו לא טכניקת ייצור; מתייחסים אליה כשחזור וניפוי באגים בסביבת פיתוח.

flowchart TB
    accTitle: איך פענוח SSLKEYLOGFILE עובד ומה גבולותיו
    accDescr: מפתחות סשן שנכתבים דרך SSLKEYLOGFILE מאפשרים ל-Wireshark לפענח TLS, אבל רק חלק מהמימושים כמו Firefox ומשפחת Chrome תומכים ו-SChannel לא; מי שיש לו את קובץ המפתח יכול לפענח את השיחה, ולכן מתייחסים אליו כטכניקה לסביבת פיתוח בלבד
    env["הגדירו SSLKEYLOGFILE"] --> key["כתבו מפתחות סשן"]
    key --> ws["קראו ב-Wireshark"]
    key -.-> risk["בעל המפתח יכול לפענח"]
    risk -.-> dev["פיתוח בלבד"]
    env -.-> sup["רק חלק ממחסניות TLS"]
    sup -.-> sch["SChannel: אין תמיכה"]

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

כשתעבורה עוברת דרך פרוקסי פנימי, היעד שמופיע ב-capture הוא שרת הפרוקסי, ו-TLS זורם בתוך מנהרת CONNECT. השאלה הקודמת לאיזה פרוקסי האפליקציה בכלל פונה מסודרת במאמר הנלווה מאותו יום «פרוקסי ארגוני ואפליקציות Windows — סידור פתרון הפרוקסי ב-WinINET, WinHTTP ו-.NET».

9. קישור ללוג האפליקציה — לשים זמן על אותו ציר

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

ההליך נראה כך.

1. מזהים את זמן האירוע מלוג האפליקציה (למשל חריגת timeout ב-10:23:41). אם ערך ה-timeout הוא 30 שניות, ההתחלה אמורה להיות בסביבות 10:23:11.
2. מחליפים את תצוגת הזמן של Wireshark ל-[View] → [Time Display Format] → [Date and Time of Day], ומצמצמים את המרווח ב-display filter (אפשר גם לסנן לפי זמן, כמו ב-frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").
3. במרווח הזה מאשרים את סדר פרק 5 (handshake → RST → retransmission → ZeroWindow). אם אפשר ליישר עד «30 שניות לפני זמן ה-timeout בלוג נשלח SYN, ואחרי זה רק שידורי SYN חוזרים», ה-«timeout» של הלוג מוחלף בתצפית «בנקודת ה-capture הזאת לא חזרה בכלל תשובה» (האם ה-SYN לא הגיע לעמית, או ש-SYN/ACK החוזר אבד בדרך חזרה, אי אפשר לסגור מנקודת ה-capture הזאת לבד. אם צריך לסגור, לוכדים בשרת ומיישרים).
4. תמיד מתקנים את ההיסט בין זמן ה-capture לזמן הלוג (היסט השעון שמדדתם בסעיף 7.1, וסימון אזור הזמן של הלוג). שגיאת קישור של כמה שניות תנעץ את השיחה הלא נכונה כאשמה.

flowchart TB
    accTitle: הליך יישור לוג האפליקציה וה-packets
    accDescr: מזהים את זמן האירוע מלוג האפליקציה, מחשבים את זמן ההתחלה אחורה מערך ה-timeout, מצמצמים את המרווח ב-Wireshark ב-display filter, מאשרים צורות לפי הסדר, מתקנים את היסט השעון, ושמים אותם על אותו ציר זמן
    lg["1. זהו זמן האירוע מהלוג"] --> rev["חשבו התחלה אחורה מערך ה-timeout"]
    rev --> flt["2. צמצמו מרווח ב-display filter"]
    flt --> chk["3. אשרו צורות בסדר פרק 5"]
    chk --> adj["4. תקנו את היסט השעון"]
    adj --> done["מילת הלוג הופכת לתצפית"]

איור 18: מצמצמים את המרווח מזמן הלוג, מאשרים את הצורה, מתקנים את היסט השעון, ושמים אותם על אותו ציר.

כשמוסרים תוצאות חקירה לצד שלישי (ספק, ספק תקשורת, אנשי הרשת של הלקוח), חיתוך הרעש ב-filter לפני המסירה הוא גם נימוס וגם אמצעי בטיחות. ב-Wireshark מצמצמים לשיחה שמעניינת ב-display filter ושומרים «packets מוצגים בלבד» ב-[File] → [Export Specified Packets], ותקבלו pcapng קטן רק לטווח שצריך.

לבסוף, אזהרת טיפול. קובץ capture מכיל את התקשורת עצמה. הוא יכול לכלול credentials מפרוטוקולים בטקסט גלוי, cookies של HTTP ומפתחות API, תוכן דואר או דוחות, ומידע אישי. מחליטים את שלוש הנקודות הבאות כסט יחד עם הליך ה-capture.

• capture במינימום הנחוץ: מצמצמים את היעד ב-filters שלפני ה-capture (פרקים 3 ו-4) ומשאירים את חלון הזמן קצר ככל האפשר. אל תעשו «פשוט ללכוד הכול» בסביבת לקוח
• מצמצמים לפני המסירה: מייצאים רק את השיחה היעד; אל תכללו תעבורת צד שלישי לא קשורה. אם נשארים חלקים רגישים, מסכימים עם הנמען על הסתרה או אמצעי אחר
• שמירה ומחיקה: מחליטים איפה קובצי capture נשמרים, לכמה זמן, ומתי נמחקים, ומוחקים אותם כשהחקירה נגמרת

flowchart TB
    accTitle: שלוש החלטות לפני שמסירים קובץ capture
    accDescr: capture מכיל את התקשורת עצמה, ולכן מחליטים כסט עם הליך ה-capture שתצמצמו למינימום ב-filters שלפני ה-capture ובחלון זמן, תחלצו רק את השיחה היעד לפני מסירה כך שתעבורה לא קשורה לא תיכלל, ותחליטו מיקום שמירה ותקופה ותמחקו אחרי החקירה
    cap["capture = התעבורה"] --> p1["לכדו את המינימום"]
    cap --> p2["חלצו יעד קודם"]
    cap --> p3["הגדירו שמירה, מחקו"]
    p2 -.-> exp["סננו וייצאו"]

איור 19: מחליטים capture מינימום, צמצום לפני מסירה, ושמירה ומחיקה כסט עם הליך ה-capture.

10. סיכום

• שכבה אחת מתחת ל-«timeout» של לוג האפליקציה נמצאת עובדת ה-packets שעברו באמת על ה-wire. האם SYN לא קיבל תשובה, RST ניתק את החיבור, retransmissions המשיכו, או הופיע ZeroWindow משנה לאן מסתכלים הלאה.
• גם באתר שאי אפשר להתקין בו Wireshark אפשר ללכוד ב-pktmon ו-netsh trace המובנים של Windows. capture בכלי המובנה, קריאה ב-Wireshark במחשב שלכם — החלוקה הזאת היא הצורה הבסיסית.
• pktmon ארבעה צעדים: רישום filter → pktmon start --capture → pktmon stop → pktmon etl2pcap. כברירת מחדל זה מקוצר ל-128 בתים, אז אם רוצים את ה-payload אל תשכחו --pkt-size 0. לראות מיקום drop וסיבה הוא חוזק שיש רק ל-pktmon.
• netsh trace לוכד חבילת ספקי ETW כ-scenario, ועם persistent=yes יכול לשרוד reboot. ממירים את ה-ETL ל-pcapng ב-etl2pcapng כדי לקרוא.
• ב-Wireshark מתחילים מ-tcp.analysis.flags ומחפשים handshake, RST, retransmission ו-ZeroWindow בסדר הזה. מהיר יותר אם קולטים קודם את התמונה ב-Conversations וב-I/O Graph ואז מצמצמים.
• תעבורה ל-localhost לא עוברת NIC, ולכן אי אפשר ללכוד אותה בדרך הרגילה. משתמשים במתאם ה-loopback של Npcap או ב-capture בתוך ה-stack של pktmon.
• לוכדים בשני הצדדים ומיישרים, ו«איזה צד הפסיק לענות» נסגר. הנחת היסוד היא סנכרון שעון (w32tm). לאירוע שתנאי השחזור שלו אינם יודעים, ממתינים עם ring buffer.
• גם תחת TLS שלד השיחה גלוי. מתייחסים לפענוח (SSLKEYLOGFILE) כטכניקה לסביבת פיתוח בלבד, ומתייחסים לקובץ ה-capture עצמו כסודי: בונים capture מינימום, צמצום ומחיקה לתוך ההפעלה.

packet capture נתפס לעיתים כ«כלי של מומחה רשת», אבל בפועל הוא כלי חקירה מצד האפליקציה שמתחיל להיות בעל משמעות רק כשמיישרים אותו עם לוג האפליקציה. בפעם הבאה שחקירה נעצרת במילה האחת «timeout», לכו להסתכל שכבה אחת למטה.

מאמרים קשורים

• הסיבה לכך ששידור חוזר ב-TCP עוצר תקשורת עם מצלמה תעשייתית, ואיך מבודדים אותה
• The Misconception That TCP Lets You Receive in the Same Units You Send — Designing Reception Around a Byte Stream
• Getting a Real Feel for the OSI Model — Dissecting a Single HTTP Request Into Its Seven Layers
• A Practical Guide to Process Monitor (ProcMon) — Pinpointing “Settings Not Applied” and “ACCESS DENIED” in 10 Minutes
• Windows Firewall ואפליקציות עסקיות — רושמים inbound rule ב-installer
• פרוקסי ארגוני ואפליקציות Windows — סידור פתרון הפרוקסי ב-WinINET, WinHTTP ו-.NET

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בחקירות תקלות שמקורן בתקשורת כמו «תקשורת אפליקציית העסק נכשלת מדי פעם ואי אפשר למצוא את הסיבה» ו«רוצים לבודד שגיאת חיבור שקורה רק בסביבת הלקוח». אנחנו לוקחים תכנון capture (איפה, מה וכמה ללכוד), ניתוח Wireshark, קישור ללוג האפליקציה, ותיקון מצד האפליקציה כעבודה רציפה אחת.

• פיתוח יישומי Windows
• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• צרו קשר

קישורים

מאמרים קשורים

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

איך עושים packet capture בשרת לקוח שבו אי אפשר להתקין Wireshark?

משתמשים בכלי Windows המובנים pktmon או netsh trace, בלי להתקין תוכנה נוספת. עם pktmon רושמים filter במסוף מוגבה, מתחילים capture ב-pktmon start --capture, ועוצרים ב-pktmon stop. את קובץ ה-ETL שמתקבל ממירים ל-pcapng ב-pktmon etl2pcap, והניתוח חוזר ל-Wireshark במחשב שלכם. "capture בכלי המובנה, קריאה ב-Wireshark" היא החלוקה הבסיסית באתרים שמגבילים התקנות.

להשתמש ב-pktmon או ב-netsh trace?

אם במערכת ההפעלה יש pktmon (Windows 10 / Windows Server 2019 ואילך), מתחילים ב-pktmon. הפקודות פשוטות, אפשר לראות איזה רכיב ב-network stack זרק את ה-packet (drop reason), והמרת pcapng מסתיימת בכלי עצמו. netsh trace עדיף כשלוכדים במערכת ישנה בלי pktmon, כשרוצים לאסוף אירועי ETW של רכיבי Windows כ-scenario, או כשרוצים שה-capture ישרוד reboot עם persistent=yes. גם חומרי troubleshooting של Microsoft מצביעים על הסדר הזה: קודם pktmon, אחר כך netsh trace אם זה לא מספיק.

למה תעבורה ל-localhost (127.0.0.1) לא מופיעה ב-Wireshark?

תעבורה ל-localhost לא עוברת אף פעם NIC פיזי; היא חוזרת בנתיב loopback הפנימי של ה-OS. capture רגיל שמכוון למתאם פיזי לכן אף פעם לא רואה אותה. ב-Wireshark בוחרים "Adapter for loopback traffic capture" של Npcap ותוכלו ללכוד תעבורת loopback. pktmon לוכד בתוך ה-network stack, ולכן יכול לצפות גם בתעבורת loopback. בלבול נפוץ נוסף: "localhost" מתיישב ל-IPv6 ::1, כך שמסך שעוקב אחרי 127.0.0.1 ריק — מאשרים בציון כתובת מפורשת.

אפשר לראות את תוכן תעבורת HTTPS (TLS) ב-packet capture?

ה-payload של נתוני האפליקציה מוצפן ואינו נראה. "שלד" השיחה — חיבור וניתוק TCP, האם ה-TLS handshake הצליח, ניתוק RST, איזה צד הפסיק להגיב — נשאר גלוי גם בהצפנה, כך שרוב חקירות ה-timeout יכולות להתקדם עם TLS מוצפן. אם צריך את ה-payload, פענוח דרך SSLKEYLOGFILE קיים, אבל נתמך רק בחלק ממימושי TLS כמו Firefox ומשפחת Chrome; SChannel המובנה של Windows אינו נתמך. המנגנון כותב חומר מפתח סודי, ולכן מתייחסים אליו כאפשרות לסביבת פיתוח בלבד.

בטוח לשלוח קובץ capture לדלפק תמיכה חיצוני?

שליחה כמו שהוא מסוכנת. capture מכיל את התקשורת עצמה ויכול לכלול credentials מפרוטוקולים בטקסט גלוי, cookies, מפתחות API ומידע אישי. קודם, בזמן ה-capture, מצמצמים את ה-filter ואת חלון הזמן למינימום שצריך, ולפני המסירה מחלצים רק את השיחה היעד ב-display filter של Wireshark ומייצאים. למה שנשאר, מסכימים עם הנמען איך לטפל בחלקים רגישים (הסתרה, או מסירה בדרך אחרת) לפני השליחה. מחליטים מראש כמה זמן ישמרו קובצי capture ומתי יימחקו.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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