ike-scan tidak menerima respons daripada get laluan IPsec yang berfungsi

Get laluan itu melayani telefon dan komputer riba setiap hari, namun ike-scan melaporkan tiada hos yang membalas. Output itu terbaca seperti bukti bahawa IPsec tiada pada peranti. Biasanya ia bermaksud peranti membuang setiap cadangan dalam prob dan memilih untuk tidak menjawab apa-apa. Kesenyapan juga satu respons, dan ia ialah respons paling kurang maklumat yang alat ini boleh berikan kepada anda.

Telusuri tiga soalan berasingan: adakah paket tiba, adakah mana-mana cadangan sepadan, dan adakah sesuatu yang lain menolak rakan sebaya?

Langkah 1: baca cadangan yang dihantar oleh alat

Mod utama bermula dengan muatan SA yang menyenaraikan transformasi yang akan diterima oleh pemula, dan ike-scan mengisi senarai itu daripada lalai yang dikompil. Set lalai itu sengaja lama: DES dan 3DES untuk penyulitan, MD5 dan SHA1 untuk pencincangan, kumpulan 1 dan 2 untuk pertukaran kunci, kunci pra-kongsi untuk pengesahan. Tiada AES, tiada SHA-2, tiada kumpulan 14. Get laluan yang dikonfigurasikan untuk AES-256 dengan SHA-256 dan modp2048 tidak berkongsi apa-apa dengannya.

Sesetengah pelaksanaan menjawab prob yang tidak sepadan dengan pemberitahuan NO-PROPOSAL-CHOSEN. Yang lain hanya membuangnya, yang biasa pada perkakas yang menganggap rakan sebaya tidak dikenali sebagai bunyi bising. Sama ada cara, imbasan tidak mencetak apa-apa, dan tiada itu sama dengan rupa UDP 500 yang ditapis dari luar, seperti yang dokumentasi projek ike-scan jelaskan tentang set lalai.

Langkah 2: tawarkan satu cadangan moden

Gantikan set lalai dengan --trans. Bentuk atribut mengambil nombor atribut IKE secara langsung: 1 untuk penyulitan, 2 untuk cincang, 3 untuk pengesahan, 4 untuk kumpulan dan 14 untuk panjang kunci apabila algoritma mengambilnya. Yang keluar ialah satu baris yang boleh anda baca dengan kuat dalam semakan perubahan.

Bentuk kedudukan membawa nilai yang sama mengikut urutan dan mengelakkan kurungan, yang penting apabila arahan bergerak melalui shell.

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

Satu cadangan bagi setiap paket adalah perlahan apabila anda menyenaraikan, jadi gelung melalui nilai yang munasabah: penyulitan 5, 7/128, 7/192, 7/256; cincang 1, 2, 5, 6, 7; kumpulan 1, 2, 5, 14, 15, 19, 20, 21; pengesahan 1 untuk kunci pra-kongsi dan 3 untuk tandatangan RSA. Cetak setiap arahan sebelum menjalankannya supaya transkrip menunjukkan apa yang ditawarkan dan dalam urutan apa.

Langkah 3: tafsirkan balasan

Balasan membuktikan tepat dua perkara: pengesah IKE boleh dicapai pada alamat itu, dan satu cadangan yang ditawarkan boleh diterima. Ia tidak menyatakan apa-apa tentang kunci pra-kongsi, lapisan L2TP atau sama ada akaun pengguna wujud. Imbasan yang berjaya sama sekali serasi dengan kegagalan setiap peringkat seterusnya.

Pada get laluan yang anda kendalikan, inilah bahagian yang benar-benar berguna. Imbasan memberitahu anda cadangan mana yang masih diterima oleh peranti, dan hasil yang terhad kepada transformasi legasi ialah penemuan tentang dasar peranti, bukan alasan untuk melemahkan klien.

Langkah 4: tafsirkan kesenyapan

Kesenyapan ialah bukti yang lebih lemah daripada rupanya. Setiap cadangan mungkin telah ditolak, UDP 500 dan 4500 mungkin ditapis, sumber mungkin dihadkan kadarnya selepas semburan, atau perkhidmatan mungkin mendengar pada alamat yang berbeza daripada yang anda imbas. Bandingkan log IKE get laluan dengan klien yang sudah bersambung menggunakan kelayakan yang sah sebelum anda membuat kesimpulan tentang kotak itu.

Tingkah laku semburan termasuk dalam senarai itu kerana penghitungan menghasilkan banyak paket dalam tetingkap pendek. Get laluan yang menjawab percubaan pertama dan kemudian senyap sedang menerangkan dasar anti-DoSnya, bukan set cadangannya.

Langkah 5: catat apa yang anda buktikan

Tulis gabungan yang diterima di sebelah versi firmware, kemudian bandingkan dengan transformasi yang ditawarkan secara lalai oleh klien yang anda pedulikan. Jurang antara kedua-dua senarai itu ialah masalah konfigurasi, dan imbasan hanya menjadikannya kelihatan. Jika satu-satunya cadangan yang diterima ialah yang anda tidak akan pilih, pembetulan itu terletak pada dasar get laluan atau profil klien, tidak pernah pada prob.

Prob yang tidak pernah menjawab tetap menjawab sesuatu: ia menunjukkan cadangan mana yang peranti ini sanggup bincangkan, dan mana yang lebih suka dilepaskan ke lantai.