Bắt gói tin trên Windows trong thực tế — chọn giữa pktmon, netsh trace và Wireshark

“Giao tiếp máy chủ của ứng dụng nghiệp vụ thất bại vài lần mỗi tháng. Nhật ký ứng dụng chỉ viết ‘timeout’. Nhật ký phía máy chủ lúc đó không có lỗi tương ứng. Chúng tôi không biết cách tái hiện” — trong tư vấn điều tra lỗi, dạng này xuất hiện liên tục.

Nhật ký ứng dụng chỉ giữ những gì ứng dụng “quyết định ghi”. Bạn thấy kết quả là timeout, nhưng yêu cầu kết nối (SYN) có được trả lời không, kết nối đã lập rồi máy chủ im, bị cắt bằng RST, hay gói có tới đích không, sống một tầng dưới nhật ký — trong các gói thực sự đi trên dây. Nếu Process Monitor là cách nhìn một tầng xuống truy cập tệp và registry, bắt gói tin là cách nhìn một tầng xuống cuộc hội thoại.

flowchart TB
    accTitle: Các gói một tầng dưới nhật ký ứng dụng
    accDescr: Nhật ký ứng dụng chỉ giữ những gì ứng dụng quyết định ghi; SYN không được trả lời, phía kia im sau khi kết nối, RST cắt, hay gói có tới chỉ sống trong các gói thực sự đi trên dây
    log["Nhật ký ứng dụng"] --> dec["Chỉ còn những gì quyết định ghi"]
    dec --> to["Kết quả là timeout một chữ"]
    to -->|nhìn một tầng xuống| pkt["Các gói thực sự đi trên dây"]
    pkt --> q1["Không trả lời SYN?"]
    pkt --> q2["Im sau khi kết nối?"]
    pkt --> q3["Bị cắt bằng RST?"]
    pkt --> q4["Có tới đích không?"]

Hình 1: Nhật ký chỉ giữ kết quả; phần tách timeout chỉ sống trong các gói một tầng dưới.

Chỗ người ta thường kẹt là ràng buộc “không được cài Wireshark trên máy chủ khách hàng”. Hiện trường mà kiểm soát thay đổi hoặc chính sách bảo mật không phê phần mềm thêm cho điều tra không hiếm. Windows, tuy vậy, đã kèm sẵn hai công cụ bắt gói: pktmon và netsh trace. Bắt bằng công cụ sẵn có của hệ điều hành, mang tệp về máy mình và đọc trong Wireshark — với cách chia đó, bạn vẫn thấy gói trên hiện trường cấm cài đặt.

Bài viết dành cho nhân sự CNTT doanh nghiệp vừa và nhỏ và lập trình viên ứng dụng Windows. Nó sắp xếp cách chọn giữa pktmon, netsh trace và Wireshark, cùng quy trình thực tế của từng cái. Bẫy lưu lượng loopback, quyết định bắt ở máy khách hay máy chủ, sống với TLS che phần tải, và đối chiếu lần bắt với nhật ký ứng dụng đều dựa trên nguồn sơ cấp tính đến tháng 8 năm 2026.

1. Kết luận trước

• “Bắt bằng công cụ sẵn có, đọc bằng Wireshark” là cách chia việc cơ bản tại hiện trường. Dù không cài được phần mềm trên máy chủ khách, pktmon và netsh trace đã có trong Windows. Chuyển nhật ký bắt được sang pcapng và phân tích trong Wireshark trên máy mình.¹²
• pktmon là công cụ bắt gói sẵn có từ Windows 10 / Windows Server 2019 trở lên. Dùng bốn bước — đăng ký bộ lọc, bắt đầu, dừng, chuyển — và điểm mạnh riêng là thấy thành phần nào của ngăn xếp mạng đã loại gói (lý do drop).³⁴
• netsh trace là công cụ sẵn có cũ hơn; nó có thể bật một nhóm nhà cung cấp ETW như một “kịch bản”. Ngoài gói, nó còn giữ sự kiện bên trong thành phần Windows, và với persistent=yes lần bắt có thể sống sót qua khởi động lại.⁵⁶
• Cả hai ghi ETL, Wireshark không mở được nguyên trạng. Chuyển sang pcapng bằng pktmon etl2pcap với pktmon, và bằng etl2pcapng mã nguồn mở của Microsoft với netsh trace.¹²
• Chính Microsoft chỉ “pktmon trước, rồi netsh trace nếu chưa đủ, và Wireshark cho phân tích giao thức”. Cách chia trong bài theo khuyến nghị chính thức đó.⁷
• Mặc định pktmon chỉ ghi 128 byte đầu mỗi gói. Nếu định đọc phần tải trong Wireshark, đừng quên --pkt-size 0 (ghi cả gói) khi bắt đầu.⁸
• Lưu lượng tới localhost không xuất hiện trong lần bắt thông thường. Nó không đi qua NIC. Dùng bộ điều hợp loopback Npcap trong Wireshark, hoặc bắt trong ngăn xếp của pktmon với công cụ sẵn có.⁹
• Dù TLS che phần tải, bạn vẫn biết được nhiều. Thiết lập kết nối, bắt tay TLS thành hay thất, RST, và bên nào im vẫn thấy được dù đã mã hóa. Giải mã qua SSLKEYLOGFILE là kỹ thuật chỉ dành cho môi trường phát triển.¹⁰
• Lần bắt chứa chính cuộc giao tiếp. Hãy giả định nó có thể gồm thông tin đăng nhập và dữ liệu cá nhân, và đưa bắt tối thiểu cần thiết cùng thu hẹp trước bàn giao vào quy trình.

2. Ba công cụ bắt gói và cách chọn

Trước hết, một bảng vai trò của ba công cụ.

Một câu: pktmon và netsh trace là công cụ “bắt”, Wireshark là công cụ “đọc”. Wireshark cũng bắt được, nhưng không dùng được nơi không được cài. Ngược lại, ETL của công cụ sẵn có có thể chuyển thành văn bản rồi đọc, nhưng nhìn nó không có bộ lọc hiển thị và phân tích TCP là cực hình. “Bắt tại hiện trường bằng công cụ sẵn có, chuyển pcapng, đọc trong Wireshark trên máy mình” là đường ngắn nhất trên hiện trường bị ràng buộc.

flowchart TB
    accTitle: Bắt bằng công cụ sẵn có, đọc bằng Wireshark
    accDescr: Tại hiện trường bạn bắt ETL bằng pktmon hoặc netsh trace, chuyển mỗi cái sang pcapng bằng công cụ chuyển của nó, rồi phân tích trong Wireshark trên máy mình
    pk["pktmon (sẵn có)"] --> etla["Tệp ETL"]
    ns["netsh trace (sẵn có)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["Phân tích trong Wireshark trên máy mình"]

Hình 2: Tại hiện trường bạn bắt ETL bằng công cụ sẵn có, chuyển pcapng, và đọc trong Wireshark trên máy mình.

Hướng dẫn điều tra mất gói của Microsoft cùng hình: bắt và cô lập nguyên nhân bằng pktmon trước, rồi chuyển sang dấu vết cấp thành phần như netsh trace start scenario=InternetClient nếu chưa đủ, và phân tích hành vi giao thức trong Wireshark.⁷

Để đọc những gì một gói thực sự cho thấy, cũng nên có hình các tầng xếp chồng — Ethernet, IP, TCP, dữ liệu ứng dụng. Giải phẫu tầng được minh họa trong “Cảm nhận thật mô hình OSI”.

3. pktmon trong thực tế — Lọc, bắt đầu, dừng, chuyển

Luồng cơ bản của pktmon gồm bốn bước. Chạy trong terminal nâng quyền.

:: 1. Đăng ký bộ lọc trước để thu hẹp mục tiêu (TCP 8443 trên máy chủ 192.168.10.20)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. Bắt đầu bắt gói. Ghi cả gói, ghi đè trong bộ đệm vòng 1GB
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Tái hiện sự cố. Trong lúc chờ có thể kiểm tra lưu lượng và drop bằng counters
pktmon counters --drop-reason

:: 4. Dừng, rồi chuyển sang pcapng cho Wireshark
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. Dọn bộ lọc đã đăng ký (bộ lọc ở lại cho đến khi xóa rõ ràng).
::    Lưu ý: filter remove không nhận tên; nó xóa "tất cả" bộ lọc đã đăng ký.
::    Trên máy có thể còn bộ lọc của cuộc điều tra khác, hãy kiểm tra trước bằng pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: Quy trình cơ bản của pktmon
    accDescr: Thu hẹp mục tiêu bằng bộ lọc, bắt đầu bắt, tái hiện sự cố, dừng, chuyển pcapng bằng etl2pcap, rồi gỡ bộ lọc đã đăng ký
    fa["1. Thu hẹp mục tiêu bằng filter add"] --> st["2. Bắt đầu bắt bằng start --capture"]
    st --> re["3. Tái hiện sự cố"]
    re -.-> ct["Xem lưu lượng và drop bằng counters"]
    re --> sp["4. Dừng"]
    sp --> cv["Chuyển pcapng bằng etl2pcap"]
    cv --> rm["5. Dọn bằng filter remove"]

Hình 3: pktmon bắt đầu bằng đăng ký bộ lọc, rồi bắt, dừng và chuyển, và bạn gỡ bộ lọc tường minh ở cuối.

Điểm cần nhớ:

• Đăng ký bộ lọc trước khi bắt đầu. Tài liệu Microsoft cũng khuyến nghị mạnh việc áp bộ lọc trước khi bắt, vì bắt mọi lưu lượng quá ồn. Bộ lọc có thể chỉ địa chỉ IP, cổng, địa chỉ MAC, giao thức, VLAN ID, v.v., và đăng ký tối đa 32. Nhiều bộ lọc là OR: gói được ghi nếu khớp bất kỳ cái nào.³
• Bộ lọc pktmon không phân nguồn và đích. -i 192.168.10.20 nghĩa là “các gói mà địa chỉ này là nguồn hoặc đích”. Hướng được thu hẹp sau bằng bộ lọc hiển thị Wireshark sau khi chuyển.³
• Kích thước gói mặc định là 128 byte. Đủ để phân tích header, nhưng nếu muốn cả dữ liệu ứng dụng, ghi cả gói bằng --pkt-size 0.⁸
• Nhật ký mặc định chế độ circular (bộ đệm vòng), kích thước mặc định 512MB. Đổi trần bằng --file-size, và --log-mode real-time in ra màn hình theo thời gian thực và không tạo tệp nhật ký. Xác nhận trước ở chế độ thời gian thực rằng bạn thực sự thấy lưu lượng quan tâm, rồi đặt lần bắt sản xuất, tránh lần bắt trống.⁸

flowchart TB
    accTitle: Cách bộ lọc pktmon có hiệu lực
    accDescr: Nhiều bộ lọc đã đăng ký ghi theo khớp OR, địa chỉ chỉ định không phân nguồn và đích, và hướng được thu hẹp sau bằng bộ lọc hiển thị Wireshark sau khi chuyển
    f1["Bộ lọc 1"] --> orc["Ghi nếu bất kỳ cái nào khớp"]
    f2["Bộ lọc 2"] --> orc
    f3["Bộ lọc 3 (tối đa 32)"] --> orc
    orc --> rec["Được ghi trong nhật ký bắt (OR)"]
    rec -.-> nodir["Không phân nguồn và đích"]
    nodir -.-> ws["Thu hẹp hướng trong Wireshark sau khi chuyển"]

Hình 4: Nhiều bộ lọc hoạt động như OR, và máy chủ là nguồn hay đích được thu hẹp trong Wireshark sau khi chuyển.

3.1. Việc chỉ pktmon làm được — thấy gói bị loại ở đâu

Giá trị riêng của pktmon so với Wireshark là nó bắt gói tại nhiều điểm trong ngăn xếp mạng, không phải một NIC, và có thể báo nơi nào và vì sao gói bị loại (dropped). Vì bạn thấy gói tới thành phần nào và biến mất ở đâu, lý do drop như “lệch MTU” hoặc “bộ lọc VLAN” đưa tới nguyên nhân mà không phải tìm mò.⁴

flowchart TB
    accTitle: pktmon bắt tại nhiều điểm trong ngăn xếp
    accDescr: pktmon bắt gói tại nhiều điểm trong ngăn xếp mạng chứ không phải một NIC, nên có thể báo kèm lý do thành phần nào gói đã tới và nơi nó bị loại
    pin["Gói"] --> p1["Bắt tại điểm 1"]
    p1 --> p2["Bắt tại điểm 2"]
    p2 --> p3["Bị loại tại điểm 3"]
    p3 -.-> rz["Báo vị trí và lý do drop"]
    rz -.-> ex["ví dụ lệch MTU hoặc bộ lọc VLAN"]

Hình 5: Bắt tại nhiều điểm trong ngăn xếp cho biết gói đi được bao xa và bị drop ở đâu, kèm lý do.

• pktmon list hiện các thành phần mạng có thể giám sát (NIC, ngăn xếp giao thức, trình điều khiển bộ lọc, v.v.) và ID của chúng.
• pktmon counters --drop-reason liệt kê bộ đếm đi qua/drop theo thành phần và lý do drop gần nhất. Tiện làm nhát cắt đầu trước khi phân tích nhật ký.¹¹
• Chuyển sang văn bản bằng pktmon etl2txt và các gói bị loại được phát kèm drop và dropReason.³

Nghi ngờ “có thứ gì trong hệ điều hành đang loại cái này trước khi tới ứng dụng” không kết thúc được chỉ bằng nhìn Wireshark. Khả năng này giúp, ví dụ, cô lập trường hợp tường lửa loại vì thiếu quy tắc vào (“Tường lửa Windows và ứng dụng nghiệp vụ”).

Một lưu ý. pktmon ghi cùng một gói tại nhiều điểm trong ngăn xếp, nên chuyển nguyên trạng sang pcapng có thể làm cùng gói xuất hiện hơn một lần. pcapng không mang “thành phần nào đã bắt”, nên khi đọc trong Wireshark bước chuẩn là chuyển với --component-id để chọn một điểm (hoặc để drop riêng trong tệp khác bằng --drop-only).¹

flowchart TB
    accTitle: Vì sao cùng một gói có thể xuất hiện hai lần sau khi chuyển pcapng
    accDescr: pktmon ghi cùng một gói tại nhiều điểm trong ngăn xếp, pcapng không giữ thành phần nào đã bắt nên có thể trùng, và bước chuẩn là chuyển sau khi thu hẹp điểm bằng component-id hoặc để drop riêng trong tệp drop-only
    same["Cùng gói được ghi tại nhiều điểm"] --> conv["Chuyển pcapng nguyên trạng"]
    conv --> lost["Thông tin điểm bắt không được mang sang"]
    lost --> dup["Cùng gói xuất hiện hơn một lần"]
    dup --> c1["Thu hẹp điểm bằng --component-id"]
    dup --> c2["Tệp riêng bằng --drop-only"]

Hình 6: Thông tin điểm bắt không được mang vào pcapng, nên bước chuẩn là thu hẹp điểm trước khi chuyển.

4. netsh trace trong thực tế — Kịch bản, ETL và lần bắt sống sót qua khởi động lại

netsh trace là cơ chế theo dõi có trong Windows lâu hơn pktmon. Đặc trưng: như một “kịch bản” nó có thể bật cùng lúc toàn bộ nhà cung cấp ETW liên quan vấn đề đó.⁶

:: 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

• Thêm capture=yes để bật bắt gói, và thu hẹp mục tiêu bằng bộ lọc bắt như ipv4.address=192.168.10.20. Danh sách bộ lọc nằm trong netsh trace show capturefilterHelp.⁶
• Dừng sẽ tạo tệp .cab ngoài ETL. .cab giữ thông tin hệ thống như cấu hình card và bản dựng hệ điều hành, nên kiêm thu thập môi trường.⁶
• Chỉ một phiên theo dõi chạy được một lúc. Trước khi bắt phiên khác, kiểm tra bằng netsh trace show status rằng không còn phiên sót.⁶
• Thêm persistent=yes và phiên sống sót qua khởi động lại. Bắt “giao tiếp hỏng một lúc ngay sau khởi động lại” hoặc “kết nối dịch vụ lúc khởi động thất bại” — sự cố không kịp bắt bằng tay — là địa bàn riêng của netsh trace.⁵

flowchart TB
    accTitle: Bắt một kịch bản netsh trace
    accDescr: Bắt đầu bằng kịch bản sẽ bật một nhóm nhà cung cấp ETW, capture=yes cũng bắt gói, và dừng tạo tệp ETL cùng tệp .cab
    sc["Bắt đầu bằng kịch bản"] --> pv["Bật nhóm nhà cung cấp"]
    sc -->|capture=yes| pc["Gói cũng được bắt"]
    pv --> re["Tái hiện sự cố"]
    pc --> re
    re --> sp["Dừng"]
    sp --> etl["Tệp ETL"]
    sp --> cab[".cab (thông tin hệ thống)"]

Hình 7: Bắt đầu bằng kịch bản sẽ bật một nhóm nhà cung cấp, và dừng tạo ETL cùng .cab.

4.1. Làm ETL đọc được trong Wireshark — etl2pcapng

ETL của netsh trace không mở nguyên trạng trong Wireshark. etl2pcapng, công cụ mã nguồn mở Microsoft công bố trên GitHub, chuyển các gói trong ETL bắt bằng netsh trace start capture=yes sang pcapng.²

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

Khi chuyển, etl2pcapng ghi ID tiến trình liên quan mỗi gói thành chú thích gói. Thấy “lưu lượng của tiến trình nào” trong Wireshark giúp khi nhiều ứng dụng trên cùng máy chủ đang nói chuyện.²

Phía sự kiện ETW (sự kiện nội bộ Windows mà nhà cung cấp kịch bản ghi) không được chuyển sang pcapng. Nếu cũng muốn sự kiện, chuyển sang văn bản bằng netsh trace convert input=C:\temp\nettrace.etl, hoặc mở ETL trong Windows Performance Analyzer.⁵⁷

flowchart TB
    accTitle: Đọc ETL netsh trace tách thành hai đường
    accDescr: Các gói trong ETL chuyển pcapng bằng etl2pcapng và đọc trong Wireshark; sự kiện ETW không chuyển pcapng, nên đọc bằng netsh trace convert hoặc Windows Performance Analyzer
    etl["ETL netsh trace"] --> pk["Gói"]
    etl --> ev["Sự kiện ETW"]
    pk -->|etl2pcapng| pc["Chuyển pcapng"]
    pc --> ws["Đọc trong Wireshark"]
    pc -.-> pid["ID tiến trình còn lại dạng chú thích"]
    ev -.-> no["Không chuyển pcapng"]
    no --> alt["Đọc bằng convert hoặc WPA"]

Hình 8: Trong ETL, gói được chuyển pcapng để đọc; sự kiện ETW đọc bằng cách khác.

5. Cái nhìn đầu khi đọc trong Wireshark — Bộ lọc hiển thị và phân tích TCP

Mở pcapng xong, trước hết cắt nhiễu bằng bộ lọc hiển thị. Các bộ thông dụng nằm trong bảng.¹²¹³

tcp.analysis.* là cờ phân tích Wireshark gán bằng cách theo số tuần tự TCP. Truyền lại, ACK trùng, lệch thứ tự, ZeroWindow và tương tự được bắt máy móc, nên cách chuẩn bắt đầu đọc là gõ tcp.analysis.flags trước và liệt kê các chỗ “trông như vấn đề”.¹³

Trong điều tra timeout, tìm các hình sau theo thứ tự.

1. Bắt tay ba chiều đã hoàn tất chưa? Có đủ ba gói SYN → SYN/ACK → ACK không? Nếu SYN lặp mà không có trả lời, nó không tới phía kia, hoặc bị loại im lặng ở giữa (mẫu tường lửa điển hình).
2. Bên nào gửi RST? RST ngay vào SYN nghĩa là không ai nghe trên cổng đích; RST sau khi kết nối đã lập nghĩa là một bên ép cắt. IP nguồn của RST là bằng chứng trực tiếp “ai cắt”.
3. Truyền lại có đang tiếp không? Truyền lại lặp cùng một phân đoạn là dấu xác nhận (ACK) không về phía gửi. Dữ liệu đi bị mất hay ACK về bị mất không kết luận được từ lần bắt một phía (vì thế “bắt cả hai phía” ở chương sau quan trọng). Truyền lại và timeout được nói sâu hơn trong “Vì sao truyền lại TCP làm khựng giao tiếp camera công nghiệp”.
4. Có ZeroWindow không? Đó là dấu ứng dụng nhận không đọc từ socket và bộ đệm nhận đầy. Đó là cơ sở nghi thiết kế ứng dụng nhận (“Hiểu lầm rằng TCP cho phép nhận đúng đơn vị bạn gửi”) chứ không phải mạng.

flowchart TB
    accTitle: Thứ tự các hình cần tìm khi điều tra timeout
    accDescr: Xác nhận bắt tay ba chiều hoàn tất, có RST và nguồn RST, truyền lại tiếp diễn, rồi ZeroWindow, để đánh dấu nguyên nhân lần đầu
    hs{"SYN có được trả lời?"} -->|không| ng["Không bao giờ tới（Tường lửa điển hình）"]
    hs -->|có| rs{"Có RST?"}
    rs -->|có| who["Nguồn RST đã cắt"]
    rs -->|không| rt{"Truyền lại tiếp?"}
    rt -->|có| ack["ACK không về"]
    rt -->|không| zw{"Có ZeroWindow?"}
    zw -->|có| app["Bên nhận không đọc"]

Hình 9: Tìm bắt tay, RST, truyền lại, rồi ZeroWindow theo thứ tự đó thu hẹp chỗ nhìn tiếp.

Trước khi đọc từng gói, cũng nên lấy toàn cảnh bằng thống kê. [Statistics] → [Conversations] là danh sách “cặp IP / cổng nào nói, từ lúc nào đến lúc nào, bao nhiêu”, để bạn xác định cuộc hội thoại quan tâm rồi lọc chỉ cuộc đó. [Statistics] → [I/O Graph] là đồ thị lưu lượng theo thời gian; các hình như “từ lúc này, một chiều im” nhảy ra. Chuột phải cuộc hội thoại TCP quan tâm rồi chọn [Follow] → [TCP Stream] để đọc trao đổi của kết nối đó dạng văn bản rõ.

flowchart TB
    accTitle: Lấy bức tranh bằng thống kê, rồi thu hẹp một cuộc hội thoại
    accDescr: Liệt kê cuộc hội thoại nào nói khi nào và bao nhiêu trong Conversations, lấy khoảng im từ I/O Graph, lọc cuộc hội thoại quan tâm, và đọc như luồng TCP
    ov["Lấy toàn cảnh bằng thống kê"] --> cv["Danh sách hội thoại trong Conversations"]
    ov --> io["Xem lưu lượng trên I/O Graph"]
    cv --> flt["Lọc cuộc hội thoại quan tâm"]
    io -.-> mute["Khoảng im trở nên thấy được"]
    flt --> fs["Đọc như luồng TCP"]

Hình 10: Trước khi đọc từng gói, lấy bức tranh bằng thống kê, thu hẹp cuộc hội thoại quan tâm, rồi đọc hết.

6. Bẫy loopback — lưu lượng tới localhost không bao giờ đi qua NIC

Cố điều tra giao tiếp giữa các ứng dụng trên cùng một PC — ví dụ ứng dụng nghiệp vụ kết nối dịch vụ trung gian tại localhost:8080 — rồi kẹt ở “Wireshark không hiện gì” là bẫy kinh điển.

Nguyên nhân rõ. Lưu lượng tới localhost (127.0.0.1) không bao giờ đi qua NIC vật lý; nó được quay vòng trên đường loopback nội bộ của hệ điều hành. Lần bắt thông thường nhắm card vật lý vì thế không bao giờ thấy.⁹

flowchart TB
    accTitle: Vì sao lưu lượng tới localhost không xuất hiện trong lần bắt
    accDescr: Lưu lượng tới localhost không bao giờ đi qua NIC vật lý và được quay vòng trên đường loopback nội bộ của hệ điều hành, nên không bao giờ xuất hiện trong lần bắt thông thường nhắm card vật lý
    app["Ứng dụng"] --> stack["Ngăn xếp mạng"]
    stack -->|bên ngoài| nic["NIC vật lý"]
    nic --> seen["Thấy trong lần bắt thông thường"]
    stack -->|localhost| lo["Quay vòng trong hệ điều hành"]
    lo -.-> miss["Không có trong lần bắt thông thường"]
    lo -.-> alt["Loopback Npcap hoặc pktmon"]

Hình 11: Lưu lượng tới localhost được quay vòng trước NIC, lần bắt card vật lý không bao giờ thấy.

Có hai cách xử lý.

• Khi bắt trong Wireshark: Chọn “Adapter for loopback traffic capture” của Npcap làm mục tiêu bắt. Bộ cài Windows của Wireshark (3.0 trở lên) kèm Npcap, nên nếu Wireshark đã cài bạn dùng được mà không cần thêm.⁹
• Khi bắt bằng công cụ sẵn có: pktmon bắt tại nhiều điểm trong ngăn xếp mạng chứ không ngoài NIC⁴, nên cũng quan sát được lưu lượng loopback. Để chắc, trước khi đặt chờ tái hiện sản xuất, xác nhận trên máy đó bằng hiển thị thời gian thực pktmon start -c -m real-time rằng lưu lượng loopback bạn quan tâm thực sự thấy được.

Cũng đề phòng hai nhầm lẫn.

• “localhost” có thể phân giải thành IPv6 ::1. Ứng dụng kết nối IPv6 ::1, nhưng người điều tra chỉ nhìn 127.0.0.1 (IPv4) và kết luận sai “không có lưu lượng”. Kéo bộ lọc hiển thị sang cả hai, như ip.addr == 127.0.0.1 || ipv6.addr == ::1, hoặc đặt đích của ứng dụng thành địa chỉ tường minh.⁹
• Lưu lượng tới IP thật của chính mình cũng không lên dây. Khi cùng một PC kết nối từ 192.168.10.5 tới 192.168.10.5, đích là IP thật nhưng hệ điều hành vẫn quay vòng bên trong. Nhớ rằng “tôi đã chỉ IP thật, vậy phải đi qua NIC” không được bảo đảm.

flowchart TB
    accTitle: Nhầm lẫn khi localhost phân giải thành IPv6
    accDescr: localhost của ứng dụng có thể phân giải thành IPv6 ::1, và nếu người điều tra chỉ nhìn 127.0.0.1 họ kết luận sai là không có lưu lượng, nên kéo bộ lọc hiển thị sang cả hai địa chỉ hoặc xác nhận đích là địa chỉ tường minh
    app["Ứng dụng kết nối localhost"] --> v6["Thực ra phân giải thành ::1 (IPv6)"]
    look["Người điều tra chỉ nhìn 127.0.0.1"] --> none["Màn hình không hiện gì"]
    v6 --> none
    none --> fix1["Kéo bộ lọc sang cả hai địa chỉ"]
    none --> fix2["Đặt đích thành địa chỉ tường minh"]

Hình 12: Đề phòng nhầm lẫn localhost phân giải thành ::1 và chỉ nhìn 127.0.0.1 dẫn tới “không có lưu lượng”.

7. Bắt ở đâu — một phía, hai phía và đồng bộ đồng hồ

Giá trị lần bắt do “bạn bắt ở đâu” quyết định. Quy tắc ngón cái như sau.

Lần bắt một phía chỉ nói “sự thật nhìn từ vị trí của tôi”. Truyền lại tiếp diễn phía khách không phân biệt gói gửi biến mất trên đường, hay tới máy chủ rồi câu trả lời biến mất. Bắt cả hai phía và xếp chúng, bạn chốt được “khách đã gửi / máy chủ không bao giờ nhận” — bên nào im. Khi cần chốt ranh giới trách nhiệm (ứng dụng, hệ điều hành, thiết bị mạng, hay phía kia), đáng sắp xếp lần bắt hai phía từ đầu.

flowchart TB
    accTitle: Lần bắt một phía và hai phía nói gì
    accDescr: Lần bắt một phía không phân biệt gói đi biến mất hay câu trả lời về biến mất; bắt cả hai phía và xếp chúng chốt bên nào im
    one["Bắt một phía"] --> fact["Sự thật từ phía bạn"]
    fact --> und["Đi ra hay về?"]
    both["Bắt cả hai phía"] --> mt["Xếp chúng"]
    mt --> fix["Bên nào im"]
    mt -.-> pre["Cần đồng bộ đồng hồ"]

Hình 13: Một phía chỉ hiện sự thật bạn thấy; xếp cả hai phía mới lần đầu chốt ranh giới trách nhiệm.

7.1. Tiền đề đối chiếu là đồng bộ đồng hồ

Để xếp lần bắt từ hai phía, đồng hồ hai máy phải khớp. Trước khi bắt, kiểm tra và ghi lệch đồng hồ.

:: 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 là lệnh hiện lệch thời gian giữa bạn và máy đối tác, và trở thành căn cứ hiệu chỉnh như “đồng hồ máy chủ +0,8 giây” khi xếp các lần bắt.¹⁴ Trong môi trường lệch lớn, sửa đồng bộ thời gian trước rồi mới bắt cuối cùng ngắn hơn.

flowchart TB
    accTitle: Quy trình kiểm tra lệch đồng hồ trước khi đối chiếu
    accDescr: Xác nhận trạng thái đồng bộ thời gian của mình bằng w32tm, đo và ghi lệch so với máy chủ đối tác bằng stripchart, dùng lệch đó làm căn cứ hiệu chỉnh khi xếp, và nếu lệch lớn thì sửa đồng bộ trước rồi mới bắt
    st["Kiểm tra trạng thái đồng bộ bằng query"] --> mc["Đo lệch bằng stripchart"]
    mc --> rc["Ghi lệch"]
    rc --> use["Căn cứ hiệu chỉnh lúc đối chiếu"]
    mc -.-> big["Nếu lệch lớn, sửa đồng bộ trước"]

Hình 14: Đo và ghi lệch đồng hồ trước khi bắt, và dùng làm căn cứ hiệu chỉnh khi xếp các lần bắt.

7.2. Với “không biết khi nào xảy ra” — bộ đệm vòng

Với sự cố không biết điều kiện tái hiện, bước cơ bản là để bộ đệm vòng chạy rồi dừng khi sự cố xảy ra.

• pktmon: Mặc định là chế độ circular. Đặt trần (MB) bằng --file-size; gói cũ hơn bị ghi đè.⁸
• netsh trace: Chỉ định maxSize=1024 filemode=circular.⁵
• Wireshark: Trong [Capture] → [Options] → [Output] có thể cấu hình “nhiều tệp + bộ đệm vòng”. Nó xoay theo kích thước tệp hoặc thời gian và chỉ giữ N tệp mới nhất, nên chạy lâu được với trần dùng đĩa.¹⁵

Mọi trường hợp, thống nhất với người tại hiện trường quy tắc khi sự cố xảy ra, “ghi giờ trước, rồi” mới dừng lần bắt. Bộ đệm vòng xóa quá khứ càng để lâu, nên nếu đường từ lúc xảy ra tới lúc dừng dài, khoảng bạn quan tâm bị ghi đè.

flowchart TB
    accTitle: Chờ bằng lần bắt bộ đệm vòng
    accDescr: Với sự cố không biết điều kiện tái hiện, để bộ đệm vòng chạy, và khi sự cố xảy ra ghi giờ rồi dừng ngay; dừng muộn thì gói cũ hơn bị ghi đè và khoảng bạn quan tâm biến mất
    st["Bắt đầu lần bắt bộ đệm vòng"] --> wt["Để chạy và chờ"]
    wt --> ev["Sự cố xảy ra"]
    ev --> memo["Ghi giờ"]
    memo --> sp["Dừng ngay"]
    wt -.-> ow["Gói cũ hơn bị ghi đè"]
    ow -.-> late["Dừng muộn xóa khoảng bạn quan tâm"]

Hình 15: Bộ đệm vòng xóa quá khứ càng để lâu, nên đã ghi giờ thì dừng ngay.

8. Vấn đề TLS che phần tải — bạn vẫn thấy gì

Hầu hết lưu lượng nghiệp vụ hôm nay là TLS (HTTPS). Người ta dễ nghĩ “mã hóa rồi thì bắt vô ích”, nhưng hầu hết điều bạn muốn khi điều tra timeout vẫn thấy được khi để nguyên mã hóa.

• Kết nối TCP đã lập chưa (bắt tay ba chiều)
• Bắt tay TLS đi được bao xa — ServerHello có về ClientHello không, có bị cắt bằng RST hoặc cảnh báo giữa chừng không
• Tên máy đích trên ClientHello (SNI), và phiên bản TLS đã thương lượng
• Sau khi kết nối lên, bên nào ngừng gửi. Vị trí im lặng, truyền lại, RST, hoặc đóng sạch (FIN)

Nói cách khác, cô lập “không kết nối được”, “đứt giữa chừng” và “không có trả lời về” hầu như không cần giải mã phần tải. Mã hóa mất “họ nói gì”; “ai im, và khi nào” vẫn còn.

flowchart TB
    accTitle: Lần bắt TLS cho thấy và không cho thấy gì
    accDescr: Mã hóa chỉ che phần tải dữ liệu ứng dụng; lập kết nối TCP, thành hay thất bắt tay TLS, SNI và phiên bản TLS, RST, và bên nào im vẫn thấy được khi để nguyên mã hóa
    tls["Bắt lưu lượng TLS"] --> vis["Thấy được"]
    tls --> hid["Không thấy"]
    vis --> v1["Lập kết nối TCP"]
    vis --> v2["Kết quả TLS và SNI"]
    vis --> v3["RST / ai im"]
    hid --> h1["Phần tải dữ liệu ứng dụng"]

Hình 16: Mã hóa chỉ mất phần tải; khung xương cuộc hội thoại vẫn đọc được khi để nguyên TLS.

Khi vẫn cần phần tải, Wireshark có thể giải mã TLS bằng khóa phiên ghi ra qua biến môi trường SSLKEYLOGFILE. Hỗ trợ giới hạn ở một số triển khai như Firefox, Chrome, Edge dựa trên Chromium và thư viện họ OpenSSL; SChannel sẵn có của Windows (ứng dụng dùng WinHTTP hoặc WinINET) không hỗ trợ cơ chế này.¹⁰ Vì “khóa phiên được ghi ra tệp” nghĩa là ai có tệp đó đều giải mã được cả cuộc hội thoại, đây không phải kỹ thuật sản xuất; hãy coi là tái hiện và gỡ lỗi trong môi trường phát triển.

flowchart TB
    accTitle: Cách giải mã SSLKEYLOGFILE hoạt động và giới hạn
    accDescr: Khóa phiên ghi qua SSLKEYLOGFILE cho phép Wireshark giải mã TLS, nhưng chỉ một số triển khai như Firefox và họ Chrome hỗ trợ còn SChannel thì không; ai có tệp khóa đều giải mã được cuộc hội thoại, nên coi là kỹ thuật chỉ dành cho môi trường phát triển
    env["Đặt SSLKEYLOGFILE"] --> key["Ghi khóa phiên"]
    key --> ws["Đọc trong Wireshark"]
    key -.-> risk["Người giữ khóa có thể giải mã"]
    risk -.-> dev["Chỉ phát triển"]
    env -.-> sup["Chỉ một số ngăn xếp TLS"]
    sup -.-> sch["SChannel: không hỗ trợ"]

Hình 17: Ghi khóa phiên có thể giải mã, nhưng triển khai được hỗ trợ có hạn, và bản chất khóa khiến đây là kỹ thuật chỉ dành cho môi trường phát triển.

Khi lưu lượng đi qua proxy nội bộ, đích hiện trong lần bắt là máy chủ proxy, và TLS chảy trong đường hầm CONNECT. Câu hỏi trước là ứng dụng đang hướng tới proxy nào được sắp trong bài cùng ngày “Proxy doanh nghiệp và ứng dụng Windows — sắp xếp cách phân giải proxy trong WinINET, WinHTTP và .NET”.

9. Đối chiếu với nhật ký ứng dụng — đặt thời gian trên cùng một trục

Một mình lần bắt hiếm khi ra kết luận. Bước quyết định trong thực tế là đặt một dòng nhật ký ứng dụng và một vòng gói trên cùng một trục thời gian.

Quy trình như sau.

1. Xác định giờ sự cố từ nhật ký ứng dụng (ví dụ, ngoại lệ timeout lúc 10:23:41). Nếu giá trị timeout là 30 giây, lúc bắt đầu phải khoảng 10:23:11.
2. Chuyển hiển thị giờ Wireshark sang [View] → [Time Display Format] → [Date and Time of Day], và thu hẹp khoảng bằng bộ lọc hiển thị (cũng lọc theo giờ được, như frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").
3. Trong khoảng đó, xác nhận thứ tự Chương 5 (bắt tay → RST → truyền lại → ZeroWindow). Nếu xếp được tới “30 giây trước giờ timeout của nhật ký, một SYN được gửi, sau đó chỉ còn truyền lại SYN”, chữ “timeout” của nhật ký được thay bằng quan sát “tại điểm bắt này, không có trả lời nào về cả” (SYN không tới phía kia, hay SYN/ACK về bị mất trên đường về, không chốt được từ một mình điểm bắt này. Nếu cần chốt, bắt trên máy chủ rồi xếp).
4. Luôn hiệu chỉnh lệch giữa giờ bắt và giờ nhật ký (lệch đồng hồ đo ở Mục 7.1, và ký hiệu múi giờ của nhật ký). Vài giây lệch đối chiếu sẽ đóng đinh nhầm cuộc hội thoại thành thủ phạm.

flowchart TB
    accTitle: Quy trình xếp nhật ký ứng dụng và các gói
    accDescr: Xác định giờ sự cố từ nhật ký ứng dụng, tính ngược giờ bắt đầu từ giá trị timeout, thu hẹp khoảng trong Wireshark bằng bộ lọc hiển thị, xác nhận các hình theo thứ tự, hiệu chỉnh lệch đồng hồ, và đặt trên cùng một trục thời gian
    lg["1. Xác định giờ sự cố từ nhật ký"] --> rev["Tính ngược lúc bắt đầu từ giá trị timeout"]
    rev --> flt["2. Thu hẹp khoảng bằng bộ lọc hiển thị"]
    flt --> chk["3. Xác nhận các hình theo thứ tự Chương 5"]
    chk --> adj["4. Hiệu chỉnh lệch đồng hồ"]
    adj --> done["Một chữ của nhật ký thành quan sát"]

Hình 18: Thu hẹp khoảng từ giờ nhật ký, xác nhận hình, hiệu chỉnh lệch đồng hồ, và đặt trên cùng một trục.

Khi bàn giao kết quả điều tra cho bên thứ ba (nhà cung cấp, nhà mạng, nhân sự mạng của khách), cắt nhiễu bằng bộ lọc trước khi bàn giao vừa lịch sự vừa là biện pháp an toàn. Trong Wireshark, thu hẹp cuộc hội thoại quan tâm bằng bộ lọc hiển thị và lưu “chỉ các gói đang hiện” bằng [File] → [Export Specified Packets], bạn được một pcapng nhỏ đúng phạm vi cần.

Cuối cùng, lưu ý xử lý. Tệp bắt chứa chính cuộc giao tiếp. Nó có thể gồm thông tin đăng nhập giao thức rõ, cookie HTTP và khóa API, nội dung thư hoặc báo cáo, và thông tin cá nhân. Quyết định ba điểm sau như một bộ với quy trình bắt.

• Bắt tối thiểu cần thiết: Thu hẹp mục tiêu bằng bộ lọc trước khi bắt (Chương 3 và 4) và giữ cửa sổ thời gian càng ngắn càng tốt. Đừng “bắt hết cho chắc” trên môi trường khách
• Thu hẹp trước khi bàn giao: Chỉ xuất cuộc hội thoại quan tâm; đừng kèm lưu lượng bên thứ ba không liên quan. Nếu còn phần nhạy cảm, thống nhất với bên nhận việc che hoặc cách khác
• Lưu giữ và xóa: Quyết định tệp bắt để đâu, bao lâu, và khi nào xóa, rồi xóa khi điều tra xong

flowchart TB
    accTitle: Ba quyết định trước khi bàn giao tệp bắt
    accDescr: Lần bắt chứa chính cuộc giao tiếp, nên quyết định như một bộ với quy trình bắt rằng bạn sẽ thu hẹp tối thiểu bằng bộ lọc trước khi bắt và cửa sổ thời gian, trích chỉ cuộc hội thoại quan tâm trước bàn giao để không kèm lưu lượng không liên quan, và quyết định nơi lưu cùng thời hạn rồi xóa sau điều tra
    cap["Bắt = lưu lượng"] --> p1["Bắt tối thiểu"]
    cap --> p2["Trích mục tiêu trước"]
    cap --> p3["Đặt lưu giữ, xóa"]
    p2 -.-> exp["Lọc và xuất"]

Hình 19: Quyết định bắt tối thiểu, thu hẹp trước bàn giao, cùng lưu giữ và xóa như một bộ với quy trình bắt.

10. Tóm tắt

• Một tầng dưới “timeout” của nhật ký ứng dụng là sự thật các gói thực sự đi trên dây. SYN không được trả lời, RST cắt, truyền lại tiếp diễn, hay ZeroWindow xuất hiện sẽ đổi chỗ bạn nhìn tiếp.
• Ngay cả hiện trường không cài được Wireshark, bạn vẫn bắt bằng pktmon và netsh trace sẵn có của Windows. Bắt bằng công cụ sẵn có, đọc bằng Wireshark trên máy mình — cách chia đó là dạng cơ bản.
• pktmon bốn bước: đăng ký bộ lọc → pktmon start --capture → pktmon stop → pktmon etl2pcap. Mặc định bị cắt 128 byte, nên nếu muốn phần tải đừng quên --pkt-size 0. Thấy vị trí và lý do drop là thế mạnh chỉ pktmon có.
• netsh trace bắt một nhóm nhà cung cấp ETW như kịch bản, và với persistent=yes có thể sống sót qua khởi động lại. Chuyển ETL sang pcapng bằng etl2pcapng để đọc.
• Trong Wireshark, bắt đầu từ tcp.analysis.flags và tìm bắt tay, RST, truyền lại, ZeroWindow theo thứ tự đó. Nhanh hơn nếu lấy bức tranh bằng Conversations và I/O Graph trước, rồi thu hẹp.
• Lưu lượng tới localhost không đi qua NIC, nên không bắt được theo cách thông thường. Dùng bộ điều hợp loopback Npcap hoặc bắt trong ngăn xếp của pktmon.
• Bắt cả hai phía và xếp chúng, “bên nào im” được chốt. Tiền đề là đồng bộ đồng hồ (w32tm). Với sự cố không biết điều kiện tái hiện, chờ bằng bộ đệm vòng.
• Ngay cả dưới TLS, khung xương cuộc hội thoại vẫn thấy. Coi giải mã (SSLKEYLOGFILE) là kỹ thuật chỉ dành cho môi trường phát triển, và coi chính tệp bắt là mật: đưa bắt tối thiểu, thu hẹp và xóa vào vận hành.

Bắt gói thường bị nghĩ là “công cụ của chuyên gia mạng”, nhưng trong thực tế nó là công cụ điều tra phía ứng dụng chỉ bắt đầu có nghĩa khi bạn xếp nó với nhật ký ứng dụng. Lần sau điều tra dừng ở một chữ “timeout”, hãy đi nhìn một tầng xuống.

Bài viết liên quan

• Vì sao truyền lại TCP làm khựng giao tiếp camera công nghiệp, và cách cô lập
• Hiểu lầm rằng TCP cho phép nhận đúng đơn vị bạn gửi — thiết kế nhận quanh luồng byte
• Cảm nhận thật mô hình OSI — mổ một yêu cầu HTTP thành bảy tầng
• Hướng dẫn thực tế Process Monitor (ProcMon) — xác định “cài đặt không áp dụng” và “ACCESS DENIED” trong 10 phút
• Tường lửa Windows và ứng dụng nghiệp vụ — đăng ký quy tắc vào từ bộ cài
• Proxy doanh nghiệp và ứng dụng Windows — sắp xếp cách phân giải proxy trong WinINET, WinHTTP và .NET

Lĩnh vực tư vấn liên quan

KomuraSoft LLC nhận điều tra lỗi có nguồn gốc giao tiếp như “giao tiếp ứng dụng nghiệp vụ thỉnh thoảng thất bại mà không tìm được nguyên nhân” và “muốn cô lập lỗi kết nối chỉ xảy ra trên môi trường khách”. Chúng tôi lấy thiết kế lần bắt (bắt ở đâu, cái gì, bao nhiêu), phân tích Wireshark, đối chiếu nhật ký ứng dụng, và sửa phía ứng dụng như một công việc liền mạch.

• Phát triển ứng dụng Windows
• Điều tra lỗi và phân tích nguyên nhân gốc rễ
• Tư vấn kỹ thuật và rà soát thiết kế
• Liên hệ với chúng tôi

Liên kết tham khảo

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Dịch vụ liên quan đến chủ đề này

Bài viết liên quan trực tiếp đến các dịch vụ sau.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Làm sao bắt gói tin trên máy chủ khách hàng không được cài Wireshark?

Dùng công cụ sẵn có của Windows là pktmon hoặc netsh trace, bạn bắt được mà không cần cài thêm phần mềm. Với pktmon, đăng ký bộ lọc trong terminal nâng quyền, bắt đầu bằng pktmon start --capture rồi dừng bằng pktmon stop. File ETL thu được chuyển sang pcapng bằng pktmon etl2pcap, nên phân tích mang về Wireshark trên máy của bạn. "Bắt bằng công cụ sẵn có, đọc bằng Wireshark" là cách chia việc cơ bản trên các hiện trường hạn chế cài đặt.

Nên dùng pktmon hay netsh trace?

Nếu hệ điều hành có pktmon (Windows 10 / Windows Server 2019 trở lên), hãy bắt đầu bằng pktmon. Lệnh đơn giản, bạn thấy thành phần nào của ngăn xếp mạng đã loại gói (lý do drop), và chuyển pcapng tự đủ. netsh trace phù hợp hơn khi bắt trên hệ điều hành cũ không có pktmon, khi muốn thu sự kiện ETW của thành phần Windows theo kịch bản, hoặc khi muốn lần bắt sống sót qua khởi động lại với persistent=yes. Tài liệu xử lý sự cố của Microsoft cũng chỉ thứ tự này: pktmon trước, rồi netsh trace nếu chưa đủ.

Vì sao lưu lượng tới localhost (127.0.0.1) không hiện trên Wireshark?

Lưu lượng tới localhost không bao giờ đi qua NIC vật lý; nó được quay vòng trên đường loopback nội bộ của hệ điều hành. Lần bắt thông thường nhắm card vật lý vì thế không bao giờ thấy. Trong Wireshark, chọn "Adapter for loopback traffic capture" của Npcap là bắt được lưu lượng loopback. pktmon bắt bên trong ngăn xếp mạng nên cũng quan sát được loopback. Nhầm lẫn phổ biến khác: "localhost" phân giải thành IPv6 ::1, nên màn hình bạn đang nhìn 127.0.0.1 trống trơn — hãy xác nhận bằng cách chỉ định địa chỉ tường minh.

Có xem được nội dung lưu lượng HTTPS (TLS) trong lần bắt gói không?

Phần tải dữ liệu ứng dụng đã mã hóa và không nhìn thấy. "Khung xương" cuộc hội thoại — kết nối và ngắt TCP, bắt tay TLS thành hay thất, cắt RST, bên nào ngừng trả lời — vẫn thấy được dù đã mã hóa, nên hầu hết điều tra timeout tiến hành với TLS để nguyên. Nếu cần phần tải, có giải mã qua SSLKEYLOGFILE, nhưng chỉ một số triển khai TLS như Firefox và họ Chrome hỗ trợ; SChannel sẵn có của Windows không hỗ trợ. Cơ chế ghi ra vật liệu khóa bí mật, hãy coi là tùy chọn chỉ dành cho môi trường phát triển.

Gửi file bắt gói cho bộ phận hỗ trợ bên ngoài có an toàn không?

Gửi nguyên trạng thì nguy hiểm. Lần bắt chứa chính cuộc giao tiếp và có thể gồm thông tin đăng nhập của giao thức rõ, cookie, khóa API và thông tin cá nhân. Trước hết, lúc bắt, thu hẹp bộ lọc và cửa sổ thời gian xuống mức tối thiểu cần thiết, rồi trước khi bàn giao hãy trích chỉ cuộc hội thoại mục tiêu bằng bộ lọc hiển thị Wireshark và xuất ra. Với phần nhạy cảm còn lại, thống nhất với bên nhận cách xử lý (che, hoặc giao bằng cách khác) trước khi gửi. Quyết định trước file bắt được giữ bao lâu và khi nào xóa.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.