Pengambilan paket jaringan banyak digunakan dalam skenario seperti pemecahan masalah dan audit keamanan. Topik ini menjelaskan masalah umum yang mungkin Anda temui saat menggunakan tcpdump atau Wireshark untuk pengambilan paket, serta cara menyelesaikannya.
Latar Belakang
tcpdump dan Wireshark adalah alat analisis protokol jaringan yang kuat. Wireshark mendukung sebagian besar sistem operasi utama, termasuk Linux, Windows, dan macOS. Biasanya, Instance Linux di lingkungan cloud tidak memiliki antarmuka pengguna grafis (GUI) terpasang secara default. Oleh karena itu, ketika Anda perlu menangkap paket jaringan pada Instance Linux di lingkungan cloud, kami merekomendasikan menggunakan alat tcpdump. Untuk informasi lebih lanjut tentang cara menginstal dan menggunakan kedua alat tersebut, lihat Gunakan Alat Pengambilan Paket untuk Menangkap Paket Jaringan.
Pesan tcpdump umum dan solusi
[Ukuran paket dibatasi selama pengambilan]
Masalah: Seperti ditunjukkan pada gambar berikut, paket tersebut memiliki panjang 171 byte, tetapi hanya 96 byte pertama yang ditangkap.
Kemungkinan Penyebab: Pesan ini menunjukkan bahwa paket lengkap tidak ditangkap. Hal ini biasanya terjadi karena pengaturan default dari alat pengambilan paket.
Solusi: Di beberapa sistem operasi, tcpdump hanya menangkap 96 byte pertama dari setiap frame secara default. Anda dapat menggunakan parameter -s untuk menentukan jumlah byte yang akan ditangkap. Berikut adalah contoh perintah:
sudo tcpdump -i eth0 -s 1000 -w tcpdump.capPesan Wireshark umum dan solusi
[Segmen TCP sebelumnya tidak ditangkap]
Masalah: Kehilangan paket atau paket yang terlewat terjadi selama pengambilan paket. Gambar berikut menunjukkan sebuah contoh.
Kemungkinan Penyebab: Pesan ini menunjukkan bahwa segmen TCP sebelumnya tidak ditangkap dan segmen data yang ditangkap tidak lengkap. Hal ini biasanya disebabkan oleh kehilangan paket atau paket yang terlewat oleh alat pengambilan.
Solusi: Analisis hasil pengambilan paket berdasarkan contoh di atas untuk menentukan situasi spesifik.
Selama transmisi data menggunakan protokol TCP, segmen data yang dikirim dari host yang sama harus berurutan. Secara khusus, Seq dari segmen data berikutnya harus sama dengan Seq dari segmen data sebelumnya ditambah panjang muatan data (yaitu Seq + Len - panjang Header TCP), dan nilai bidang Ack penerima sama dengan Seq dari segmen data pengirim ditambah panjang muatan data, yang menunjukkan nomor urut byte berikutnya yang diharapkan diterima (kecuali dalam skenario jabat tangan tiga arah atau jabat tangan empat arah). Jika Seq dari segmen data berikutnya lebih besar dari Seq dari yang sebelumnya ditambah panjang muatan data, dan tidak ada segmen data perantara yang diamati, maka situasi berikut mungkin ada:
Pengambilan paket yang terlewat (Segmen TCP sebelumnya tidak tertangkap): Jika
Ackberikutnya menyertakan rentangSeqyang tidak tertangkap (misalnya, pengirim mengirimkanSeq=1000danSeq=2000, dan penerima mengembalikanAck=2000), hal ini menunjukkan bahwa data perantara telah diakui oleh penerima, tetapi alat pengambilan melewatkannya.Kehilangan paket: Jika
Ackberikutnya tidak mencakup rentangSeqyang terlewat (misalnya, pengirim mengirimkanSeq=1000danSeq=2000, dan penerima mengembalikanAck=1000), hal ini mengindikasikan bahwa data perantara belum diakui oleh penerima, dan kehilangan paket mungkin telah terjadi.Segmen data dalam jaringan mungkin tidak berurutan (segmen kemudian tiba sebelum segmen awal). Dalam hal ini, penerima akan mengakui berulang kali
Ackyang berkelanjutan yang telah diterima melaluiSeqsampai segmen yang hilang diterima.
Logika pemrosesan untuk segmen luar urutan dan mekanisme jendela adalah sebagai berikut:
Jika segmen data
Seqmelebihi rentang jendela penerima (Window), penerima akan membuang segmen tersebut, dan pemulihan akan bergantung pada mekanisme retransmisi timeout atau retransmisi cepat.Jika segmen data Seq melebihi rentang jendela penerima (Window), penerima akan membuang segmen tersebut, dan pemulihan akan bergantung pada mekanisme retransmisi timeout atau retransmisi cepat.
[TCP ACKed unseen segment]
Masalah: Pesan [TCP ACKed unseen segment] muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.

Kemungkinan Penyebab: Pesan ini menunjukkan bahwa paket yang di-ACK tidak ditangkap. Menurut informasi di baris 32 pada gambar di atas, nilai nomor urut (Seq) ditambah panjang (Len) adalah 6889 ditambah 1448, yang sama dengan 8337. Diharapkan nomor urut paket berikutnya dari server adalah 8337. Namun, baris 35 menunjukkan nomor urut 11233, yang menunjukkan bahwa informasi antara 8337 dan 11232 tidak ditangkap. Hanya paket pengakuan berikutnya yang ditangkap, tetapi paket data sebelumnya tidak. Informasi antara 8337 dan 11232 seharusnya muncul sebelum baris 34.
Solusi: Ini mungkin pesan Wireshark yang paling umum. Anda perlu menganalisis hasil pengambilan paket berdasarkan contoh di atas untuk menentukan situasi spesifik.
[TCP Out-of-Order]
Masalah: Pesan [TCP Out-of-Order] muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.

Kemungkinan Penyebab: Pesan ini menunjukkan bahwa paket data tidak berurutan. Ketika Wireshark mendeteksi bahwa Seq dari paket berikutnya lebih kecil dari Seq ditambah Len dari paket sebelumnya, itu dianggap tidak berurutan. Rentang kecil dari paket tidak berurutan memiliki sedikit dampak, seperti ketika urutan asli 1, 2, 3, 4, 5 menjadi kacau menjadi 2, 1, 3, 4, 5. Namun, rentang besar dapat memicu retransmisi cepat. Misalnya, jika urutan menjadi kacau menjadi 2, 3, 4, 5, 1, itu akan memicu cukup "Dup ACK" untuk menyebabkan retransmisi paket.
Solusi: Analisis hasil pengambilan paket berdasarkan contoh di atas. Paket tidak berurutan dengan rentang kecil sesekali dapat diabaikan. Namun, jika paket tidak berurutan dengan rentang besar sering terjadi, Anda dapat menggunakan alat seperti MTR untuk analisis dan pemecahan masalah lebih lanjut, atau periksa log perangkat perantara seperti switch dan router untuk analisis lebih lanjut.
[TCP Dup ACK]
Masalah: Pesan [TCP Dup ACK] muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.

Kemungkinan Penyebab: Pesan ini menunjukkan bahwa ACK duplikat telah terjadi. Ketika paket tidak berurutan atau kehilangan paket terjadi, penerima menerima paket dengan nilai Seq lebih besar dari yang diharapkan. Untuk setiap paket semacam itu yang diterima, penerima merespons dengan nilai Seq yang diharapkan untuk mengingatkan pengirim, sehingga menghasilkan ACK duplikat.
Solusi: Jika situasi ini sering terjadi, Anda dapat menggunakan alat seperti MTR untuk analisis dan pemecahan masalah lebih lanjut, atau periksa log perangkat perantara seperti switch dan router untuk analisis lebih lanjut.
[TCP Retransmission]
Masalah: Pesan [TCP Retransmission] muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.

Kemungkinan Penyebab: Pesan ini menunjukkan bahwa paket data sedang diretransmisi. Jika paket hilang dan tidak ada paket berikutnya yang dapat memicu "Dup ACK" di penerima, retransmisi cepat tidak akan terjadi. Dalam hal ini, pengirim hanya bisa menunggu retransmisi timeout. Seperti ditunjukkan pada gambar di atas, klien mengirimkan paket asli nomor 1053 dan terus menunggu ACK yang sesuai. Ia harus mere-transmit paket 1225 setelah lebih dari 100 milidetik.
Solusi: Jika situasi ini sering terjadi, Anda dapat menggunakan alat seperti MTR untuk analisis dan pemecahan masalah lebih lanjut, atau periksa log perangkat perantara seperti switch dan router untuk analisis lebih lanjut.
TCP menyediakan transmisi yang andal dengan menyetel timer saat mengirim data untuk mengatasi masalah pengakuan paket. Jika tidak ada pengakuan yang diterima ketika timer habis, ia akan mentransmisikan ulang data. Mengenai bagaimana waktu retransmisi dihitung, RFC2988 memberikan solusi yang masih digunakan Linux hingga hari ini. Untuk informasi lebih rinci, lihat bagian RTT dan RTO dalam dokumentasi TCP-IP.
[TCP Fast Retransmission]
Masalah: Pesan [TCP Fast Retransmission] muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.

Kemungkinan Penyebab: Pesan ini menunjukkan bahwa paket data sedang diretransmisi dengan cepat. Ketika pengirim menerima tiga atau lebih pesan "TCP Dup ACK", ia menyadari bahwa paket yang sebelumnya dikirim mungkin telah hilang dan memulai retransmisi cepat. Seperti ditunjukkan pada gambar di atas, ketika server menerima tiga pesan "TCP Dup ACK", ia mere-transmit paket 1177 dengan Seq sama dengan 991851.
Solusi: Jika situasi ini sering terjadi, Anda dapat menggunakan alat seperti MTR untuk analisis dan pemecahan masalah lebih lanjut, atau periksa log perangkat perantara seperti switch dan router untuk analisis lebih lanjut.
Mekanisme retransmisi cepat mengimplementasikan standar lain untuk penilaian kehilangan paket. Ketika penerima menerima tiga pengakuan duplikat berturut-turut, pengirim tidak perlu menunggu timer retransmisi habis dan dapat mere-transmit segmen yang belum diakui lebih awal.
[TCP zerowindow]
Masalah: Pesan [TCP zerowindow] muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.

Kemungkinan Penyebab: Pesan ini menunjukkan bahwa jendela penerima adalah 0, buffer penuh, dan tidak akan menerima data lagi. "win=" menunjukkan berapa banyak ruang buffer yang tersedia bagi pengirim paket ini untuk menerima data. "Win=0" menunjukkan bahwa buffer penuh, memberi tahu pihak lain bahwa ia tidak akan lagi menerima data, seperti ditunjukkan pada gambar di atas.
Solusi: Penyebab potensial dari masalah ini termasuk kapasitas pemrosesan yang tidak mencukupi di sisi penerima atau sumber daya lebar pita jaringan yang tidak mencukupi. Analisis lebih lanjut diperlukan untuk mengidentifikasi penyebab spesifik.
[TCP window Full]
Masalah: Pesan [TCP window Full] muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.
Kemungkinan Penyebab: Pesan ini menunjukkan bahwa jendela pengiriman penuh. Seperti ditunjukkan pada gambar di atas, itu menunjukkan bahwa pengirim paket telah menghabiskan jendela penerima yang dinyatakan oleh pihak lain dan tidak dapat mengirim lebih banyak data untuk sementara waktu.
Solusi: Penyebab potensial dari masalah ini termasuk kapasitas pemrosesan yang tidak mencukupi di sisi penerima atau sumber daya lebar pita jaringan yang tidak mencukupi. Analisis lebih lanjut diperlukan untuk mengidentifikasi penyebab spesifik.
Byte dalam penerbangan sama dengan jendela penerima pihak lain, yang menunjukkan bahwa nilai yang dikirim oleh pengirim dikurangi nilai pengakuan terbaru oleh pihak lain sama dengan berapa banyak nilai yang telah diakui. Artinya, Seq ditambah Len sama dengan Ack, yang merupakan Ack terbaru. Dua bidang berikut menunjukkan bahwa transmisi telah dihentikan dan harus diperhatikan.
Byte dalam penerbangan sama dengan jendela penerima penerima, yang menunjukkan bahwa jumlah byte yang dikirim oleh pengirim dikurangi jumlah byte yang baru saja diakui oleh penerima sama dengan jumlah byte yang diakui. Artinya, Seq ditambah Len sama dengan Ack, yang merupakan Ack terbaru. Dua bidang berikut menunjukkan bahwa transmisi telah dihentikan dan harus diberi perhatian tinggi.
[TCP segment of a reassembled PDU]
Masalah: Pesan [TCP segment of a reassembled PDU] muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.

Kemungkinan Penyebab: Pesan ini menunjukkan segmen protokol TCP dari PDU yang dirakit ulang. Ini menunjukkan bahwa Wireshark dapat secara virtual mengelompokkan paket TCP yang termasuk dalam PDU lapisan aplikasi yang sama.
Solusi: Anda perlu mengonfigurasi perangkat lunak dengan memilih Edit > Preferences > Protocol > TCP, dan memastikan bahwa "Allow sub dissector to reassemble TCP streams" diaktifkan. Nomor paket konfirmasi ACK sama.

[Continuation to #X]
Masalah: Pesan [Continuation to #X] muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.

Kemungkinan Penyebab: Pesan ini menunjukkan bahwa "Allow sub dissector to reassemble TCP streams" dinonaktifkan. Aktifkan sesuai dengan situasi aktual Anda.
Solusi: Anda perlu mengonfigurasi perangkat lunak dengan memilih Edit > Preferences > Protocol > TCP, dan memastikan bahwa "Allow sub dissector to reassemble TCP streams" diaktifkan.

Time-to-live exceeded (Fragment reassembly time exceeded)
Masalah: Pesan Time-to-live exceeded (Fragment reassembly time exceeded) muncul selama pengambilan paket, seperti ditunjukkan pada gambar berikut.
Kemungkinan Penyebab: Pesan ini menunjukkan bahwa Time-to-Live (TTL) telah dilampaui, khususnya bahwa waktu reassembly fragmen telah dilampaui. Ini menunjukkan bahwa pengirim paket ini sebelumnya menerima beberapa fragmen tetapi tidak dapat merakitnya kembali karena suatu alasan. Seperti ditunjukkan pada gambar di atas, karena beberapa paket dari Shanghai ke Beijing dikirim dalam fragmen, dan beberapa hilang dalam perjalanan, Beijing tidak dapat merakitnya kembali dan harus menggunakan kesalahan ICMP ini untuk memberi tahu pihak lain.
Solusi: Jika masalah ini berlangsung lama, Anda dapat menyelesaikannya dengan memeriksa tabel routing, menggunakan alat MTR untuk menganalisis loop jaringan, menyesuaikan nilai TTL awal, menyesuaikan MTU, atau mengoptimalkan lebar pita jaringan.
Referensi
Untuk informasi lebih lanjut tentang Wireshark, lihat Dokumentasi Resmi Wireshark.
Untuk informasi lebih lanjut tentang cara menggunakan alat pengambilan paket, lihat Gunakan Alat Pengambilan Paket untuk Menangkap Paket Jaringan.
Untuk informasi lebih lanjut tentang cara memecahkan masalah di mana Anda dapat melakukan ping ke instance tetapi tidak dapat terhubung ke portnya, lihat Metode Pemecahan Masalah untuk Masalah di Mana Anda Dapat Melakukan Ping ke Instance ECS Tetapi Tidak Dapat Terhubung ke Portnya.
Untuk informasi lebih lanjut tentang cara menggunakan alat MTR untuk menganalisis tautan jaringan, lihat Gunakan Alat MTR untuk Menganalisis Tautan Jaringan.