Praktik penangkapan paket di Windows — membedakan pemakaian pktmon, netsh trace, dan Wireshark

“Komunikasi server aplikasi bisnis gagal beberapa kali dalam sebulan. Log aplikasi hanya menampilkan “timeout”. Log sisi server tidak punya galat pada waktu yang bersangkutan. Syarat reproduksinya tidak diketahui” — dalam konsultasi penyelidikan bug, bentuk ini benar-benar sering muncul.

Log aplikasi hanya menyimpan apa yang aplikasi “memutuskan untuk ditulis”. Hasilnya timeout memang diketahui, tetapi apakah permintaan sambungan (SYN) tidak mendapat balasan, apakah sambungan terbentuk lalu server diam di tengah jalan, apakah diputus paksa dengan RST, atau apakah paket sampai ke tujuan sama sekali, hanya tersisa satu lapis di bawah log — pada paket yang benar-benar lewat di kabel. Jika Process Monitor adalah cara melihat akses berkas dan registri dari satu lapis lebih dalam, penangkapan paket adalah cara melihat komunikasi dari satu lapis lebih dalam.

flowchart TB
    accTitle: Paket satu lapis di bawah log aplikasi
    accDescr: Log aplikasi hanya menyimpan apa yang diputuskan untuk ditulis; apakah SYN tanpa balasan, diam setelah sambungan terbentuk, diputus RST, atau paket sampai tujuan, hanya tersisa pada paket yang benar-benar lewat di kabel
    log["Log aplikasi"] --> dec["Hanya yang diputuskan untuk ditulis yang tersisa"]
    dec --> to["Hasilnya satu kata timeout"]
    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 sambungan terbentuk?"]
    pkt --> q3["Diputus dengan RST?"]
    pkt --> q4["Sampai ke tujuan?"]

Gambar 1: Yang tersisa di log hanyalah hasilnya; rincian timeout hanya ada pada paket satu lapis di bawahnya.

Yang biasanya membuat orang berhenti di sini adalah batasan “Wireshark tidak bisa dipasang di server pelanggan”. Situs yang persetujuan manajemen perubahan atau kebijakan keamanannya tidak turun, sehingga penambahan perangkat lunak untuk penyelidikan tidak realistis, tidak jarang. Namun Windows sudah membawa dua sarana penangkapan paket secara bawaan: pktmon dan netsh trace. Pengambilan dilakukan dengan alat bawaan OS, berkas hasilnya dibawa ke PC sendiri, lalu dibaca di Wireshark — dengan pembagian itu, paket tetap dapat dilihat di lapangan yang melarang pemasangan.

Artikel ini ditujukan kepada staf TI perusahaan kecil dan menengah serta pengembang aplikasi Windows. Ia merapikan cara membedakan pemakaian pktmon, netsh trace, dan Wireshark, plus prosedur praktis masing-masing. Jebakan lalu lintas loopback, keputusan apakah mengambil di klien atau di server, cara menghadapi masalah isi yang tidak terlihat karena TLS, sampai penyelarasan dengan log aplikasi, semuanya dijelaskan berdasarkan sumber primer per Agustus 2026.

1. Kesimpulan dulu

• “Yang mengambil adalah alat bawaan, yang membaca adalah Wireshark” adalah bentuk dasar di lapangan. Meski perangkat lunak tidak bisa dipasang di server pelanggan, pktmon dan netsh trace tersedia sebagai bawaan Windows. Log yang diambil diubah ke format pcapng, lalu dianalisis di Wireshark pada mesin sendiri.¹²
• pktmon adalah alat penangkapan paket yang terpasang secara bawaan di Windows 10 / Windows Server 2019 dan yang lebih baru. Dipakai dalam empat langkah — daftar filter, mulai, hentikan, konversi — dan kekuatannya yang khas adalah sampai diketahui di komponen tumpukan jaringan mana paket dibuang (alasan drop).³⁴
• netsh trace adalah alat bawaan yang lebih lama; ia dapat mengaktifkan sekelompok penyedia ETW sebagai “skenario”. Selain paket, peristiwa dari dalam komponen Windows juga tersimpan, dan dengan persistent=yes pengambilan dapat bertahan melewati boot ulang.⁵⁶
• Keluaran keduanya berformat ETL, dan Wireshark tidak dapat membukanya apa adanya. Untuk pktmon konversi ke pcapng memakai pktmon etl2pcap; untuk netsh trace memakai etl2pcapng, alat sumber terbuka buatan Microsoft.¹²
• Microsoft sendiri menuntun alur “pktmon dulu, lalu netsh trace jika itu belum cukup, dan analisis protokol di Wireshark”. Pembagian pemakaian dalam artikel ini mengikuti urutan rekomendasi resmi itu.⁷
• Secara bawaan pktmon hanya merekam 128 bita pertama setiap paket. Jika Anda berniat membaca sampai isinya di Wireshark, jangan lupa menentukan --pkt-size 0 (rekam seluruh paket) saat memulai.⁸
• Lalu lintas ke localhost tidak tampil dalam penangkapan biasa. Karena tidak melewati NIC. Di Wireshark gunakan adaptor loopback Npcap; dengan alat bawaan, gunakan pengambilan di dalam tumpukan milik pktmon.⁹
• Meski isi tidak terlihat karena TLS, yang dapat diketahui tetap banyak. Pembentukan sambungan, apakah jabat tangan TLS berhasil, RST, dan sisi mana yang diam tetap terlihat meski terenkripsi. Dekripsi lewat SSLKEYLOGFILE adalah sarana yang terbatas pada lingkungan pengembangan.¹⁰
• Penangkapan berisi isi komunikasi itu sendiri. Dengan prasyarat bahwa ia bisa mencakup kredensial dan data pribadi, masukkan pengambilan seminimal mungkin dan penyempitan sebelum diserahkan ke luar perusahaan ke dalam prosedur.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 21, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Tiga alat penangkapan dan cara membedakan pemakaiannya

Pertama, peran ketiga alat itu dirangkum dalam satu tabel.

Pembagian peran dalam satu kalimat: pktmon dan netsh trace adalah alat untuk “mengambil”, Wireshark adalah alat untuk “membaca”. Wireshark juga punya fungsi pengambilan, tetapi tidak dapat dipakai di lingkungan yang tidak mengizinkan pemasangan. Sebaliknya, ETL dari alat bawaan bisa dikonversi ke teks lalu dibaca, tetapi menelusurinya secara visual tanpa filter tampilan dan tanpa analisis TCP adalah siksaan. “Ambil dengan alat bawaan di lapangan, konversi ke pcapng, lalu baca di Wireshark pada mesin sendiri” adalah rute terpendek di lapangan yang punya batasan.

flowchart TB
    accTitle: Yang mengambil adalah alat bawaan, yang membaca adalah Wireshark
    accDescr: Di lapangan ETL diambil dengan pktmon atau netsh trace, dikonversi ke pcapng dengan alat konversi masing-masing, lalu dianalisis di Wireshark pada 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 pada mesin sendiri"]

Gambar 2: Di lapangan ETL diambil dengan alat bawaan, dikonversi ke pcapng, lalu dibaca di Wireshark pada mesin sendiri.

Panduan investigasi packet loss Microsoft memakai kerangka yang sama: pertama lakukan pengambilan dan isolasi penyebab dengan pktmon, jika itu belum cukup lanjut ke jejak tingkat komponen seperti netsh trace start scenario=InternetClient, dan perilaku protokol dianalisis di Wireshark.⁷

Sebagai prasyarat untuk membaca apa yang terekam di paket, pemahaman akan lebih cepat jika tumpukan lapisan Ethernet, IP, TCP, dan data aplikasi sudah terbayang. Anatomi lapisan itu digambarkan di “Membayangkan model acuan OSI dengan jelas”.

3. Praktik pktmon — filter, mulai, hentikan, konversi

Alur dasar pktmon ada empat langkah. Jalankan di terminal dengan hak administrator.

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

:: 2. Mulai pengambilan. Rekam seluruh paket, timpa dengan ring buffer 1GB
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Reproduksikan kejadian. Sementara menunggu, aliran dan pembuangan dapat dicek lewat penghitung
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 yang didaftarkan (filter tetap ada sampai dihapus secara eksplisit).
::    Perhatian: filter remove tidak dapat diberi nama; ia menghapus "semua" filter yang terdaftar.
::    Di lingkungan yang masih menyimpan filter penyelidikan lain, periksa dulu dengan pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: Prosedur dasar pktmon
    accDescr: Daftarkan filter untuk mempersempit sasaran, mulai pengambilan, reproduksikan kejadian, hentikan, konversi ke pcapng dengan etl2pcap, lalu hapus filter yang didaftarkan
    fa["1. Persempit sasaran dengan filter add"] --> st["2. Mulai pengambilan dengan start --capture"]
    st --> re["3. Reproduksikan kejadian"]
    re -.-> ct["Cek aliran dan pembuangan dengan counters"]
    re --> sp["4. Hentikan dengan stop"]
    sp --> cv["Konversi ke pcapng dengan etl2pcap"]
    cv --> rm["5. Bersihkan dengan filter remove"]

Gambar 3: pktmon dimulai dari pendaftaran filter; setelah pengambilan, penghentian, dan konversi, filter dibersihkan secara eksplisit.

Poin yang perlu dipegang adalah sebagai berikut.

• Filter didaftarkan sebelum pengambilan dimulai. Dokumentasi Microsoft juga sangat menganjurkan penerapan filter sebelum mulai, karena pengambilan seluruh lalu lintas terlalu berisik. Filter dapat ditentukan dengan alamat IP, port, alamat MAC, protokol, VLAN ID, dan semacamnya, paling banyak 32 buah. Beberapa filter adalah kondisi OR: “rekam jika cocok dengan salah satunya”.³
• Filter pktmon tidak membedakan sumber dan tujuan. -i 192.168.10.20 berarti “paket yang alamat ini adalah sumber atau tujuannya”. Penyempitan arah dilakukan belakangan dengan filter tampilan Wireshark setelah konversi.³
• Ukuran paket bawaan adalah 128 bita. Cukup untuk menganalisis header, tetapi jika Anda akan membaca sampai data aplikasi, rekam seluruhnya dengan --pkt-size 0.⁸
• Log secara bawaan memakai mode circular (ring buffer), ukuran bawaan 512MB. Batas atas dapat diubah dengan --file-size. Jika --log-mode real-time, tampilan langsung ke layar dan berkas log tidak dibuat. Pastikan dulu “lalu lintas yang dituju memang terlihat” dengan tampilan real-time, baru mulai pengambilan yang sesungguhnya, agar tidak sia-sia.⁸

flowchart TB
    accTitle: Cara kerja filter pktmon
    accDescr: Beberapa filter yang didaftarkan bekerja sebagai kondisi OR (rekam jika salah satu cocok); alamat yang ditentukan tidak membedakan sumber dan tujuan, sehingga penyempitan arah dilakukan dengan filter tampilan Wireshark setelah konversi
    f1["Filter 1"] --> orc["Rekam jika salah satu cocok"]
    f2["Filter 2"] --> orc
    f3["Filter 3 (maks. 32)"] --> orc
    orc --> rec["Tercatat di log pengambilan (kondisi OR)"]
    rec -.-> nodir["Sumber dan tujuan tidak dibedakan"]
    nodir -.-> ws["Arah dipersempit di Wireshark setelah konversi"]

Gambar 4: Beberapa filter bekerja sebagai kondisi OR; arah sumber atau tujuan dipersempit di Wireshark setelah konversi.

3.1. Kekuatan khas pktmon — diketahui di mana paket dibuang

Nilai khas pktmon yang berbeda dari Wireshark adalah paket ditangkap di beberapa titik di dalam tumpukan jaringan, bukan di satu titik NIC, lalu lokasi dan alasan pembuangan (drop) dilaporkan. Karena dapat diketahui sampai komponen mana paket tiba dan di mana ia hilang, alasan drop seperti “MTU mismatch” atau “filter VLAN” menuntun ke penyebab tanpa tebakan 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 titik NIC, sehingga dapat dilaporkan sampai komponen mana paket tiba dan di mana dibuang beserta alasannya
    pin["Paket"] --> p1["Ditangkap di titik 1"]
    p1 --> p2["Ditangkap di titik 2"]
    p2 --> p3["Dibuang di titik 3"]
    p3 -.-> rz["Laporkan lokasi pembuangan dan alasan drop"]
    rz -.-> ex["Contoh: MTU mismatch atau filter VLAN"]

Gambar 5: Karena ditangkap di beberapa titik di dalam tumpukan, sampai di mana paket tiba dan di mana dibuang dapat diketahui beserta alasannya.

• pktmon list menampilkan daftar dan ID komponen jaringan yang dipantau (NIC, tumpukan protokol, filter driver, dan semacamnya).
• pktmon counters --drop-reason menampilkan penghitung lolos/buang per komponen dan alasan drop terbaru. Berguna sebagai isolasi awal sebelum log dianalisis.¹¹
• Jika dikonversi ke teks dengan pktmon etl2txt, paket yang dibuang dikeluarkan dengan drop dan dropReason (alasan pembuangan).³

Kecurigaan “dibuang di suatu tempat di OS sebelum sampai ke aplikasi” tidak selesai hanya dengan menatap Wireshark. Fungsi ini berguna, misalnya, untuk mengisolasi kasus yang dijatuhkan firewall karena aturan masuk yang tidak memadai (“Firewall Windows dan aplikasi bisnis”).

Ada satu peringatan. pktmon merekam paket yang sama di beberapa titik di dalam tumpukan, sehingga konversi apa adanya ke pcapng dapat membuat paket yang sama tampak duplikat. Informasi “di komponen mana ditangkap” tidak diteruskan ke format pcapng; untuk tujuan dibaca di Wireshark, praktik bakunya adalah mempersempit titik dengan --component-id pada pktmon etl2pcap saat konversi (atau memisahkan yang drop saja ke berkas lain dengan --drop-only).¹

flowchart TB
    accTitle: Alasan paket yang sama tampak duplikat saat konversi pcapng
    accDescr: pktmon merekam paket yang sama di beberapa titik di dalam tumpukan, dan pcapng tidak mewarisi informasi di komponen mana ditangkap, sehingga dapat tampak duplikat; praktik bakunya adalah mempersempit titik dengan component-id atau memisahkan yang drop saja dengan drop-only
    same["Paket yang sama direkam di beberapa titik"] --> conv["Konversi apa adanya ke pcapng"]
    conv --> lost["Informasi titik tangkap tidak diteruskan"]
    lost --> dup["Paket yang sama tampak duplikat"]
    dup --> c1["Persempit titik dengan --component-id"]
    dup --> c2["Berkas terpisah dengan --drop-only"]

Gambar 6: Karena informasi titik tangkap tidak diteruskan ke pcapng, praktik bakunya adalah mempersempit titik dulu baru mengonversi.

4. Praktik netsh trace — skenario dan ETL, pengambilan yang melewati boot ulang

netsh trace adalah mekanisme pengambilan jejak yang sudah ada di Windows lebih lama daripada pktmon. Cirinya: dalam satuan “skenario”, seperangkat penyedia ETW yang terkait dengan masalah itu dapat diaktifkan sekaligus.⁶

:: Daftar skenario yang tersedia, dan konfirmasi penyedia yang termasuk dalam skenario
netsh trace show scenarios
netsh trace show scenario netconnection

:: Mulai pengambilan. Termasuk penangkapan paket, buffer sirkular 1GB
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Reproduksikan kejadian lalu hentikan (proses penggabungan memakan sedikit waktu)
netsh trace stop

• Jika capture=yes ditambahkan, penangkapan paket aktif, dan sasaran dapat dipersempit dengan filter penangkapan seperti ipv4.address=192.168.10.20. Daftar filter dapat dilihat dengan netsh trace show capturefilterHelp.⁶
• Saat dihentikan, selain berkas ETL juga dihasilkan berkas .cab. .cab berisi informasi sistem seperti konfigurasi adaptor dan build OS, sehingga sekaligus mengumpulkan informasi lingkungan.⁶
• Hanya satu sesi jejak yang dapat berjalan sekaligus. Sebelum memulai pengambilan lain, periksa dengan netsh trace show status apakah ada sesi yang masih berjalan.⁶
• Jika persistent=yes ditambahkan, sesi dipertahankan melewati boot ulang. Pengambilan kejadian yang tidak sempat dimulai secara manual — “komunikasi gagal hanya sekejap setelah boot ulang”, “sambungan layanan saat startup gagal” — adalah wilayah khas netsh trace.⁵

flowchart TB
    accTitle: Pengambilan skenario netsh trace
    accDescr: Memulai dengan menentukan skenario mengaktifkan seperangkat penyedia ETW sekaligus; jika capture=yes, paket juga diambil; saat dihentikan dihasilkan berkas ETL dan berkas .cab
    sc["Mulai dengan menentukan skenario"] --> pv["Aktifkan seperangkat penyedia"]
    sc -->|capture=yes| pc["Paket juga diambil"]
    pv --> re["Reproduksikan kejadian"]
    pc --> re
    re --> sp["Hentikan dengan stop"]
    sp --> etl["Berkas ETL"]
    sp --> cab[".cab (informasi sistem)"]

Gambar 7: Memulai dengan skenario mengaktifkan seperangkat penyedia sekaligus; saat dihentikan dihasilkan ETL dan .cab.

4.1. Membuat ETL dapat dibaca di Wireshark — etl2pcapng

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

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

Saat konversi, etl2pcapng menuliskan ID proses yang terlibat pada paket sebagai komentar paket. “Komunikasi proses mana” dapat dicek di Wireshark, sehingga berguna untuk isolasi di lingkungan yang beberapa aplikasi di server yang sama sedang berkomunikasi.²

Peristiwa ETW (peristiwa internal Windows yang dicatat penyedia skenario) tidak dikonversi ke pcapng. Jika peristiwa juga ingin dibaca, konversi ke teks dan semacamnya dengan netsh trace convert input=C:\temp\nettrace.etl, atau buka di Windows Performance Analyzer dan alat sejenis.⁵⁷

flowchart TB
    accTitle: Cara membaca ETL netsh trace terbagi dua
    accDescr: Paket di dalam ETL dikonversi ke pcapng dengan etl2pcapng lalu dibaca di Wireshark; peristiwa ETW tidak dikonversi ke pcapng, sehingga dibaca dengan netsh trace convert atau Windows Performance Analyzer
    etl["ETL netsh trace"] --> pk["Paket"]
    etl --> ev["Peristiwa ETW"]
    pk -->|etl2pcapng| pc["Konversi ke pcapng"]
    pc --> ws["Baca di Wireshark"]
    pc -.-> pid["ID proses tersisa di komentar"]
    ev -.-> no["Tidak dikonversi ke pcapng"]
    no --> alt["Baca dengan convert atau WPA"]

Gambar 8: Dari ETL, paket dikonversi ke pcapng lalu dibaca; peristiwa ETW dibaca dengan sarana lain.

5. Pengantar cara membaca di Wireshark — filter tampilan dan analisis TCP

Setelah pcapng dibuka, pertama-tama kurangi kebisingan dengan filter tampilan. Yang sering dipakai dirangkum dalam tabel.¹²¹³

tcp.analysis.* adalah bendera analisis yang Wireshark tetapkan secara otomatis dengan menelusuri nomor urut TCP. Transmisi ulang, ACK duplikat, urutan tertukar, ZeroWindow, dan semacamnya dapat dipungut secara mekanis, sehingga praktik baku saat mulai membaca adalah mengetik tcp.analysis.flags dulu dan membuat daftar “lokasi yang tampak bermasalah”.¹³

Dalam penyelidikan timeout, bentuk berikut dicari berurutan.

1. Apakah three-way handshake terbentuk. Apakah tiga paket SYN→SYN/ACK→ACK lengkap. Jika SYN diulang tanpa balasan, paket tidak sampai ke lawan atau dibuang diam-diam di tengah jalan (pola khas firewall).
2. RST datang dari sisi mana. RST segera terhadap SYN berarti tidak ada yang mendengarkan di port tujuan; RST setelah sambungan terbentuk berarti salah satu sisi memutus paksa. IP sumber RST adalah bukti langsung “siapa yang memutus”.
3. Apakah transmisi ulang berlanjut. Transmisi ulang segmen yang sama berulang adalah tanda bahwa ACK tidak kembali ke sisi pengirim. Apakah data pergi yang hilang atau ACK pulang yang hilang tidak dapat dipastikan dari penangkapan satu sisi saja (justru karena itu “ambil di kedua sisi” di bab berikutnya berguna). Pendalaman transmisi ulang dan timeout dibahas di “Penyebab komunikasi kamera industri berhenti karena transmisi ulang TCP, dan cara mengisolasinya”.
4. Apakah ZeroWindow muncul. Itu tanda aplikasi sisi penerima tidak membaca data dari soket, sehingga buffer terima penuh. Menjadi dasar untuk mencurigai rancangan aplikasi penerima, bukan jaringan (“Kesalahpahaman bahwa setiap satuan Send di TCP dapat di-Receive dalam satuan yang sama”).

flowchart TB
    accTitle: Urutan bentuk yang dicari dalam penyelidikan timeout
    accDescr: Periksa berurutan terbentuknya three-way handshake, ada tidaknya RST dan sumbernya, berlanjutnya transmisi ulang, lalu ZeroWindow, untuk mendapat petunjuk penyebab
    hs{"SYN mendapat balasan?"} -->|tidak| ng["Curiga tidak sampai dan dibuang (khas FW)"]
    hs -->|ya| rs{"Ada RST?"}
    rs -->|ya| who["Sumber RST adalah sisi yang memutus"]
    rs -->|tidak| rt{"Transmisi ulang berlanjut?"}
    rt -->|ya| ack["Tanda ACK tidak kembali"]
    rt -->|tidak| zw{"ZeroWindow muncul?"}
    zw -->|ya| app["Tanda aplikasi penerima tidak membaca"]

Gambar 9: Mencari bentuk berurutan handshake, RST, transmisi ulang, ZeroWindow mempersempit tempat yang dicek berikutnya.

Sebelum membaca paket satu per satu, meninjau keseluruhan dengan fungsi statistik juga efektif. [Statistik]→[Percakapan (Conversations)] adalah daftar “pasangan IP dan pasangan port mana, dari kapan sampai kapan, berbicara seberapa banyak”; setelah percakapan tujuan diidentifikasi, hanya percakapan itu yang dapat difilter. [Statistik]→[Grafik I/O (I/O Graph)] adalah grafik aliran pada sumbu waktu; bentuk seperti “mulai saat ini hanya satu arah yang sunyi” langsung terlihat. Klik kanan percakapan TCP sasaran lalu pilih [Ikuti]→[Aliran TCP] untuk membaca bolak-balik sambungan itu saja dalam teks biasa.

flowchart TB
    accTitle: Tinjau dengan statistik, lalu persempit percakapan
    accDescr: Identifikasi percakapan tujuan dari daftar Conversations tentang siapa berbicara kapan dan seberapa banyak, tangkap jendela sunyi dengan I/O Graph, filter hanya percakapan itu, lalu baca utuh sebagai aliran TCP
    ov["Tinjau keseluruhan dengan statistik"] --> cv["Daftar percakapan di Conversations"]
    ov --> io["Lihat aliran di grafik I/O"]
    cv --> flt["Filter hanya percakapan tujuan"]
    io -.-> mute["Waktu yang menjadi sunyi diketahui"]
    flt --> fs["Baca utuh sebagai aliran TCP"]

Gambar 10: Sebelum membaca per paket, tinjau dengan statistik, persempit ke percakapan tujuan, baru baca utuh.

6. Jebakan lalu lintas loopback — tujuan localhost tidak melewati NIC

Mencoba menyelidiki komunikasi antaraplikasi di PC yang sama — misalnya sambungan dari aplikasi bisnis ke layanan perantara di localhost:8080 — lalu macet karena “tidak ada apa-apa di Wireshark” adalah jebakan klasik.

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

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

Gambar 11: Tujuan localhost diputar balik sebelum NIC, sehingga tidak muncul dari awal pada penangkapan adaptor fisik.

Ada dua cara menanganinya.

• Jika mengambil dengan Wireshark: pilih “Adapter for loopback traffic capture” yang disediakan Npcap sebagai sasaran penangkapan. Pemasang Wireshark untuk Windows (3.0 dan yang lebih baru) menyertakan Npcap, jadi jika Wireshark sudah terpasang, tidak perlu pekerjaan tambahan.⁹
• Jika mengambil dengan alat bawaan: pktmon mengambil di beberapa titik di dalam tumpukan jaringan, bukan di luar NIC⁴, sehingga juga dapat dipakai untuk mengamati lalu lintas loopback. Demi kepastian, sebelum menunggu reproduksi di lingkungan produksi, pastikan di lingkungan itu bahwa lalu lintas loopback yang dituju benar-benar terlihat dengan tampilan real-time pktmon start -c -m real-time.

Perhatikan juga dua kekeliruan berikut.

• “localhost” kadang diselesaikan ke IPv6 ::1. Polanya: aplikasi tersambung ke ::1 (IPv6), sementara sisi yang menyelidiki hanya melihat 127.0.0.1 (IPv4) lalu salah menyimpulkan “tidak ada komunikasi”. Pasang filter tampilan ke keduanya seperti ip.addr == 127.0.0.1 || ipv6.addr == ::1, atau nyatakan tujuan sambungan aplikasi sebagai alamat secara eksplisit.⁹
• Lalu lintas ke IP nyata mesin sendiri juga tidak keluar ke kabel. Jika PC yang sama tersambung dari 192.168.10.5 ke 192.168.10.5, bahkan jika tujuannya IP nyata, OS memutar baliknya di dalam. Ingat bahwa “karena IP nyata yang ditentukan, mestinya melewati NIC” tidak selalu benar.

flowchart TB
    accTitle: Kekeliruan localhost yang diselesaikan ke IPv6
    accDescr: localhost aplikasi kadang diselesaikan ke ::1 (IPv6) lalu tersambung; jika sisi yang menyelidiki hanya melihat 127.0.0.1, komunikasi dianggap tidak ada, jadi pasang filter ke kedua alamat atau nyatakan tujuan sebagai alamat
    app["Aplikasi tersambung ke localhost"] --> v6["Sebenarnya diselesaikan ke ::1 (IPv6)"]
    look["Sisi penyelidik hanya melihat 127.0.0.1"] --> none["Layar kosong"]
    v6 --> none
    none --> fix1["Pasang filter ke kedua alamat"]
    none --> fix2["Nyatakan tujuan sebagai alamat"]

Gambar 12: Waspadai kekeliruan localhost yang diselesaikan ke ::1, lalu “tidak ada komunikasi” karena hanya 127.0.0.1 yang diawasi.

7. Di mana mengambil — satu sisi, kedua sisi, dan sinkronisasi waktu

Nilai penangkapan ditentukan oleh “di mana diambil”. Patokan keputusannya sebagai berikut.

Yang diketahui dari penangkapan satu sisi hanyalah “fakta yang terlihat dari posisi sendiri”. Meski transmisi ulang berlanjut di sisi klien, tidak dapat dibedakan apakah paket yang dikirim hilang di jalur, atau sampai ke server tetapi responsnya yang hilang. Jika diambil di kedua sisi lalu diselaraskan, terpastikan hal seperti “klien mengirim, server tidak menerima” — sisi mana yang diam. Di situasi yang ingin memastikan batas tanggung jawab (aplikasi, OS, perangkat jaringan, atau pihak lawan), ada nilai untuk merancang pengambilan kedua sisi dari awal.

flowchart TB
    accTitle: Yang diketahui dari pengambilan satu sisi vs kedua sisi
    accDescr: Penangkapan satu sisi tidak membedakan apakah paket pergi yang hilang atau respons pulang yang hilang; pengambilan di kedua sisi lalu diselaraskan memastikan sisi mana yang diam
    one["Ambil hanya satu sisi"] --> fact["Hanya fakta yang terlihat dari posisi sendiri"]
    fact --> und["Tidak bisa bedakan pergi hilang atau pulang hilang"]
    both["Ambil di kedua sisi sekaligus"] --> mt["Selaraskan"]
    mt --> fix["Sisi mana yang diam terpastikan"]
    mt -.-> pre["Prasyaratnya sinkronisasi waktu kedua mesin"]

Gambar 13: Satu sisi hanya memberi fakta yang terlihat; baru setelah diselaraskan di kedua sisi batas tanggung jawab terpastikan.

7.1. Prasyarat penyelarasan adalah sinkronisasi waktu

Untuk menyelaraskan penangkapan kedua sisi, jam kedua mesin harus selaras. Sebelum memulai pengambilan, periksa dan catat selisih waktu.

:: Periksa status sinkronisasi waktu (tujuan sinkron dan waktu sinkron terakhir)
w32tm /query /status

:: Ukur selisih waktu terhadap server lawan (5 sampel)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart menampilkan offset waktu antara Anda dan komputer lawan, dan menjadi dasar untuk mengoreksi “jam sisi server bergeser +0,8 detik” saat penyelarasan.¹⁴ Di lingkungan yang selisihnya besar, pada akhirnya lebih cepat memperbaiki sinkronisasi waktu dulu baru mengambil.

flowchart TB
    accTitle: Prosedur memeriksa selisih waktu sebelum penyelarasan
    accDescr: Periksa status sinkronisasi sendiri dengan w32tm, ukur selisih terhadap server lawan dengan stripchart lalu catat, pakai selisih itu sebagai dasar koreksi saat penyelarasan; jika selisih besar, perbaiki sinkronisasi dulu baru mengambil
    st["Periksa status sinkron dengan query"] --> mc["Ukur selisih dengan stripchart"]
    mc --> rc["Catat selisihnya"]
    rc --> use["Dasar koreksi saat penyelarasan"]
    mc -.-> big["Jika selisih besar, perbaiki sinkron dulu"]

Gambar 14: Ukur dan catat selisih waktu sebelum pengambilan, lalu jadikan dasar koreksi saat penyelarasan.

7.2. Untuk “tidak diketahui kapan terjadi”, pakai ring buffer

Untuk kejadian yang syarat reproduksinya tidak diketahui, dasarnya adalah terus mengambil dengan ring buffer, lalu berhenti ketika terjadi.

• pktmon: bawaan sudah mode circular. Tentukan batas atas (MB) dengan --file-size; paket lama ditimpa dari yang tertua.⁸
• netsh trace: tentukan seperti maxSize=1024 filemode=circular.⁵
• Wireshark: [Penangkapan]→[Opsi]→[Keluaran] dapat dikonfigurasi “beberapa berkas + ring buffer”. Berganti berdasarkan ukuran berkas atau waktu sambil hanya menyimpan N berkas terbaru, sehingga dapat dijalankan lama dengan batas pemakaian disk.¹⁵

Dalam semua kasus, bagikan kepada petugas di lapangan prosedur ini: ketika kejadian terjadi, catat waktu kejadian dulu, lalu hentikan pengambilan. Ring buffer menghapus masa lalu semakin lama menunggu, jadi jika prosedur dari kejadian sampai berhenti panjang, interval yang penting tertimpa.

flowchart TB
    accTitle: Operasi menunggu dengan ring buffer
    accDescr: Kejadian yang syarat reproduksinya tidak diketahui diambil terus dengan ring buffer sambil menunggu; ketika terjadi, catat waktu kejadian lalu segera hentikan; jika berhenti terlambat, paket lama tertimpa dan interval penting hilang
    st["Mulai pengambilan dengan ring buffer"] --> wt["Tunggu sambil terus mengambil"]
    wt --> ev["Kejadian terjadi"]
    ev --> memo["Catat waktu kejadian"]
    memo --> sp["Segera hentikan"]
    wt -.-> ow["Paket lama ditimpa"]
    ow -.-> late["Jika berhenti terlambat, interval penting hilang"]

Gambar 15: Semakin lama menunggu, masa lalu di ring buffer hilang, jadi setelah mencatat waktu kejadian segera hentikan.

8. Masalah isi yang tidak terlihat karena TLS — yang tetap dapat diketahui

Sebagian besar komunikasi bisnis sekarang memakai TLS (HTTPS). Mudah dikira “kalau terenkripsi, penangkapan sia-sia”, tetapi sebagian besar hal yang ingin diketahui dalam penyelidikan timeout tetap dapat diketahui dalam keadaan terenkripsi.

• Apakah sambungan TCP terbentuk (three-way handshake)
• Sejauh mana jabat tangan TLS berjalan — apakah ServerHello kembali terhadap ClientHello, apakah terputus oleh RST atau alert di tengah jabat tangan
• Nama host tujuan (SNI) yang tertera di ClientHello, dan versi TLS yang dinegosiasikan
• Setelah terbentuk, sisi mana yang berhenti mengirim. Posisi tanpa respons, transmisi ulang, RST, atau penutupan normal (FIN)

Dengan kata lain, untuk mengisolasi “tidak tersambung”, “putus di tengah”, “respons tidak kembali”, dekripsi isi hampir tidak diperlukan. Yang hilang karena enkripsi adalah “apa yang dibicarakan”; “siapa diam kapan” tetap tersisa.

flowchart TB
    accTitle: Yang terlihat dan yang tidak terlihat pada penangkapan TLS
    accDescr: Yang tidak terlihat karena enkripsi hanyalah isi data aplikasi; pembentukan sambungan TCP, berhasil tidaknya jabat tangan TLS, SNI dan versi TLS, RST dan sisi mana yang diam tetap dapat diketahui dalam keadaan terenkripsi
    tls["Penangkapan lalu lintas TLS"] --> vis["Yang terlihat"]
    tls --> hid["Yang tidak terlihat"]
    vis --> v1["Pembentukan sambungan TCP"]
    vis --> v2["Hasil TLS dan SNI"]
    vis --> v3["RST dan sisi mana yang diam"]
    hid --> h1["Isi data aplikasi"]

Gambar 16: Yang hilang karena enkripsi hanyalah isi; kerangka komunikasi tetap dapat dibaca meski TLS dibiarkan terenkripsi.

Jika isi tetap diperlukan, Wireshark punya mekanisme mendekripsi TLS memakai kunci sesi yang ditulis lewat variabel lingkungan SSLKEYLOGFILE. Namun yang didukung hanya sebagian implementasi seperti peramban 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 = siapa pun yang memegang berkas itu dapat mendekripsi seluruh komunikasi, ini bukan sarana untuk lingkungan produksi, melainkan untuk reproduksi dan debug di lingkungan pengembangan.

flowchart TB
    accTitle: Mekanisme dekripsi lewat SSLKEYLOGFILE dan batasannya
    accDescr: Kunci sesi yang ditulis lewat SSLKEYLOGFILE memungkinkan dekripsi TLS di Wireshark, tetapi yang didukung hanya sebagian implementasi seperti Firefox dan keluarga Chrome; SChannel tidak didukung; pemegang berkas kunci dapat mendekripsi komunikasi, sehingga ini sarana terbatas lingkungan pengembangan
    env["Atur SSLKEYLOGFILE"] --> key["Tulis kunci sesi ke berkas"]
    key --> ws["Dekripsi dan baca di Wireshark"]
    key -.-> risk["Pemegang kunci dapat mendekripsi semuanya"]
    risk -.-> dev["Posisikan sebagai terbatas lingkungan pengembangan"]
    env -.-> sup["Hanya sebagian implementasi TLS yang didukung"]
    sup -.-> sch["SChannel tidak didukung"]

Gambar 17: Dekripsi mungkin dengan menuliskan kunci sesi, tetapi implementasi yang didukung terbatas, dan karena sifat kunci itu sarana ini terbatas lingkungan pengembangan.

Selain itu, pada komunikasi lewat proksi internal, tujuan yang terekam di penangkapan menjadi server proksi, dan TLS mengalir di dalam terowongan CONNECT. Masalah di depannya — ke proksi mana aplikasi sebenarnya menuju — dirapikan di artikel saudari yang terbit hari yang sama, “Proksi internal dan aplikasi Windows — merapikan resolusi proksi di WinINET, WinHTTP, dan .NET”.

9. Menyelaraskan dengan log aplikasi — menyusun waktu pada sumbu yang sama

Sebenarnya jarang kesimpulan keluar dari penangkapan saja. Penentu di praktik adalah menyusun satu baris log aplikasi dan satu bolak-balik paket pada sumbu waktu yang sama.

Prosedurnya berbentuk sebagai berikut.

1. Identifikasi waktu kejadian dari log aplikasi (contoh: pengecualian timeout pada 10:23:41). Jika nilai timeout 30 detik, mulai seharusnya sekitar 10:23:11.
2. Ubah tampilan waktu Wireshark ke [Tampilan]→[Format tampilan waktu]→[Tanggal dan waktu], lalu persempit interval terkait dengan filter tampilan (dapat juga dipersempit berdasarkan waktu seperti frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").
3. Di interval itu, periksa urutan bab 5 (handshake→RST→transmisi ulang→ZeroWindow). Jika dapat diselaraskan sampai “30 detik sebelum waktu timeout di log, SYN dikirim, setelah itu hanya transmisi ulang SYN”, maka “timeout” di log tergantikan oleh fakta pengamatan “di titik pengambilan ini sama sekali tidak ada balasan” (apakah SYN tidak sampai ke lawan, atau SYN/ACK balasan hilang di jalan pulang, tidak dapat dipastikan dari titik pengambilan ini saja. Jika ingin memastikannya, selaraskan dengan pengambilan sisi server).
4. Selisih waktu antara jam penangkapan dan jam log (selisih yang diukur di pasal 7.1, notasi zona waktu log) wajib dikoreksi. Jika galat penyelarasan beberapa detik, komunikasi lain bisa dikira pelakunya.

flowchart TB
    accTitle: Prosedur menyelaraskan log aplikasi dan paket
    accDescr: Identifikasi waktu kejadian dari log aplikasi, hitung mundur waktu mulai dari nilai timeout, persempit interval di Wireshark dengan filter tampilan, periksa bentuk berurutan, koreksi selisih jam, dan susun pada sumbu waktu yang sama
    lg["1. Identifikasi waktu kejadian dari log"] --> rev["Hitung mundur mulai dari nilai timeout"]
    rev --> flt["2. Persempit interval dengan filter tampilan"]
    flt --> chk["3. Periksa bentuk menurut urutan bab 5"]
    chk --> adj["4. Koreksi selisih jam"]
    adj --> done["Satu kata di log menjadi fakta pengamatan"]

Gambar 18: Persempit interval dari waktu log, periksa bentuk, koreksi selisih jam, dan susun pada sumbu yang sama.

Ketika hasil penyelidikan diserahkan ke pihak ketiga (vendor, operator jaringan, staf jaringan pelanggan), mengurangi kebisingan dengan filter sebelum menyerahkan adalah sopan santun sekaligus langkah keamanan. Di Wireshark, persempit ke percakapan sasaran dengan filter tampilan, lalu simpan “hanya paket yang ditampilkan” dengan [Berkas]→[Ekspor paket yang ditentukan], dan Anda mendapat pcapng kecil hanya untuk rentang yang diperlukan.

Akhirnya, peringatan penanganan. Berkas penangkapan berisi isi 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 pengambilan.

• Pengambilan seminimal mungkin: Persempit sasaran dengan filter pra-pengambilan (bab 3 dan 4) dan buat jendelanya sesingkat mungkin. Jangan “ambil semua dulu” di lingkungan pelanggan
• Penyempitan sebelum menyerahkan: Ekspor hanya percakapan sasaran; jangan sertakan lalu lintas pihak ketiga yang tidak terkait. Jika bagian rahasia masih ada, sepakati dengan penerima penyembunyian atau cara lain
• Penyimpanan dan penghapusan: Putuskan lokasi simpan, masa berlaku, dan penghapusan berkas pengambilan, lalu hapus setelah penyelidikan selesai

flowchart TB
    accTitle: Tiga keputusan sebelum menyerahkan berkas penangkapan
    accDescr: Penangkapan berisi isi komunikasi itu sendiri, jadi putuskan sebagai satu paket dengan prosedur pengambilan: persempit ke minimum dengan filter pra-pengambilan dan jendela waktu, ekstrak hanya percakapan sasaran sebelum serah agar lalu lintas tidak terkait tidak disertakan, dan tentukan lokasi serta masa simpan lalu hapus setelah penyelidikan
    cap["Penangkapan berisi isi komunikasi"] --> p1["Pengambilan seminimal mungkin"]
    cap --> p2["Ekstrak sasaran dulu sebelum serah"]
    cap --> p3["Tentukan masa simpan lalu hapus"]
    p2 -.-> exp["Persempit dengan filter tampilan lalu ekspor"]

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

10. Ringkasan

• Satu lapis di bawah “timeout” log aplikasi ada fakta paket yang benar-benar lewat di kabel. Apakah SYN tidak mendapat balasan, diputus RST, transmisi ulang berlanjut, atau ZeroWindow muncul, mengubah tempat yang dicek berikutnya.
• Meski di lapangan yang tidak dapat memasang Wireshark, pengambilan bisa dilakukan dengan pktmon dan netsh trace bawaan Windows. Yang mengambil adalah alat bawaan, yang membaca adalah Wireshark pada mesin sendiri — pembagian itu adalah bentuk dasar.
• pktmon empat langkah: daftar filter → pktmon start --capture → pktmon stop → pktmon etl2pcap. Secara bawaan terpotong 128 bita, jadi jika ingin isinya jangan lupa --pkt-size 0. Melihat lokasi dan alasan drop adalah kekuatan yang hanya dimiliki pktmon.
• netsh trace mengambil sekelompok penyedia ETW sebagai skenario, dan dengan persistent=yes dapat melewati boot ulang. ETL dikonversi ke pcapng dengan etl2pcapng lalu dibaca.
• Di Wireshark, mulai dari tcp.analysis.flags dan cari bentuk handshake, RST, transmisi ulang, dan ZeroWindow berurutan. Lebih cepat jika ditinjau dulu dengan Conversations dan I/O Graph, baru dipersempit.
• Tujuan localhost tidak melewati NIC, jadi tidak dapat diambil dengan cara biasa. Gunakan adaptor loopback Npcap atau pengambilan di dalam tumpukan pktmon.
• Ambil di kedua sisi lalu selaraskan, dan “sisi mana yang diam” terpastikan. Prasyaratnya sinkronisasi waktu (w32tm). Untuk kejadian yang syarat reproduksinya tidak diketahui, tunggu dengan ring buffer.
• Meski TLS, kerangka komunikasi terlihat. Posisikan dekripsi (SSLKEYLOGFILE) sebagai sarana terbatas lingkungan pengembangan, dan perlakukan berkas penangkapan sendiri sebagai rahasia: masukkan pengambilan 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 berarti ketika diselaraskan dengan log aplikasi. Lain kali penyelidikan berhenti di satu kata “timeout”, pergilah melihat satu lapis ke bawah.

Artikel terkait

• Penyebab komunikasi kamera industri berhenti karena transmisi ulang TCP, dan cara mengisolasinya
• Kesalahpahaman bahwa setiap satuan Send di TCP dapat di-Receive dalam satuan yang sama — merancang penerimaan sebagai aliran bita
• Membayangkan model acuan OSI dengan jelas — membedah satu permintaan HTTP menjadi tujuh lapisan
• Panduan praktis Process Monitor (ProcMon) — mengidentifikasi “pengaturan tidak terbaca” dan “ACCESS DENIED” dalam 10 menit
• Firewall Windows dan aplikasi bisnis — daftarkan aturan masuk dari pemasang
• Proksi internal 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 kadang gagal dan penyebabnya tidak diketahui” dan “kami ingin mengisolasi galat sambungan yang hanya terjadi di lingkungan pelanggan”. Kami menangani secara berkesinambungan mulai dari perancangan pengambilan penangkapan paket (di mana, apa, dan seberapa banyak), analisis di Wireshark, penyelarasan dengan log aplikasi, sampai perbaikan sisi aplikasi.

• Pengembangan aplikasi Windows
• Penyelidikan bug dan analisis penyebab
• Konsultasi teknis dan tinjauan rancangan
• 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 mengambil penangkapan paket di server pelanggan yang tidak boleh dipasangi Wireshark?

Dengan pktmon atau netsh trace bawaan Windows, pengambilan bisa dilakukan tanpa memasang perangkat lunak tambahan. Untuk pktmon, daftarkan filter di terminal dengan hak administrator, mulai pengambilan dengan pktmon start --capture, lalu hentikan dengan pktmon stop. Berkas ETL yang dihasilkan dapat diubah ke format pcapng dengan pktmon etl2pcap, sehingga analisis dilakukan di Wireshark pada mesin sendiri setelah berkas dibawa pulang. "Yang mengambil adalah alat bawaan, yang membaca adalah Wireshark" adalah pembagian kerja dasar di lapangan yang membatasi pemasangan.

Mana yang sebaiknya dipakai, pktmon atau netsh trace?

Jika OS-nya mendukung pktmon (Windows 10 / Windows Server 2019 dan yang lebih baru), mulai dari pktmon. Perintahnya sederhana, Anda dapat memeriksa di komponen tumpukan jaringan mana paket dibuang (alasan drop), dan konversi ke pcapng selesai di alat itu sendiri. netsh trace lebih menguntungkan saat pengambilan dilakukan di OS lama yang belum punya pktmon, saat Anda ingin mengambil peristiwa ETW komponen Windows sekaligus dalam bentuk skenario, atau saat pengambilan harus bertahan melewati boot ulang dengan persistent=yes. Materi pemecahan masalah Microsoft juga menuntun urutan yang sama: pktmon dulu, lalu netsh trace jika itu belum cukup.

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

Lalu lintas ke localhost tidak melewati NIC fisik; ia diputar balik di jalur loopback internal OS. Karena itu, penangkapan biasa yang menargetkan adaptor fisik tidak pernah menampilkannya dari awal. Di Wireshark, pilih "Adapter for loopback traffic capture" yang disediakan Npcap untuk mengambil lalu lintas loopback. pktmon mengambil di dalam tumpukan jaringan, sehingga juga dapat dipakai untuk mengamati lalu lintas loopback. Kekeliruan lain yang sering terjadi: "localhost" diselesaikan 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?

Isi data aplikasi terenkripsi dan tidak terlihat. Namun "kerangka" percakapan — pembentukan dan pemutusan sambungan TCP, apakah jabat tangan TLS berhasil, pemutusan oleh RST, sisi mana yang berhenti merespons — tetap dapat diketahui meski terenkripsi, sehingga sebagian besar penyelidikan timeout dapat dilanjutkan dengan TLS dibiarkan terenkripsi. Jika isi juga diperlukan, ada cara dekripsi lewat SSLKEYLOGFILE, tetapi yang didukung hanya sebagian implementasi TLS seperti Firefox dan keluarga Chrome; SChannel bawaan Windows tidak didukung. Mekanismenya menuliskan informasi kunci rahasia, jadi bahkan jika dipakai, anggap itu terbatas pada lingkungan pengembangan.

Amankah mengirim berkas penangkapan ke meja dukungan di luar perusahaan?

Mengirimnya apa adanya berbahaya. Penangkapan berisi isi komunikasi itu sendiri, dan bisa mencakup kredensial protokol teks biasa, Cookie, kunci API, dan data pribadi. Pertama, pada tahap pengambilan, persempit filter dan jendela waktu ke minimum yang diperlukan, dan sebelum menyerahkannya, ekstrak hanya percakapan sasaran dengan filter tampilan Wireshark lalu ekspor. Isi yang masih tersisa sebaiknya diserahkan setelah disepakati dengan penerima cara menangani bagian rahasia (penyembunyian, atau penyediaan lewat cara lain). Masa simpan dan penghapusan berkas pengambilan juga sebaiknya diputuskan lebih dulu.

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.