Kehilangan Ping di VPN: kelompokkan permintaan Echo sebelum persentase

Sebuah tangkapan berisi enam permintaan Echo dan tiga balasan, dan seseorang menulis kehilangan paket 50 persen di tiket. Angka itu bisa benar untuk tangkapan dan salah untuk terowongan. Keenam permintaan itu mungkin milik dua percakapan berbeda dengan dua kontrak pengiriman berbeda. Kelompokkan sebelum membagi, dan rasio berhenti menjadi bagian menarik dari laporan.

Langkah 1: pisahkan aliran berdasarkan sumber dan tujuan

Permintaan Echo membawa sumber dan tujuan, dan kedua bidang itu menentukan percakapan mana yang diikutinya. Probe yang dibuat oleh gateway memakai alamat terowongan gateway, sedangkan probe yang diteruskan atas nama host LAN mempertahankan alamat host itu. Sisi jauh mungkin memiliki rute balik untuk yang satu dan tidak untuk yang lain, sehingga kedua kelompok berperilaku berbeda karena alasan yang tidak ada hubungannya dengan terowongan.

Pisahkan tangkapan pada bidang itu sebelum menghitung apa pun, dan pertahankan tujuan sebagai bagian dari kunci. Dua aliran ke peer berbeda tidak sebanding meski berbagi sumber.

Catat kelompok beserta jumlahnya, karena langkah berikutnya menentukan balasan mana milik kelompok mana. Kelompok dengan tiga permintaan dan tanpa balasan yang cocok adalah temuan. Kelompok dengan tiga permintaan dan tiga balasan adalah garis dasar.

Langkah 2: cocokkan pada pengenal dan urutan

Format Echo dalam RFC 792 membawa pengenal dan nomor urut, dan memperlakukan keduanya sebagai bidang yang memasangkan balasan dengan permintaannya. Keduanya diperlukan untuk tugas itu. Nomor urut saja tidak unik, karena pengirim atau proses berbeda dapat memakai ulang nilai yang sama dalam satu jendela tangkapan. Pengenal mempersempit pengirim dan urutan mempersempit posisi, dan pasangan itu bersama-sama yang membuat kecocokan dapat dipertahankan.

Balasan membalik arah alamat permintaannya, jadi kecocokan adalah pasangan permintaan-balasan, bukan dua tuple identik. Bandingkan sumber permintaan dengan tujuan balasan dan tujuan permintaan dengan sumber balasan, lalu pastikan pengenal dan urutannya setuju.

Pertahankan juga jendela pengamatan, karena tangkapan panjang dapat memuat pemakaian ulang yang sah atas kedua bidang. Memangkas jendela menjadi satu semburan menghilangkan sebagian besar ambiguitas itu. Ini juga membuat hitungan dapat direproduksi oleh siapa pun yang membaca tiket.

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

Langkah 3: bandingkan tuple pada batas yang sama

Jika terjemahan alamat jaringan berada di antara titik tangkapan dan peer, alamat dalam permintaan dan balasan akan berbeda secara desain. Bandingkan tuple pada satu batas, atau bawa pemetaannya secara eksplisit agar selisihnya diperhitungkan. Mencampur permintaan sebelum terjemahan dengan balasan setelah terjemahan menciptakan ketidakcocokan yang tidak pernah ada di kabel.

Tentukan batas sebelum mulai menghitung, dan nyatakan dalam laporan agar orang berikutnya dapat mereproduksi pengelompokan. Satu tangkapan di sisi klien dan satu lagi di sisi server adalah dua batas berbeda. Masing-masing menjawab pertanyaan berbeda tentang ke mana balasan menghilang.

Kelompok probe yang diterjemahkan juga mewarisi status perangkat terjemahan itu sendiri, yang bisa menjadi alasan sebenarnya balasan tidak pernah tiba. Periksa status itu sebelum menyalahkan jalur di baliknya.

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

Langkah 4: nyatakan apa yang dapat dan tidak dapat dibuktikan tangkapan

Celah yang teramati tidak membuktikan bahwa host jauh tetap diam. Titik tangkapan mungkin hanya melihat satu arah, filter dapat membuang balasan, atau buffer dapat meluap selama jendela. Masing-masing menghasilkan ketiadaan yang sama dan kesimpulan yang berbeda.

Catat lokasi tangkapan, ekspresi filter, dan penghitung buang bersama hitungan, karena rasio tanpa itu tidak dapat diaudit. Ketiga baris itulah yang membuat angka dapat dipertahankan nanti.

Lalu pisahkan apa yang ditetapkan pengamatan dari apa yang disarankannya, dalam dua kalimat alih-alih satu. Kalimat pertama menyatakan hitungan dan batasnya. Kalimat kedua menyatakan hipotesis dan apa yang akan mengonfirmasinya.

Ketika pertanyaannya apakah rute tertentu membuang paket, probe terkendali dengan alamat sumber eksplisit adalah bukti lebih kuat daripada hitungan pasif lalu lintas campuran. Kirim dari mesin yang sama, pada waktu yang sama, ke peer yang sama. Ubah satu variabel dan perbandingannya tetap berlaku.

Laporkan kelompok dan batas berikutnya

Laporan memiliki tiga baris: definisi kelompok, hitungan yang cocok di dalam tiap kelompok, dan batas tempat perbandingan dibuat. Pembaca lalu dapat melihat bahwa satu kelompok menjawab lengkap dan yang lain tidak, yang menunjuk ke rute atau izin alih-alih ke kehilangan acak.

Lampirkan berkas tangkapan dan ekspresi filter agar pengelompokan dapat direproduksi. Ringkasan tanpa berkas adalah pernyataan, bukan hasil.

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

Ketika satu kelompok menunjukkan lima balasan dan yang lain tidak sama sekali, temuannya adalah satu sumber punya rute balik yang berfungsi dan yang lain tidak. Itu tiket yang jauh lebih baik daripada persentase campuran, dan itu mengarahkan pemeriksaan berikutnya ke rute balik alih-alih ke instans VPN yang tidak terkait.