Penangkapan paket di Windows secara praktis — memilih antara pktmon, netsh trace, dan Wireshark

“Komunikasi server aplikasi bisnis gagal beberapa kali sebulan. Log aplikasi hanya menulis ‘timeout’. Tidak ada galat yang cocok di log sisi server pada waktu itu. Kami tidak tahu cara mereproduksinya” — dalam konsultasi penyelidikan bug, bentuk ini muncul terus-menerus.

Log aplikasi hanya menyimpan apa yang aplikasi “memutuskan untuk ditulis”. Anda melihat hasilnya timeout, tetapi apakah permintaan sambungan (SYN) tidak mendapat balasan, apakah sambungan terbentuk lalu server diam, apakah diputus dengan RST, atau apakah paket sampai ke tujuan, hidup satu lapis di bawah log — di paket yang benar-benar lewat di kabel. Jika Process Monitor adalah cara melihat satu lapis ke bawah akses berkas dan registri, penangkapan paket adalah cara melihat satu lapis ke bawah percakapan.

flowchart TB
    accTitle: Paket satu lapis di bawah log aplikasi
    accDescr: Log aplikasi hanya menyimpan apa yang aplikasi memutuskan untuk ditulis; apakah SYN tanpa balasan, rekan diam setelah sambung, RST memutus, atau paket sampai hanya hidup di paket yang benar-benar lewat di kabel
    log["Log aplikasi"] --> dec["Hanya yang diputuskan untuk ditulis yang tersisa"]
    dec --> to["Hasilnya timeout satu kata"]
    to -->|lihat satu lapis ke bawah| pkt["Paket yang benar-benar lewat di kabel"]
    pkt --> q1["Tidak ada balasan ke SYN?"]
    pkt --> q2["Diam setelah sambung?"]
    pkt --> q3["Diputus dengan RST?"]
    pkt --> q4["Apakah sampai ke tujuan?"]

Gambar 1: Log hanya menyimpan hasil; rincian timeout hanya hidup di paket satu lapis di bawah.

Tempat orang biasanya macet adalah batasan “kami tidak bisa memasang Wireshark di server pelanggan”. Situs yang pengendalian perubahannya atau kebijakan keamanannya tidak menyetujui perangkat lunak tambahan untuk penyelidikan tidak jarang. Namun Windows sudah mengirimkan dua alat penangkapan paket: pktmon dan netsh trace. Tangkap dengan alat OS bawaan, bawa berkas hasil ke PC sendiri, dan baca di Wireshark — dengan pembagian itu, paket tetap terlihat di situs yang melarang pemasangan.

Artikel ini ditujukan kepada staf TI perusahaan kecil dan menengah serta pengembang aplikasi Windows. Ia merapikan cara memilih di antara pktmon, netsh trace, dan Wireshark, serta prosedur praktis masing-masing. Jebakan lalu lintas loopback, memutuskan menangkap di klien atau server, cara hidup dengan TLS yang menyembunyikan muatan, dan mengkorelasikan penangkapan dengan log aplikasi semuanya dibahas dari sumber primer per Agustus 2026.

1. Kesimpulan dulu

• “Tangkap dengan alat bawaan, baca dengan Wireshark” adalah pembagian dasar di lapangan. Meski Anda tidak bisa memasang perangkat lunak di server pelanggan, pktmon dan netsh trace sudah ada di Windows. Ubah log yang ditangkap ke pcapng dan analisis di Wireshark di mesin sendiri.¹²
• pktmon adalah alat penangkapan paket bawaan Windows 10 / Windows Server 2019 dan yang lebih baru. Dipakai dalam empat langkah — daftarkan filter, mulai, hentikan, konversi — dan kekuatannya yang khas adalah melihat komponen tumpukan jaringan mana yang membuang paket (alasan drop).³⁴
• netsh trace adalah alat bawaan yang lebih tua; ia dapat mengaktifkan sekelompok penyedia ETW sebagai “skenario”. Selain paket ia menyimpan peristiwa dari dalam komponen Windows, dan dengan persistent=yes penangkapan dapat bertahan melewati boot ulang.⁵⁶
• Kedua alat menulis ETL, yang Wireshark tidak bisa buka apa adanya. Ubah ke pcapng dengan pktmon etl2pcap untuk pktmon, dan dengan etl2pcapng sumber terbuka Microsoft untuk netsh trace.¹²
• Microsoft sendiri menunjuk “pktmon dulu, lalu netsh trace jika itu belum cukup, dan Wireshark untuk analisis protokol”. Pembagian artikel ini mengikuti rekomendasi resmi itu.⁷
• Secara bawaan pktmon hanya merekam 128 bita pertama setiap paket. Jika Anda bermaksud membaca muatan di Wireshark, jangan lupa --pkt-size 0 (rekam seluruh paket) saat memulai.⁸
• Lalu lintas ke localhost tidak muncul dalam penangkapan biasa. Ia tidak pernah melewati NIC. Gunakan adaptor loopback Npcap di Wireshark, atau penangkapan dalam tumpukan pktmon dengan alat bawaan.⁹
• Meski TLS menyembunyikan muatan, Anda masih bisa belajar banyak. Pembentukan sambungan, apakah jabat tangan TLS berhasil, RST, dan sisi mana yang diam tetap terlihat meski terenkripsi. Dekripsi lewat SSLKEYLOGFILE adalah teknik hanya untuk lingkungan pengembangan.¹⁰
• Penangkapan berisi komunikasi itu sendiri. Anggap ia bisa mencakup kredensial dan data pribadi, dan masukkan penangkapan seminimal mungkin serta penyempitan sebelum serah ke dalam prosedur.

2. Tiga alat penangkapan dan cara memilih

Pertama, satu tabel peran ketiga alat.

Dalam satu kalimat, pktmon dan netsh trace adalah alat “menangkap”, dan Wireshark adalah alat “membaca”. Wireshark juga bisa menangkap, tetapi Anda tidak bisa memakainya di tempat yang tidak boleh dipasang. Sebaliknya, ETL alat bawaan bisa diubah ke teks dan dibaca, tetapi menatapnya tanpa filter tampilan dan analisis TCP adalah siksaan. “Tangkap di lapangan dengan alat bawaan, ubah ke pcapng, dan baca di Wireshark di mesin sendiri” adalah jalur terpendek di situs yang terbatas.

flowchart TB
    accTitle: Tangkap dengan alat bawaan, baca dengan Wireshark
    accDescr: Di lapangan Anda menangkap ETL dengan pktmon atau netsh trace, mengubah masing-masing ke pcapng dengan alat konversinya, lalu menganalisis di Wireshark di mesin sendiri
    pk["pktmon (bawaan)"] --> etla["Berkas ETL"]
    ns["netsh trace (bawaan)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["Analisis di Wireshark di mesin sendiri"]

Gambar 2: Di lapangan Anda menangkap ETL dengan alat bawaan, mengubah ke pcapng, dan membacanya di Wireshark di mesin sendiri.

Panduan investigasi kehilangan paket Microsoft berbentuk sama: tangkap dan isolasi penyebab dengan pktmon dulu, lalu pindah ke jejak tingkat komponen seperti netsh trace start scenario=InternetClient jika itu belum cukup, dan analisis perilaku protokol di Wireshark.⁷

Sebagai prasyarat untuk membaca apa yang sebenarnya ditunjukkan paket, membantu juga punya gambaran lapisan yang ditumpuk — Ethernet, IP, TCP, data aplikasi. Anatomi lapisan diilustrasikan di “Merasakan model OSI secara nyata”.

3. pktmon secara praktis — Filter, mulai, hentikan, konversi

Alur dasar pktmon ada empat langkah. Jalankan di terminal yang ditingkatkan.

:: 1. Daftarkan filter dulu untuk mempersempit sasaran (TCP 8443 di server 192.168.10.20)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. Mulai penangkapan. Rekam paket utuh, timpa dalam cincin 1GB
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Reproduksi insiden. Sambil menunggu, volume dan drop bisa dicek dengan counters
pktmon counters --drop-reason

:: 4. Hentikan, lalu konversi ke pcapng untuk Wireshark
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. Bersihkan filter terdaftar (filter tetap ada sampai dihapus secara eksplisit).
::    Catatan: filter remove tidak menerima nama; perintah ini menghapus «semua» filter terdaftar.
::    Di mesin yang mungkin masih punya filter penyelidikan lain, periksa dulu dengan pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: Prosedur dasar pktmon
    accDescr: Persempit sasaran dengan filter, mulai penangkapan, reproduksi insiden, hentikan, ubah ke pcapng dengan etl2pcap, dan terakhir hapus filter yang terdaftar
    fa["1. Persempit sasaran dengan filter add"] --> st["2. Mulai penangkapan dengan start --capture"]
    st --> re["3. Reproduksi insiden"]
    re -.-> ct["Cek volume dan drop dengan counters"]
    re --> sp["4. Hentikan"]
    sp --> cv["Ubah ke pcapng dengan etl2pcap"]
    cv --> rm["5. Bersihkan dengan filter remove"]

Gambar 3: pktmon dimulai dengan pendaftaran filter, lalu penangkapan, berhenti, dan konversi, dan Anda menghapus filter secara eksplisit di akhir.

Hal yang perlu diingat:

• Daftarkan filter sebelum memulai penangkapan. Dokumentasi Microsoft juga sangat menganjurkan menerapkan filter sebelum mulai, karena menangkap semua lalu lintas terlalu berisik. Filter bisa menyebutkan alamat IP, porta, alamat MAC, protokol, ID VLAN, dan seterusnya, dan Anda bisa mendaftarkan hingga 32. Beberapa filter adalah OR: paket dicatat jika cocok dengan salah satunya.³
• Filter pktmon tidak membedakan sumber dan tujuan. -i 192.168.10.20 berarti supaya “paket di mana alamat ini adalah sumber atau tujuan”. Arah dipersempit nanti dengan filter tampilan Wireshark setelah konversi.³
• Ukuran paket bawaan adalah 128 bita. Cukup untuk analisis header, tetapi jika Anda juga ingin data aplikasi, rekam seluruh paket dengan --pkt-size 0.⁸
• Log secara bawaan dalam mode circular (penyangga cincin), ukuran bawaan 512MB. Anda bisa mengubah batas dengan --file-size, dan --log-mode real-time mencetak ke layar secara waktu nyata dan tidak membuat berkas log. Pastikan dulu dalam mode waktu nyata bahwa lalu lintas yang Anda pedulikan benar-benar terlihat, lalu atur penangkapan produksi, dan Anda menghindari pengambilan kosong.⁸

flowchart TB
    accTitle: Cara filter pktmon berlaku
    accDescr: Beberapa filter terdaftar merekam pada kecocokan OR, alamat yang disebutkan tidak membedakan sumber dan tujuan, dan arah dipersempit nanti dengan filter tampilan Wireshark setelah konversi
    f1["Filter 1"] --> orc["Rekam jika salah satu cocok"]
    f2["Filter 2"] --> orc
    f3["Filter 3 (hingga 32)"] --> orc
    orc --> rec["Tercatat di log penangkapan (OR)"]
    rec -.-> nodir["Sumber dan tujuan tidak dibedakan"]
    nodir -.-> ws["Persempit arah di Wireshark setelah konversi"]

Gambar 4: Beberapa filter bekerja sebagai OR, dan apakah host sumber atau tujuan dipersempit di Wireshark setelah konversi.

3.1. Yang hanya bisa dilakukan pktmon — melihat di mana paket dibuang

Nilai khas pktmon dibanding Wireshark adalah ia menangkap paket di beberapa titik di dalam tumpukan jaringan, bukan di satu NIC, dan bisa melaporkan di mana dan mengapa paket dibuang (dropped). Karena Anda melihat komponen mana yang dicapai paket dan di mana ia hilang, alasan drop seperti “ketidakcocokan MTU” atau “filter VLAN” membawa ke penyebab tanpa pencarian membabi buta.⁴

flowchart TB
    accTitle: pktmon menangkap di beberapa titik di dalam tumpukan
    accDescr: pktmon menangkap paket di beberapa titik di dalam tumpukan jaringan, bukan di satu NIC, sehingga bisa melaporkan dengan alasan komponen mana yang dicapai paket dan di mana ia dibuang
    pin["Paket"] --> p1["Ditangkap di titik 1"]
    p1 --> p2["Ditangkap di titik 2"]
    p2 --> p3["Dibuang di titik 3"]
    p3 -.-> rz["Melaporkan lokasi dan alasan drop"]
    rz -.-> ex["mis. ketidakcocokan MTU atau filter VLAN"]

Gambar 5: Menangkap di beberapa titik di dalam tumpukan memberi tahu seberapa jauh paket sampai dan di mana ia di-drop, beserta alasannya.

• pktmon list menampilkan komponen jaringan yang bisa dipantau (NIC, tumpukan protokol, driver filter, dan seterusnya) beserta ID-nya.
• pktmon counters --drop-reason mencantumkan penghitung lolos/drop per komponen dan alasan drop terbaru. Nyaman sebagai potongan pertama sebelum menganalisis log.¹¹
• Ubah ke teks dengan pktmon etl2txt dan paket yang dibuang dikeluarkan dengan drop dan dropReason.³

Dugaan bahwa “sesuatu di OS membuang ini sebelum sampai ke aplikasi” tidak bisa diselesaikan hanya dengan menatap Wireshark. Kemampuan ini membantu, misalnya, saat mengisolasi kasus firewall yang membuang karena aturan masuk hilang (“Firewall Windows dan aplikasi bisnis”).

Satu peringatan. pktmon merekam paket yang sama di beberapa titik tumpukan, jadi mengonversi apa adanya ke pcapng bisa membuat paket yang sama muncul lebih dari sekali. pcapng tidak membawa “komponen mana yang menangkap ini”, jadi jika Anda membaca di Wireshark langkah standarnya adalah mengonversi dengan --component-id untuk memilih satu titik (atau menaruh drop saja di berkas terpisah dengan --drop-only).¹

flowchart TB
    accTitle: Mengapa paket yang sama bisa muncul dua kali setelah konversi pcapng
    accDescr: pktmon merekam paket yang sama di beberapa titik tumpukan, pcapng tidak menyimpan komponen mana yang menangkap sehingga duplikat bisa muncul, dan langkah standar adalah mengonversi setelah mempersempit titik dengan component-id atau menaruh drop saja di berkas drop-only
    same["Paket yang sama direkam di beberapa titik"] --> conv["Ubah ke pcapng apa adanya"]
    conv --> lost["Informasi titik penangkapan tidak terbawa"]
    lost --> dup["Paket yang sama muncul lebih dari sekali"]
    dup --> c1["Persempit titik dengan --component-id"]
    dup --> c2["Berkas terpisah dengan --drop-only"]

Gambar 6: Informasi titik penangkapan tidak terbawa ke pcapng, jadi langkah standar adalah mempersempit titik sebelum mengonversi.

4. netsh trace secara praktis — Skenario, ETL, dan penangkapan yang bertahan melewati boot ulang

netsh trace adalah mekanisme pelacakan yang sudah ada di Windows lebih lama daripada pktmon. Cirinya: sebagai “skenario” ia dapat mengaktifkan sekaligus seluruh kumpulan penyedia ETW yang terkait masalah itu.⁶

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

• Tambahkan capture=yes untuk mengaktifkan penangkapan paket, dan persempit sasaran dengan filter penangkapan seperti ipv4.address=192.168.10.20. Daftar filter ada di netsh trace show capturefilterHelp.⁶
• Menghentikan menghasilkan berkas .cab selain ETL. .cab menyimpan informasi sistem seperti konfigurasi adaptor dan build OS, jadi ia merangkap pengumpulan lingkungan.⁶
• Hanya satu sesi jejak yang bisa berjalan sekaligus. Sebelum memulai penangkapan lain, periksa dengan netsh trace show status bahwa tidak ada sesi sisa yang masih berjalan.⁶
• Tambahkan persistent=yes dan sesi bertahan melewati boot ulang. Menangkap “komunikasi gagal sejenak tepat setelah boot ulang” atau “sambungan layanan saat mulai gagal” — insiden yang tidak sempat Anda mulai dengan tangan — adalah wilayah unik netsh trace.⁵

flowchart TB
    accTitle: Menangkap skenario netsh trace
    accDescr: Memulai dengan skenario mengaktifkan sekelompok penyedia ETW, capture=yes juga menangkap paket, dan menghentikan menghasilkan berkas ETL serta berkas .cab
    sc["Mulai dengan skenario"] --> pv["Aktifkan kumpulan penyedia"]
    sc -->|capture=yes| pc["Paket juga ditangkap"]
    pv --> re["Reproduksi insiden"]
    pc --> re
    re --> sp["Hentikan"]
    sp --> etl["Berkas ETL"]
    sp --> cab[".cab (informasi sistem)"]

Gambar 7: Memulai dengan skenario mengaktifkan sekelompok penyedia, dan menghentikan menghasilkan ETL serta .cab.

4.1. Membuat ETL dapat dibaca di Wireshark — etl2pcapng

ETL netsh trace tidak bisa dibuka apa adanya di Wireshark. etl2pcapng, alat sumber terbuka yang Microsoft terbitkan di GitHub, mengubah paket di dalam ETL yang ditangkap dengan netsh trace start capture=yes ke pcapng.²

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

Saat konversi, etl2pcapng menulis ID proses yang terlibat dengan setiap paket sebagai komentar paket. Bisa melihat “lalu lintas proses mana ini” di Wireshark membantu ketika beberapa aplikasi di server yang sama sedang berbicara.²

Sisi peristiwa ETW (peristiwa internal Windows yang dicatat penyedia skenario) tidak dikonversi ke pcapng. Jika Anda juga ingin peristiwa, ubah ke teks atau sejenisnya dengan netsh trace convert input=C:\temp\nettrace.etl, atau buka ETL di Windows Performance Analyzer.⁵⁷

flowchart TB
    accTitle: Membaca ETL netsh trace terbagi dua jalur
    accDescr: Paket di dalam ETL diubah ke pcapng dengan etl2pcapng dan dibaca di Wireshark; peristiwa ETW tidak diubah ke pcapng, jadi Anda membacanya dengan netsh trace convert atau Windows Performance Analyzer
    etl["ETL netsh trace"] --> pk["Paket"]
    etl --> ev["Peristiwa ETW"]
    pk -->|etl2pcapng| pc["Ubah ke pcapng"]
    pc --> ws["Baca di Wireshark"]
    pc -.-> pid["ID proses tetap sebagai komentar"]
    ev -.-> no["Tidak diubah ke pcapng"]
    no --> alt["Baca dengan convert atau WPA"]

Gambar 8: Dari ETL, paket diubah ke pcapng untuk dibaca; peristiwa ETW dibaca dengan cara lain.

5. Pandangan pertama membaca di Wireshark — Filter tampilan dan analisis TCP

Setelah membuka pcapng, potong dulu kebisingan dengan filter tampilan. Yang umum ada di tabel.¹²¹³

tcp.analysis.* adalah bendera analisis yang Wireshark berikan dengan mengikuti nomor urutan TCP. Transmisi ulang, ACK duplikat, di luar urutan, ZeroWindow, dan sejenisnya dipetik secara mekanis, jadi cara standar mulai membaca adalah mengetik tcp.analysis.flags dulu dan mencantumkan tempat yang “terlihat seperti masalah”.¹³

Dalam penyelidikan timeout, cari bentuk berikut berurutan.

1. Apakah jabat tangan tiga arah selesai? Apakah ketiga paket SYN → SYN/ACK → ACK semuanya ada? Jika SYN diulang tanpa balasan, ia tidak pernah sampai ke rekan, atau dibuang diam-diam di tengah (pola firewall yang khas).
2. Sisi mana yang mengirim RST? RST segera ke SYN berarti tidak ada yang mendengarkan di porta tujuan; RST setelah sambungan terbentuk berarti satu sisi memaksa sambungan turun. IP sumber RST adalah bukti langsung “siapa yang memutus”.
3. Apakah transmisi ulang berlanjut? Transmisi ulang berulang segmen yang sama adalah tanda bahwa pengakuan (ACK) tidak kembali ke pengirim. Apakah data keluar hilang atau ACK yang kembali hilang tidak bisa diputus dari penangkapan satu sisi (itulah sebabnya “tangkap di kedua sisi” di bab berikutnya penting). Transmisi ulang dan timeout dibahas lebih dalam di “Mengapa transmisi ulang TCP menghentikan komunikasi kamera industri”.
4. Apakah ZeroWindow ada? Itu tanda aplikasi penerima tidak membaca dari soket dan penyangga terima penuh. Itu alasan untuk mencurigai rancangan aplikasi penerima (“Kesalahpahaman bahwa TCP membiarkan Anda menerima dalam satuan yang sama dengan yang Anda kirim”) daripada jaringan.

flowchart TB
    accTitle: Urutan bentuk yang dicari dalam penyelidikan timeout
    accDescr: Konfirmasi selesainya jabat tangan tiga arah, ada tidaknya dan sumber RST, transmisi ulang yang berlanjut, lalu ZeroWindow, untuk menandai penyebab pertama kali
    hs{"Apakah SYN mendapat balasan?"} -->|tidak| ng["Tidak pernah sampai（Firewall khas）"]
    hs -->|ya| rs{"Ada RST?"}
    rs -->|ya| who["Sumber RST yang memutus"]
    rs -->|tidak| rt{"Transmisi ulang berlanjut?"}
    rt -->|ya| ack["ACK tidak kembali"]
    rt -->|tidak| zw{"Ada ZeroWindow?"}
    zw -->|ya| app["Penerima tidak membaca"]

Gambar 9: Mencari jabat tangan, RST, transmisi ulang, lalu ZeroWindow dalam urutan itu mempersempit ke mana melihat berikutnya.

Sebelum membaca paket satu per satu, membantu juga mengambil gambaran utuh dengan fitur statistik. [Statistics] → [Conversations] adalah daftar “pasangan IP / porta mana yang berbicara, dari kapan sampai kapan, seberapa banyak”, sehingga Anda bisa mengidentifikasi percakapan yang Anda pedulikan lalu memfilter hanya ke percakapan itu. [Statistics] → [I/O Graph] adalah grafik volume sepanjang waktu; bentuk seperti “dari waktu ini, satu arah diam” langsung menonjol. Klik kanan percakapan TCP yang diminati dan pilih [Follow] → [TCP Stream] dan Anda bisa membaca tukar-menukar sambungan itu sebagai teks biasa.

flowchart TB
    accTitle: Ambil gambaran dengan statistik, lalu persempit ke percakapan
    accDescr: Cantumkan percakapan mana yang berbicara kapan dan seberapa banyak di Conversations, ambil interval diam dari I/O Graph, filter ke percakapan yang diminati, dan baca sebagai aliran TCP
    ov["Ambil gambaran utuh dengan statistik"] --> cv["Daftar percakapan di Conversations"]
    ov --> io["Lihat volume di I/O Graph"]
    cv --> flt["Filter ke percakapan yang diminati"]
    io -.-> mute["Interval diam menjadi terlihat"]
    flt --> fs["Baca sebagai aliran TCP"]

Gambar 10: Sebelum membaca paket demi paket, ambil gambaran dengan statistik, persempit ke percakapan yang diminati, lalu baca sampai habis.

6. Jebakan loopback — lalu lintas ke localhost tidak pernah melewati NIC

Mencoba menyelidiki komunikasi antar aplikasi di PC yang sama — misalnya aplikasi bisnis yang menyambung ke layanan perantara di localhost:8080 — dan macet di “tidak ada yang muncul di Wireshark” adalah jebakan klasik.

Penyebabnya jelas. Lalu lintas ke localhost (127.0.0.1) tidak pernah melewati NIC fisik; ia diputar balik di jalur loopback internal OS. Penangkapan biasa yang menargetkan adaptor fisik karena itu tidak pernah melihatnya.⁹

flowchart TB
    accTitle: Mengapa lalu lintas ke localhost tidak muncul dalam penangkapan
    accDescr: Lalu lintas ke localhost tidak pernah melewati NIC fisik dan diputar balik di jalur loopback internal OS, jadi tidak pernah muncul dalam penangkapan biasa yang menargetkan adaptor fisik
    app["Aplikasi"] --> stack["Tumpukan jaringan"]
    stack -->|eksternal| nic["NIC fisik"]
    nic --> seen["Terlihat di penangkapan biasa"]
    stack -->|localhost| lo["Diputar balik di OS"]
    lo -.-> miss["Tidak di penangkapan biasa"]
    lo -.-> alt["Loopback Npcap atau pktmon"]

Gambar 11: Lalu lintas ke localhost diputar balik sebelum NIC, jadi penangkapan adaptor fisik tidak pernah melihatnya.

Ada dua cara mengatasinya.

• Saat menangkap di Wireshark: Pilih “Adapter for loopback traffic capture” Npcap sebagai sasaran penangkapan. Pemasang Windows Wireshark (3.0 dan yang lebih baru) menyertakan Npcap, jadi jika Wireshark sudah terpasang Anda bisa memakainya tanpa kerja tambahan.⁹
• Saat menangkap dengan alat bawaan: pktmon menangkap di beberapa titik di dalam tumpukan jaringan, bukan di luar NIC⁴, jadi ia juga bisa mengamati lalu lintas loopback. Agar yakin, sebelum mengatur tunggu-reproduksi produksi, konfirmasikan di mesin itu dengan tampilan waktu nyata pktmon start -c -m real-time bahwa lalu lintas loopback yang Anda pedulikan benar-benar terlihat.

Waspadai juga dua kebingungan.

• “localhost” bisa terselesaikan ke IPv6 ::1. Aplikasi menyambung ke IPv6 ::1, tetapi penyelidik hanya melihat 127.0.0.1 (IPv4) dan keliru menyimpulkan “tidak ada lalu lintas”. Rentangkan filter tampilan ke keduanya, seperti ip.addr == 127.0.0.1 || ipv6.addr == ::1, atau jadikan pengaturan tujuan aplikasi alamat eksplisit.⁹
• Lalu lintas ke IP nyata Anda sendiri juga tidak pernah ke kabel. Ketika PC yang sama menyambung dari 192.168.10.5 ke 192.168.10.5, tujuannya IP nyata tetapi OS tetap memutarnya di dalam. Ingat bahwa “saya menyebutkan IP nyata, jadi pasti lewat NIC” tidak dijamin.

flowchart TB
    accTitle: Kebingungan ketika localhost terselesaikan ke IPv6
    accDescr: localhost aplikasi bisa terselesaikan ke IPv6 ::1, dan jika penyelidik hanya melihat 127.0.0.1 mereka keliru menyimpulkan tidak ada lalu lintas, jadi rentangkan filter tampilan ke kedua alamat atau pastikan tujuan sebagai alamat eksplisit
    app["Aplikasi menyambung ke localhost"] --> v6["Sebenarnya terselesaikan ke ::1 (IPv6)"]
    look["Penyelidik hanya melihat 127.0.0.1"] --> none["Tidak ada yang muncul di layar"]
    v6 --> none
    none --> fix1["Rentangkan filter ke kedua alamat"]
    none --> fix2["Jadikan tujuan alamat eksplisit"]

Gambar 12: Waspadai kebingungan di mana localhost terselesaikan ke ::1 dan hanya melihat 127.0.0.1 membawa ke “tidak ada lalu lintas”.

7. Di mana menangkap — satu sisi, kedua sisi, dan sinkron jam

Nilai penangkapan diputuskan oleh “di mana Anda menangkap”. Aturan praktisnya sebagai berikut.

Penangkapan satu sisi hanya memberi tahu “fakta seperti terlihat dari posisi saya”. Transmisi ulang yang berlanjut di klien tidak membedakan apakah paket terkirim hilang di jalur, atau sampai ke server dan balasan hilang. Tangkap di kedua sisi dan sejajarkan, dan Anda bisa menyelesaikan “klien mengirim / server tidak pernah menerima” — sisi mana yang diam. Ketika Anda perlu menyelesaikan batas tanggung jawab (aplikasi, OS, perangkat jaringan, atau ujung lain), ada gunanya merancang penangkapan kedua sisi dari awal.

flowchart TB
    accTitle: Apa yang dikatakan penangkapan satu sisi dan dua sisi
    accDescr: Penangkapan satu sisi tidak bisa membedakan apakah paket keluar hilang atau balasan kembali hilang; menangkap di kedua sisi dan menyelaraskannya menyelesaikan sisi mana yang diam
    one["Tangkap di satu sisi"] --> fact["Fakta dari sisi Anda"]
    fact --> und["Keluar atau kembali?"]
    both["Tangkap di kedua sisi"] --> mt["Sejajarkan"]
    mt --> fix["Sisi mana yang diam"]
    mt -.-> pre["Perlu sinkron jam"]

Gambar 13: Satu sisi hanya menunjukkan fakta yang Anda lihat; menyelaraskan kedua sisi barulah yang menyelesaikan batas tanggung jawab.

7.1. Prasyarat korelasi adalah sinkron jam

Untuk menyelaraskan penangkapan dari kedua sisi, jam kedua mesin harus setuju. Sebelum memulai penangkapan, periksa dan catat offset jam.

:: 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 adalah perintah yang menampilkan offset waktu antara Anda dan komputer rekan, dan menjadi dasar koreksi seperti “jam server +0,8 detik” saat Anda menyelaraskan penangkapan.¹⁴ Di lingkungan dengan offset besar, memperbaiki sinkron waktu dulu lalu menangkap pada akhirnya lebih pendek.

flowchart TB
    accTitle: Prosedur memeriksa offset jam sebelum korelasi
    accDescr: Konfirmasi status sinkron waktu sendiri dengan w32tm, ukur dan catat offset terhadap server rekan dengan stripchart, gunakan offset itu sebagai dasar koreksi saat menyelaraskan, dan jika offset besar perbaiki sinkron dulu lalu tangkap
    st["Periksa status sinkron dengan query"] --> mc["Ukur offset dengan stripchart"]
    mc --> rc["Catat offset"]
    rc --> use["Dasar koreksi saat korelasi"]
    mc -.-> big["Jika offset besar, perbaiki sinkron dulu"]

Gambar 14: Ukur dan catat offset jam sebelum menangkap, dan gunakan sebagai dasar koreksi saat menyelaraskan penangkapan.

7.2. Untuk “kita tidak tahu kapan terjadi” — penyangga cincin

Untuk insiden yang syarat reproduksinya tidak diketahui, langkah dasar adalah membiarkan penyangga cincin berjalan dan menghentikannya saat insiden terjadi.

• pktmon: Bawaan adalah mode circular. Atur batas (MB) dengan --file-size; paket yang lebih lama ditimpa.⁸
• netsh trace: Sebutkan sebagai maxSize=1024 filemode=circular.⁵
• Wireshark: Di [Capture] → [Options] → [Output] Anda bisa mengonfigurasi “beberapa berkas + penyangga cincin”. Ia berputar menurut ukuran berkas atau waktu dan hanya menyimpan N berkas terbaru, jadi Anda bisa berjalan lama dengan batas pemakaian disk.¹⁵

Dalam setiap kasus, bagikan dengan orang di lapangan aturan bahwa saat insiden terjadi, “catat waktunya dulu, lalu” hentikan penangkapan. Penyangga cincin menghapus masa lalu semakin lama Anda menunggu, jadi jika jalur dari kejadian ke berhenti panjang, interval yang Anda pedulikan tertimpa.

flowchart TB
    accTitle: Menunggu dengan penangkapan penyangga cincin
    accDescr: Untuk insiden yang syarat reproduksinya tidak diketahui, biarkan penyangga cincin berjalan, dan saat insiden terjadi catat waktu dan hentikan segera; jika berhenti terlambat, paket yang lebih lama tertimpa dan interval yang Anda pedulikan hilang
    st["Mulai penangkapan penyangga cincin"] --> wt["Biarkan berjalan dan tunggu"]
    wt --> ev["Insiden terjadi"]
    ev --> memo["Catat waktu"]
    memo --> sp["Hentikan segera"]
    wt -.-> ow["Paket yang lebih lama tertimpa"]
    ow -.-> late["Berhenti terlambat menghapus interval yang Anda pedulikan"]

Gambar 15: Penyangga cincin menghapus masa lalu semakin lama Anda menunggu, jadi setelah mencatat waktu, hentikan segera.

8. Masalah TLS menyembunyikan muatan — apa yang masih bisa dilihat

Sebagian besar lalu lintas bisnis hari ini adalah TLS (HTTPS). Orang cenderung berpikir “kalau terenkripsi, menangkap tidak ada gunanya”, tetapi sebagian besar yang Anda inginkan dalam penyelidikan timeout tetap terlihat dengan enkripsi dibiarkan di tempat.

• Apakah sambungan TCP terbentuk (jabat tangan tiga arah)
• Sejauh mana jabat tangan TLS sampai — apakah ServerHello kembali ke ClientHello, apakah dipotong dengan RST atau peringatan selama jabat tangan
• Nama host tujuan di ClientHello (SNI), dan versi TLS yang dinegosiasikan
• Setelah sambungan naik, sisi mana yang berhenti mengirim. Lokasi keheningan, transmisi ulang, RST, atau penutupan bersih (FIN)

Dengan kata lain, mengisolasi “tidak bisa menyambung”, “putus di tengah”, dan “tidak ada respons yang kembali” hampir tidak pernah butuh dekripsi muatan. Yang hilang karena enkripsi adalah “apa yang mereka katakan”; “siapa yang diam, dan kapan” tetap ada.

flowchart TB
    accTitle: Apa yang bisa dan tidak bisa ditunjukkan penangkapan TLS
    accDescr: Enkripsi hanya menyembunyikan muatan data aplikasi; pembentukan sambungan TCP, berhasil atau gagalnya jabat tangan TLS, SNI dan versi TLS, RST, dan sisi mana yang diam tetap terlihat dengan enkripsi dibiarkan di tempat
    tls["Penangkapan lalu lintas TLS"] --> vis["Terlihat"]
    tls --> hid["Tidak terlihat"]
    vis --> v1["Pembentukan sambungan TCP"]
    vis --> v2["Hasil TLS dan SNI"]
    vis --> v3["RST / siapa yang diam"]
    hid --> h1["Muatan data aplikasi"]

Gambar 16: Enkripsi hanya kehilangan muatan; kerangka percakapan masih bisa dibaca dengan TLS dibiarkan di tempat.

Ketika Anda masih butuh muatan, Wireshark bisa mendekripsi TLS memakai kunci sesi yang ditulis lewat variabel lingkungan SSLKEYLOGFILE. Dukungan terbatas pada beberapa implementasi seperti Firefox, Chrome, Edge berbasis Chromium, dan pustaka keluarga OpenSSL; SChannel bawaan Windows (aplikasi yang memakai WinHTTP atau WinINET) tidak mendukung mekanisme ini.¹⁰ Karena “kunci sesi ditulis ke berkas” berarti siapa pun yang punya berkas itu bisa mendekripsi seluruh percakapan, ini bukan teknik produksi; perlakukan sebagai reproduksi dan pengawakutuan di lingkungan pengembangan.

flowchart TB
    accTitle: Cara kerja dekripsi SSLKEYLOGFILE dan batasannya
    accDescr: Kunci sesi yang ditulis lewat SSLKEYLOGFILE memungkinkan Wireshark mendekripsi TLS, tetapi hanya sebagian implementasi seperti Firefox dan keluarga Chrome yang mendukung dan SChannel tidak; siapa pun yang punya berkas kunci bisa mendekripsi percakapan, jadi perlakukan sebagai teknik hanya untuk lingkungan pengembangan
    env["Atur SSLKEYLOGFILE"] --> key["Tulis kunci sesi"]
    key --> ws["Baca di Wireshark"]
    key -.-> risk["Pemegang kunci bisa mendekripsi"]
    risk -.-> dev["Hanya pengembangan"]
    env -.-> sup["Hanya sebagian tumpukan TLS"]
    sup -.-> sch["SChannel: tidak didukung"]

Gambar 17: Menulis kunci sesi bisa mendekripsi, tetapi implementasi yang didukung terbatas, dan sifat kunci membuatnya teknik hanya untuk lingkungan pengembangan.

Ketika lalu lintas lewat proksi internal, tujuan yang muncul dalam penangkapan adalah server proksi, dan TLS mengalir di dalam terowongan CONNECT. Pertanyaan pendahuluan ke proksi mana aplikasi bahkan menuju dirapikan di artikel pendamping hari yang sama “Proksi perusahaan dan aplikasi Windows — merapikan resolusi proksi di WinINET, WinHTTP, dan .NET”.

9. Mengorelasikan dengan log aplikasi — menaruh waktu pada sumbu yang sama

Penangkapan sendiri jarang menghasilkan kesimpulan. Langkah penentu di praktik adalah menaruh satu baris log aplikasi dan satu bolak-balik paket pada sumbu waktu yang sama.

Prosedurnya seperti ini.

1. Identifikasi waktu insiden dari log aplikasi (misalnya, pengecualian timeout pada 10:23:41). Jika nilai timeout 30 detik, awalnya seharusnya sekitar 10:23:11.
2. Alihkan tampilan waktu Wireshark ke [View] → [Time Display Format] → [Date and Time of Day], dan persempit interval dengan filter tampilan (Anda juga bisa memfilter menurut waktu, seperti frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").
3. Di interval itu, konfirmasikan urutan Bab 5 (jabat tangan → RST → transmisi ulang → ZeroWindow). Jika Anda bisa menyelaraskan sampai “30 detik sebelum waktu timeout log, SYN dikirim, dan setelah itu hanya transmisi ulang SYN”, “timeout” di log diganti pengamatan “di titik penangkapan ini, sama sekali tidak ada balasan yang kembali” (apakah SYN tidak pernah sampai ke rekan, atau SYN/ACK yang kembali hilang di jalan pulang, tidak bisa diputus dari titik penangkapan ini saja. Jika perlu memutusnya, tangkap di server dan sejajarkan).
4. Selalu koreksi offset antara waktu penangkapan dan waktu log (offset jam yang Anda ukur di Bagian 7.1, dan notasi zona waktu log). Beberapa detik kesalahan korelasi akan memakukan percakapan yang salah sebagai pelaku.

flowchart TB
    accTitle: Prosedur menyelaraskan log aplikasi dan paket
    accDescr: Identifikasi waktu insiden dari log aplikasi, hitung mundur waktu mulai dari nilai timeout, persempit interval di Wireshark dengan filter tampilan, konfirmasikan bentuk berurutan, koreksi offset jam, dan taruh pada sumbu waktu yang sama
    lg["1. Identifikasi waktu insiden dari log"] --> rev["Hitung mundur awal dari nilai timeout"]
    rev --> flt["2. Persempit interval dengan filter tampilan"]
    flt --> chk["3. Konfirmasikan bentuk dalam urutan Bab 5"]
    chk --> adj["4. Koreksi offset jam"]
    adj --> done["Satu kata di log menjadi pengamatan"]

Gambar 18: Persempit interval dari waktu log, konfirmasikan bentuk, koreksi offset jam, dan taruh pada sumbu yang sama.

Ketika Anda menyerahkan hasil penyelidikan ke pihak ketiga (vendor, operator, staf jaringan pelanggan), memotong kebisingan dengan filter sebelum menyerahkan adalah sopan santun sekaligus langkah keamanan. Di Wireshark, persempit ke percakapan yang diminati dengan filter tampilan dan simpan “hanya paket yang ditampilkan” dengan [File] → [Export Specified Packets], dan Anda mendapat pcapng kecil hanya rentang yang Anda butuhkan.

Akhirnya, peringatan penanganan. Berkas penangkapan berisi komunikasi itu sendiri. Ia bisa mencakup kredensial protokol teks biasa, cookie HTTP dan kunci API, isi surat atau laporan, dan data pribadi. Putuskan tiga poin berikut sebagai satu paket dengan prosedur penangkapan.

• Penangkapan seminimal mungkin: Persempit sasaran dengan filter pra-penangkapan (Bab 3 dan 4) dan jaga jendela waktu sependek mungkin. Jangan “tangkap semuanya saja” di lingkungan pelanggan
• Persempit sebelum menyerahkan: Ekspor hanya percakapan yang diminati; jangan sertakan lalu lintas pihak ketiga yang tidak terkait. Jika bagian sensitif masih ada, sepakati dengan penerima penyamaran atau cara lain
• Penyimpanan dan penghapusan: Putuskan di mana berkas penangkapan disimpan, berapa lama, dan kapan dihapus, dan hapus saat penyelidikan selesai

flowchart TB
    accTitle: Tiga keputusan sebelum menyerahkan berkas penangkapan
    accDescr: Penangkapan berisi komunikasi itu sendiri, jadi putuskan sebagai satu paket dengan prosedur penangkapan bahwa Anda akan mempersempit ke minimum dengan filter pra-penangkapan dan jendela waktu, mengekstrak hanya percakapan yang diminati sebelum serah agar lalu lintas tidak terkait tidak disertakan, dan memutuskan lokasi serta masa simpan lalu menghapus setelah penyelidikan
    cap["Penangkapan = lalu lintas"] --> p1["Tangkap yang minimum"]
    cap --> p2["Ekstrak sasaran dulu"]
    cap --> p3["Atur penyimpanan, hapus"]
    p2 -.-> exp["Filter dan ekspor"]

Gambar 19: Putuskan penangkapan minimum, penyempitan sebelum serah, serta penyimpanan dan penghapusan sebagai satu paket dengan prosedur penangkapan.

10. Ringkasan

• Satu lapis di bawah “timeout” log aplikasi adalah fakta paket yang benar-benar lewat di kabel. Apakah SYN tidak mendapat balasan, RST memutus, transmisi ulang berlanjut, atau ZeroWindow muncul mengubah ke mana Anda melihat berikutnya.
• Meski di situs yang tidak bisa memasang Wireshark, Anda bisa menangkap dengan pktmon dan netsh trace bawaan Windows. Tangkap dengan alat bawaan, baca dengan Wireshark di mesin sendiri — pembagian itu adalah bentuk dasar.
• pktmon empat langkah: daftarkan filter → pktmon start --capture → pktmon stop → pktmon etl2pcap. Secara bawaan terpotong 128 bita, jadi jika Anda ingin muatan jangan lupa --pkt-size 0. Melihat lokasi dan alasan drop adalah kekuatan yang hanya dimiliki pktmon.
• netsh trace menangkap sekelompok penyedia ETW sebagai skenario, dan dengan persistent=yes ia bisa bertahan melewati boot ulang. Ubah ETL ke pcapng dengan etl2pcapng untuk membacanya.
• Di Wireshark, mulai dari tcp.analysis.flags dan cari jabat tangan, RST, transmisi ulang, dan ZeroWindow dalam urutan itu. Lebih cepat jika Anda mengambil gambaran dengan Conversations dan I/O Graph dulu, lalu mempersempit.
• Lalu lintas ke localhost tidak pernah melewati NIC, jadi Anda tidak bisa menangkapnya dengan cara biasa. Gunakan adaptor loopback Npcap atau penangkapan dalam tumpukan pktmon.
• Tangkap di kedua sisi dan sejajarkan, dan “sisi mana yang diam” terselesaikan. Prasyaratnya sinkron jam (w32tm). Untuk insiden yang syarat reproduksinya tidak diketahui, tunggu dengan penyangga cincin.
• Bahkan di bawah TLS kerangka percakapan terlihat. Perlakukan dekripsi (SSLKEYLOGFILE) sebagai teknik hanya untuk lingkungan pengembangan, dan perlakukan berkas penangkapan sendiri sebagai rahasia: masukkan penangkapan minimum, penyempitan, dan penghapusan ke dalam operasi.

Penangkapan paket sering dianggap “alat spesialis jaringan”, tetapi di praktik ia adalah alat penyelidikan sisi aplikasi yang baru mulai berarti ketika Anda menyelaraskannya dengan log aplikasi. Lain kali penyelidikan berhenti di satu kata “timeout”, pergilah melihat satu lapis ke bawah.

Artikel terkait

• Mengapa transmisi ulang TCP menghentikan komunikasi kamera industri, dan cara mengisolasinya
• Kesalahpahaman bahwa TCP membiarkan Anda menerima dalam satuan yang sama dengan yang Anda kirim — merancang penerimaan di seputar aliran bita
• Merasakan model OSI secara nyata — membedah satu permintaan HTTP menjadi tujuh lapisannya
• Panduan praktis Process Monitor (ProcMon) — menunjuk “pengaturan tidak diterapkan” dan “ACCESS DENIED” dalam 10 menit
• Firewall Windows dan aplikasi bisnis — daftarkan aturan masuk dari pemasang
• Proksi perusahaan dan aplikasi Windows — merapikan resolusi proksi di WinINET, WinHTTP, dan .NET

Area konsultasi terkait

KomuraSoft LLC menangani penyelidikan bug berawal komunikasi seperti “komunikasi aplikasi bisnis sesekali gagal dan kami tidak menemukan penyebabnya” dan “kami ingin mengisolasi galat sambungan yang hanya terjadi di lingkungan pelanggan”. Kami mengambil perancangan penangkapan (di mana, apa, dan seberapa banyak), analisis Wireshark, korelasi dengan log aplikasi, dan perbaikan sisi aplikasi sebagai satu pekerjaan berkesinambungan.

• Pengembangan aplikasi Windows
• Investigasi bug dan akar masalah
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Bagaimana cara menangkap paket di server pelanggan yang tidak boleh memasang Wireshark?

Gunakan alat bawaan Windows, pktmon atau netsh trace, dan Anda bisa menangkap tanpa memasang perangkat lunak tambahan. Dengan pktmon, daftarkan filter di terminal yang ditingkatkan, mulai penangkapan dengan pktmon start --capture, lalu hentikan dengan pktmon stop. File ETL yang dihasilkan dapat diubah ke pcapng dengan pktmon etl2pcap, sehingga analisis dibawa ke Wireshark di mesin sendiri. "Tangkap dengan alat bawaan, baca dengan Wireshark" adalah pembagian dasar di situs yang membatasi pemasangan.

Haruskah memakai pktmon atau netsh trace?

Jika OS punya pktmon (Windows 10 / Windows Server 2019 dan yang lebih baru), mulai dari pktmon. Perintahnya sederhana, Anda bisa melihat komponen tumpukan jaringan mana yang membuang paket (alasan drop), dan konversi pcapng mandiri. netsh trace lebih baik saat menangkap di OS lama tanpa pktmon, saat ingin mengumpulkan peristiwa ETW komponen Windows sebagai skenario, atau saat penangkapan harus bertahan melewati boot ulang dengan persistent=yes. Materi pemecahan masalah Microsoft juga menunjuk urutan ini: pktmon dulu, lalu netsh trace jika itu belum cukup.

Mengapa lalu lintas ke localhost (127.0.0.1) tidak muncul di Wireshark?

Lalu lintas ke localhost tidak pernah melewati NIC fisik; ia diputar balik di jalur loopback internal OS. Penangkapan biasa yang menargetkan adaptor fisik karena itu tidak pernah melihatnya. Di Wireshark, pilih "Adapter for loopback traffic capture" milik Npcap dan Anda bisa menangkap lalu lintas loopback. pktmon menangkap di dalam tumpukan jaringan, jadi ia juga bisa mengamati lalu lintas loopback. Kebingungan lain yang umum: "localhost" terselesaikan ke IPv6 ::1, sehingga layar yang Anda awasi untuk 127.0.0.1 kosong — pastikan dengan menyebutkan alamat secara eksplisit.

Bisakah isi lalu lintas HTTPS (TLS) terlihat dalam penangkapan paket?

Muatan data aplikasi terenkripsi dan tidak terlihat. "Kerangka" percakapan — sambung dan putus TCP, apakah jabat tangan TLS berhasil, pemutusan RST, sisi mana yang berhenti merespons — tetap terlihat meski terenkripsi, jadi sebagian besar penyelidikan timeout bisa jalan dengan TLS dibiarkan terenkripsi. Jika Anda butuh muatan, dekripsi lewat SSLKEYLOGFILE ada, tetapi hanya didukung sebagian implementasi TLS seperti Firefox dan keluarga Chrome; SChannel bawaan Windows tidak didukung. Mekanismenya menulis bahan kunci rahasia, jadi perlakukan sebagai opsi hanya untuk lingkungan pengembangan.

Amankah mengirim file penangkapan ke meja dukungan eksternal?

Mengirimnya apa adanya berbahaya. Penangkapan berisi komunikasi itu sendiri dan bisa mencakup kredensial protokol teks biasa, cookie, kunci API, dan data pribadi. Pertama, pada saat menangkap, persempit filter dan jendela waktu ke minimum yang Anda butuhkan, dan sebelum menyerahkannya, ekstrak hanya percakapan sasaran dengan filter tampilan Wireshark lalu ekspor. Untuk yang masih tersisa, sepakati dengan penerima cara menangani bagian sensitif (penyamaran, atau pengiriman lewat cara lain) sebelum Anda kirim. Putuskan lebih dulu berapa lama file penangkapan disimpan dan kapan dihapus.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.