לכידת מנות ב-Windows בפועל — בחירה בין pktmon, netsh trace ו-Wireshark

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

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

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

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

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

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

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

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

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

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

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

flowchart TB
    accTitle: לכידה בכלי המובנה, קריאה ב-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 במחשב שלכם.

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

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

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

הזרימה הבסיסית של 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: צמצמו את היעד במסנן, התחילו לכידה, שחזרו את האירוע, עצרו, המירו ל-pcapng ב-etl2pcap, ולבסוף הסירו את המסנן הרשום
    fa["1. צמצמו יעד ב-filter add"] --> st["2. התחילו לכידה ב-start --capture"]
    st --> re["3. שחזרו את האירוע"]
    re -.-> ct["בדקו נפח ו-drop במונים"]
    re --> sp["4. עצרו"]
    sp --> cv["המירו ל-pcapng ב-etl2pcap"]
    cv --> rm["5. נקו ב-filter remove"]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. netsh trace בפועל — תרחישים, ETL ולכידות ששורדות אתחול

netsh trace הוא מנגנון המעקב שנמצא ב-Windows יותר זמן מ-pktmon. המאפיין שלו הוא שכ«תרחיש» הוא יכול להפעיל בבת אחת את כל סט ספקי ה-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 כדי להפעיל לכידת מנות, וצמצמו את היעד במסנן לכידה כמו ipv4.address=192.168.10.20. רשימת המסננים ב-netsh trace show capturefilterHelp.⁶
• העצירה מייצרת קובץ .cab בנוסף ל-ETL. ה-.cab מחזיק מידע מערכת כמו תצורת מתאם ו-build של מערכת ההפעלה, כך שהוא משמש גם כאיסוף סביבה.⁶
• רק סשן מעקב אחד יכול לרוץ בבת אחת. לפני שמתחילים לכידה אחרת, בדקו ב-netsh trace show status שלא נשאר סשן רץ.⁶
• הוסיפו persistent=yes והסשן שורד אתחול. לכידת «התקשורת נכשלת לרגע מיד אחרי אתחול» או «חיבור השירות בהפעלה נכשל» — אירועים שאי אפשר להספיק להתחיל ביד — היא הקרקע הייחודית של netsh trace.⁵

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

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

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

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

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

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

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

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

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

5. מבט ראשון על קריאה ב-Wireshark — מסנני תצוגה וניתוח TCP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:: 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 שניות» כשמיישרים את הלכידות.¹⁴ בסביבה עם היסט גדול, תיקון סנכרון הזמן קודם ואחר כך לכידה הוא בסוף הנתיב הקצר יותר.

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

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

7.2. ל«לא יודעים מתי זה יקרה» — חוצץ טבעת

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

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

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

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

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

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

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

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

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

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

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

כשעדיין צריך את המטען, 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: כתיבת מפתחות סשן יכולה לפענח, אבל המימושים הנתמכים מוגבלים, ואופי המפתח הופך את זה לטכניקה לסביבת פיתוח בלבד.

כשתעבורה עוברת דרך פרוקסי פנימי, היעד שמופיע בלכידה הוא שרת הפרוקסי, ו-TLS זורם בתוך מנהרת CONNECT. השאלה הקודמת לאיזה פרוקסי האפליקציה בכלל פונה מסודרת במאמר הנלווה מאותו יום «Corporate Proxies and Windows Apps — Sorting Out Proxy Resolution in WinINET, WinHTTP, and .NET».

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

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

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

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

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

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

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

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

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

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

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

10. סיכום

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

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

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

• הסיבה לכך ששידור חוזר ב-TCP עוצר תקשורת עם מצלמה תעשייתית, ואיך מבודדים אותה
• הטעות ש-TCP מאפשר לקבל באותן יחידות ששולחים — עיצוב קבלה סביב זרם בתים
• להרגיש באמת את מודל OSI — לפרק בקשת HTTP אחת לשבע השכבות שלה
• מדריך מעשי ל-Process Monitor (ProcMon) — לאתר «הגדרות לא הוחלו» ו-«ACCESS DENIED» ב-10 דקות
• חומת האש של Windows ואפליקציות עסקיות — רשמו כללי כניסה מהמתקין
• פרוקסי ארגוני ואפליקציות Windows — סידור פתרון פרוקסי ב-WinINET, WinHTTP ו-.NET

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

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

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

קישורים

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

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

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

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

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

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

שאלות נפוצות

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

איך לוכדים מנות בשרת לקוח שבו אי אפשר להתקין Wireshark?

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

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

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

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

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

אפשר לראות את תוכן תעבורת HTTPS (TLS) בלכידת מנות?

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

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

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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