ESP mendekripsi dengan baik dan paket dalam tetap tidak sampai ke mana pun

Penghitung penerimaan ESP naik, terowongan tetap hidup, dan aplikasi tidak pernah melihat paketnya. Dekripsi berjalan, verifikasi integritas lolos, lalu penerima harus memutuskan apa sebenarnya muatan yang dilindungi itu. Pada langkah terakhir itulah ketidakcocokan format muncul, dan dari luar sama sekali tidak terlihat seperti masalah firewall.

Apa yang Anda lihat ketika labelnya berbohong

Tidak ada apa pun di log klien yang membedakannya dari lubang hitam perutean. Keduanya menghasilkan waktu tunggu aplikasi di samping terowongan yang sehat, karena itulah penghitung yang pertama disalahkan.

Penghitung penerimaan yang naik benar-benar kabar baik: paket datang dan terautentikasi. Itu bukan bukti bahwa paket dalam masuk akal bagi apa pun di atas lapisan kripto.

Tipenya tinggal di trailer

Dalam mode terowongan IPsec biasa, muatan yang dilindungi ESP berisi paket IP dalam yang lengkap. Field header berikutnya di trailer menentukan apa muatan itu, dan itu bukan port TCP, bukan nomor protokol di header luar, dan bukan bagian dari field SPI serta nomor urut awal. RFC 4303 bagian 2.6 mendefinisikannya sebagai field tipe muatan, yang merupakan nama tepat untuk tugas yang tepat.

Nilai yang akan Anda temui kecil dan layak diingat: IPv4 adalah 4 (0x04) dan IPv6 adalah 41 (0x29).

Angka-angka itu berasal dari penetapan nomor protokol IANA, bukan dari kebiasaan lokal. Pengirim yang menyatakan IPv4 sementara membungkus paket IPv6 telah menghasilkan ketidaksesuaian format, dan tidak ada aturan firewall yang memperbaiki bita yang bertentangan dengan labelnya sendiri.

Cara membedakannya dari tersangka biasa

Sebagian besar paket yang hilang bukan cacat pengodean. Periksa selektor lebih dulu, karena selektor lalu lintas yang mengecualikan prefiks IPv6 membuang lalu lintas sebelum apa pun dienkapsulasi. Lalu periksa perutean, kemudian penyaringan lokal di host penerima. Hanya setelah itu dikesampingkan, ketidakcocokan format muatan menjadi penjelasan yang masuk akal.

Tangkapan terenkripsi tidak akan menyelesaikannya, karena header berikutnya yang dilindungi berada di dalam muatan terenkripsi. Anda perlu diagnostik implementasi atau titik pengamatan terdekripsi yang didukung, dan keduanya memerlukan izin sebelum digunakan.

Jika tidak ada yang bisa menghasilkan bukti itu, Anda tidak punya bug format. Anda punya teori, dan selektor tetap menjadi taruhan yang lebih baik.

Apa yang bukan perbaikan

Jangan mematikan pemeriksaan integritas agar lalu lintas lolos. Jangan menulis ulang paket terenkripsi di router perantara, karena itu tidak bisa berhasil dan akan merusak aliran sementara terlihat membantu dalam tangkapan. Jangan membuka aturan firewall aplikasi yang lebih lebar dengan teori bahwa sebuah port diblokir. Tidak satu pun dari itu menyentuh ketidakcocokan label.

Jika ketidakcocokan yang terkonfirmasi berasal dari implementasi rekan, simpan reproduksi minimal yang sudah dibersihkan dan bawa ke saluran dukungan implementasi tersebut.

Verifikasi alirannya, bukan penghitungnya

Setelah koreksi, uji aliran IPv6 sebenarnya dari ujung ke ujung: permintaan aplikasi melalui terowongan, balasannya, dan pasangan alamat yang diamati tiap sisi. Penghitung ESP yang naik hanya membuktikan paket diterima dan terautentikasi. Itu tidak mengatakan apa pun tentang apakah paket dalam dapat digunakan.

Catat kedua hasil di tiket. Pergerakan penghitung plus aliran yang berfungsi adalah perbaikan; pergerakan penghitung saja persis seperti yang Anda miliki sebelum memulai.