จับแพ็กเก็ตบน 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 จับด้วยเครื่องมือในตัวของ OS นำไฟล์กลับเครื่องตนเองแล้วอ่านใน Wireshark — ด้วยการแบ่งแบบนั้น ยังเห็นแพ็กเก็ตได้ในไซต์ที่ห้ามติดตั้ง

บทความนี้มุ่งถึงเจ้าหน้าที่ไอทีบริษัทขนาดเล็กและกลาง และนักพัฒนาแอป 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, ข้อมูลแอป — ก็ช่วย กายวิภาคชั้นมีใน “รู้สึกถึงโมเดล OSI จริง ๆ”

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 ด้วย counters"]
    re --> sp["4. หยุด"]
    sp --> cv["แปลงเป็น pcapng ด้วย etl2pcap"]
    cv --> rm["5. เก็บกวาดด้วย filter remove"]

ภาพ 3: pktmon เริ่มที่การลงทะเบียนตัวกรอง แล้วจับ หยุด และแปลง และถอดตัวกรองอย่างชัดเจนตอนท้าย

จุดที่ต้องจำ:

• ลงทะเบียนตัวกรองก่อนเริ่มจับ เอกสาร Microsoft ก็แนะนำอย่างหนักให้ใส่ตัวกรองก่อนเริ่ม เพราะจับทราฟฟิกทั้งหมดเสียงดังเกินไป ตัวกรองระบุที่อยู่ IP พอร์ต ที่อยู่ MAC โปรโตคอล VLAN ID ได้ และลงทะเบียนได้ถึง 32 ตัว กรองหลายตัวเป็น OR แพ็กเก็ตถูกบันทึกถ้าตรงข้อใดข้อหนึ่ง³
• ตัวกรอง pktmon ไม่แยกต้นทางกับปลายทาง -i 192.168.10.20 หมายถึง “แพ็กเก็ตที่ที่อยู่นี้เป็นต้นทางหรือปลายทาง” ทิศทางแคบทีหลังด้วยตัวกรองแสดงผล Wireshark หลังแปลง³
• ขนาดแพ็กเก็ตเริ่มต้นคือ 128 ไบต์ พอสำหรับวิเคราะห์ส่วนหัว แต่ถ้าต้องการข้อมูลแอปด้วย ให้บันทึกทั้งแพ็กเก็ตด้วย --pkt-size 0⁸
• ล็อกเริ่มต้นเป็นโหมด circular (บัฟเฟอร์วงแหวน) ขนาดเริ่มต้น 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 เดียว และรายงานได้ว่าทิ้งที่ไหนเพราะอะไร (dropped) เพราะเห็นว่าแพ็กเก็ตถึงคอมโพเนนต์ใดและหายที่ไหน เหตุผล 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: การจับที่หลายจุดในสแตกบอกว่าแพ็กเก็ตไปได้ไกลแค่ไหนและถูก drop ที่ไหน พร้อมเหตุผล

• pktmon list แสดงคอมโพเนนต์เครือข่ายที่เฝ้าได้ (NIC สแตกโปรโตคอล ไดรเวอร์กรอง ฯลฯ) และรหัส
• pktmon counters --drop-reason รายการตัวนับผ่าน/drop ตามคอมโพเนนต์และเหตุผล drop ล่าสุด สะดวกเป็นตัดแรกก่อนวิเคราะห์ล็อก¹¹
• แปลงเป็นข้อความด้วย pktmon etl2txt แพ็กเก็ตที่ถูกทิ้งออกมาพร้อม drop และ dropReason³

ความสงสัยว่า “มีสิ่งใน OS ทิ้งสิ่งนี้ก่อนถึงแอป” ไม่จบด้วยการจ้อง Wireshark อย่างเดียว ความสามารถนี้ช่วย เช่น แยกกรณีไฟร์วอลล์ทิ้งเพราะไม่มีกฎขาเข้า (“ไฟร์วอลล์ Windows และแอปธุรกิจ”)

ข้อควรระวัง 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 เก็บข้อมูลระบบอย่างการตั้งค่าอะแดปเตอร์และบิลด์ OS จึงใช้เก็บสภาพแวดล้อมด้วย⁶
• เซสชันเทรซรันได้ทีละหนึ่ง ก่อนเริ่มจับอีกครั้ง ให้ตรวจด้วย 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 หรือไม่? นั่นคือสัญญาณว่าแอปฝั่งรับไม่อ่านจากซ็อกเก็ตและบัฟเฟอร์รับเต็ม เป็นเหตุสงสัยการออกแบบแอปฝั่งรับ (“ความเข้าใจผิดว่า TCP ให้รับเป็นหน่วยเดียวกับที่ส่ง”) มากกว่าเครือข่าย

flowchart TB
    accTitle: ลำดับรูปที่ต้องหาในการสืบ timeout
    accDescr: ยืนยันว่าจับมือสามทางครบ มี RST และต้นทาง 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 จริง แต่ถูกหันกลับบนเส้นลูปแบ็กภายใน OS การจับปกติที่เล็งอะแดปเตอร์จริงจึงไม่เห็น⁹

flowchart TB
    accTitle: ทำไมทราฟฟิกไป localhost ไม่ขึ้นในการจับ
    accDescr: ทราฟฟิกไป localhost ไม่เคยผ่าน NIC จริงและถูกหันกลับบนเส้นลูปแบ็กภายใน OS จึงไม่ขึ้นในการจับปกติที่เล็งอะแดปเตอร์จริง
    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 จริงแต่ OS ยังหันกลับภายใน จำไว้ว่า “ระบุ 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. จับที่ไหน — ฝั่งเดียว สองฝั่ง และการซิงก์นาฬิกา

คุณค่าของการจับถูกตัดสินด้วย “จับที่ไหน” กฎคร่าว ๆ ดังนี้

การจับฝั่งเดียวบอกแค่ “ข้อเท็จจริงจากตำแหน่งของฉัน” การส่งซ้ำที่ต่อเนื่องฝั่งไคลเอนต์ไม่แยกว่าแพ็กเก็ตที่ส่งหายบนเส้นทาง หรือถึงเซิร์ฟเวอร์แล้วคำตอบหาย จับทั้งสองฝั่งแล้ววางเรียง จะปิดได้ว่า “ไคลเอนต์ส่งแล้ว / เซิร์ฟเวอร์ไม่เคยรับ” — ฝั่งใดเงียบ เมื่อต้องปิดเส้นขอบความรับผิดชอบ (แอป OS อุปกรณ์เครือข่าย หรือปลายอีกฝั่ง) คุ้มที่จะจัดจับสองฝั่งตั้งแต่ต้น

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: ค่าเริ่มต้นคือโหมด circular ตั้งเพดาน (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 คำถามก่อนหน้าว่าแอปมุ่งไปพร็อกซีใด จัดไว้ในบทคู่วันเดียวกัน “พร็อกซีองค์กรและแอป Windows — จัดระเบียบการแปลงพร็อกซีใน WinINET, WinHTTP และ .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?

ถ้า OS มี pktmon (Windows 10 / Windows Server 2019 เป็นต้นไป) ให้เริ่มที่ pktmon คำสั่งเรียบง่าย เห็นได้ว่าคอมโพเนนต์ใดในสแตกเครือข่ายทิ้งแพ็กเก็ต (เหตุผล drop) และการแปลง pcapng ทำได้เอง netsh trace เหมาะกว่าเมื่อจับบน OS เก่าที่ไม่มี pktmon เมื่อต้องการเก็บเหตุการณ์ ETW ของคอมโพเนนต์ Windows เป็นสถานการณ์ หรือเมื่อต้องการให้การจับรอดรีบูตด้วย persistent=yes เอกสารแก้ปัญหาของ Microsoft ก็ชี้ลำดับนี้เช่นกัน คือ pktmon ก่อน แล้วค่อย netsh trace ถ้ายังไม่พอ

ทำไมทราฟฟิกไป localhost (127.0.0.1) ไม่ขึ้นใน Wireshark?

ทราฟฟิกไป localhost ไม่เคยผ่าน NIC จริง แต่ถูกหันกลับบนเส้นลูปแบ็กภายใน OS การจับปกติที่เล็งอะแดปเตอร์จริงจึงไม่เห็น ใน 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 ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก