ike-scan tidak mendapat respons dari gateway IPsec yang berfungsi

Gateway itu melayani ponsel dan laptop setiap hari, tetapi ike-scan melaporkan tidak ada host yang merespons. Keluaran itu terbaca seperti bukti bahwa IPsec tidak ada di perangkat. Biasanya ini berarti perangkat membuang setiap proposal dalam probe dan memilih untuk tidak menjawab apa pun. Keheningan adalah respons, dan itulah respons paling tidak informatif yang bisa diberikan alat ini.

Telusuri tiga pertanyaan terpisah: apakah paket tiba, apakah ada proposal yang cocok, dan apakah ada hal lain yang menolak peer?

Langkah 1: baca proposal yang dikirim alat

Mode utama dimulai dengan payload SA yang mencantumkan transformasi yang akan diterima inisiator, dan ike-scan mengisi daftar itu dari bawaan hasil kompilasi. Kumpulan bawaannya sengaja dibuat tua: DES dan 3DES untuk enkripsi, MD5 dan SHA1 untuk hashing, grup 1 dan 2 untuk pertukaran kunci, kunci pra-bagi untuk autentikasi. Tidak ada AES, tidak ada SHA-2, tidak ada grup 14. Gateway yang dikonfigurasi untuk AES-256 dengan SHA-256 dan modp2048 tidak berbagi apa pun dengannya.

Beberapa implementasi menjawab probe yang tidak cocok dengan notifikasi NO-PROPOSAL-CHOSEN. Yang lain membuangnya begitu saja, yang lazim pada perangkat yang menganggap peer tak dikenal sebagai kebisingan. Bagaimanapun, pemindaian tidak mencetak apa pun, dan ketiadaan itu identik dengan tampilan UDP 500 yang difilter dari luar, sebagaimana dokumentasi proyek ike-scan menjelaskan tentang kumpulan bawaan.

Langkah 2: tawarkan satu proposal modern

Ganti kumpulan bawaan dengan --trans. Bentuk atribut mengambil nomor atribut IKE secara langsung: 1 untuk enkripsi, 2 untuk hash, 3 untuk autentikasi, 4 untuk grup, dan 14 untuk panjang kunci bila algoritme memerlukannya. Hasilnya adalah satu baris yang bisa Anda baca keras dalam tinjauan perubahan.

Bentuk posisional membawa nilai yang sama secara berurutan dan menghindari tanda kurung, yang penting begitu perintah melewati shell.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

Satu proposal per paket lambat saat Anda melakukan enumerasi, jadi ulangi untuk nilai-nilai yang masuk akal: enkripsi 5, 7/128, 7/192, 7/256; hash 1, 2, 5, 6, 7; grup 1, 2, 5, 14, 15, 19, 20, 21; autentikasi 1 untuk kunci pra-bagi dan 3 untuk tanda tangan RSA. Cetak setiap perintah sebelum menjalankannya agar transkrip menunjukkan apa yang ditawarkan dan dalam urutan apa.

Langkah 3: tafsirkan balasan

Balasan membuktikan tepat dua hal: ada responder IKE yang dapat dijangkau di alamat itu, dan satu proposal yang ditawarkan dapat diterima. Balasan itu tidak mengatakan apa pun tentang kunci pra-bagi, lapisan L2TP, atau apakah akun pengguna ada. Pemindaian yang berhasil sepenuhnya kompatibel dengan kegagalan setiap tahap berikutnya.

Pada gateway yang Anda kelola, inilah bagian yang benar-benar berguna. Pemindaian memberi tahu proposal mana yang masih diterima perangkat, dan hasil yang terbatas pada transformasi lama adalah temuan tentang kebijakan perangkat, bukan alasan untuk melemahkan klien.

Langkah 4: tafsirkan keheningan

Keheningan adalah bukti yang lebih lemah daripada tampilannya. Setiap proposal mungkin ditolak, UDP 500 dan 4500 mungkin difilter, sumber mungkin dibatasi lajunya setelah semburan, atau layanan mungkin mendengarkan di alamat yang berbeda dari yang Anda pindai. Bandingkan log IKE gateway dengan klien yang sudah terhubung memakai kredensial valid sebelum Anda menyimpulkan apa pun tentang kotak itu.

Perilaku semburan masuk dalam daftar itu karena enumerasi menghasilkan banyak paket dalam jendela singkat. Gateway yang menjawab percobaan pertama lalu diam sedang menjelaskan kebijakan anti-DoS-nya, bukan kumpulan proposalnya.

Langkah 5: catat apa yang Anda buktikan

Tulis kombinasi yang diterima di samping versi firmware, lalu bandingkan dengan transformasi yang ditawarkan klien yang Anda pedulikan secara bawaan. Celah antara kedua daftar itulah masalah konfigurasi, dan pemindaian hanya membuatnya terlihat. Jika satu-satunya proposal yang diterima adalah yang tidak akan Anda pilih, perbaikannya ada di kebijakan gateway atau di profil klien, tidak pernah di probe.

Probe yang tidak pernah menjawab tetap menjawab sesuatu: ia menunjukkan proposal mana yang bersedia dibahas perangkat ini, dan mana yang lebih suka dibuangnya.