Saat IKEv2 mengembalikan TS_UNACCEPTABLE, bandingkan subnet sebenarnya

Baca TS_UNACCEPTABLE sebagai ketidaksepakatan cakupan, bukan sebagai profil rusak. Gateway mengatakan bahwa kedua peer tidak dapat menyepakati alamat mana yang boleh dibawa terowongan ini. IKE SA bisa saja sudah aktif pada saat itu, karena itulah klien bisa tampak terhubung tanpa SA anak di belakangnya. Setelah dibingkai begitu, pekerjaannya menjadi mekanis. Tuliskan prefiks yang dimaksudkan kedua sisi, bandingkan dalam satu arah, dan sempitkan sampai keduanya beririsan.

Tulis dulu pasangan yang dimaksudkan

Sebelum menyentuh konfigurasi, daftarkan empat nilai: rentang sumber penginisiasi, rentang tujuannya, dan pasangan yang sama dilihat dari pihak penjawab. Catat juga keluarga alamat masing-masing. Rentang IPv4 dan rentang IPv6 adalah jenis pemilih yang berbeda, dan tidak ada yang bisa dilipat ke dalam muatan yang lain.

Tambahkan batasan protokol atau port apa pun yang dibawa kebijakan. Aturan yang hanya mengizinkan TCP 445 ke server file menggambarkan himpunan yang lebih sempit daripada subnet tempat aturan itu berada. Jika itu Anda tinggalkan dari catatan, hasil negosiasi akan tampak tidak konsisten karena alasan yang tidak Anda lihat.

Balik label sebelum membandingkannya

Lokal dan jarak jauh adalah label relatif. Prefiks lokal klien adalah rentang jarak jauh gateway, dan rentang lokal gateway adalah rentang jarak jauh klien. Karena itu tangkapan layar dari kedua ujung tidak pernah cocok, dan membandingkannya secara harfiah adalah cara biasa kehilangan satu sore.

Penjawab dapat menyempitkan tawaran ke subhimpunan yang dapat diterima alih-alih menolaknya. Hasil itu lebih buruk daripada kegagalan bersih, karena hanya bekerja separuh. Minta 10.0.0.0/16 ketika kebijakan mengizinkan 10.0.5.0/24, dan Anda bisa berakhir dengan SA anak yang hanya mencakup /24 itu. Satu host menjawab, semua yang lain berada di luar, dan tidak ada apa pun di klien yang mengatakannya. Baca pemilih yang diterima, bukan yang diminta, sebelum menyimpulkan negosiasi berhasil.

Profil road warrior yang meminta rute bawaan terus berdatangan di sini. Gateway yang dibangun untuk akses terpisah menyempitkan tawaran rentang penuh ke subnetnya sendiri, dan klien harus menerima hasil yang dipersempit atau gagal dengan lantang.

Baca penolakan dari satu percobaan

Kumpulkan kedua log dari percobaan koneksi yang sama. Profil tersimpan menunjukkan apa yang Anda konfigurasikan, bukan apa yang diusulkan, dan pada strongSwan swanctl --log mencetak notifikasi yang diterima bersama pemilih yang dibawanya.

Lalu periksa apa yang benar-benar terpasang. swanctl --list-sas menunjukkan pemilih SA anak, dan ip xfrm policy menunjukkan rentang yang sama sebagai entri kebijakan kernel. SA anak dalam daftar itu dengan pemilih yang tidak Anda maksudkan adalah peristiwa penyempitan; tidak ada SA anak ditambah TS_UNACCEPTABLE di log berarti penolakan.

Selagi di sana, pisahkan tetangga dekat. INVALID_SELECTORS mengeluh tentang pemilih di dalam SA anak yang sudah terbentuk, sedangkan INTERNAL_ADDRESS_FAILURE berarti penjawab tidak dapat mengalokasikan alamat virtual, yang merupakan masalah kumpulan, bukan masalah cakupan.

Periksa apa yang diam-diam mengecilkan himpunan

Tiga hal mengecilkan himpunan pemilih tanpa mengatakan apa pun. Kebijakan penjawab adalah yang pertama, melalui daftar subnet, aturan grup, atau otorisasi per pengguna yang mereduksi tawaran menjadi subhimpunan. Keluarga alamat adalah yang kedua: klien tumpukan ganda sering mengusulkan IPv6 bersama IPv4 dan mendapat penolakan untuk rentang yang tidak pernah dikonfigurasi gateway.

Batasan protokol dan port adalah yang ketiga. Di mana kebijakan hanya mengizinkan TCP 445, SA anak dapat naik sementara ICMP dan UDP tetap di luarnya, dan pengguna melaporkan terowongan rusak padahal hanya satu protokol yang pernah diizinkan.

Jadi memperlebar alamat saja tidak dapat memperbaiki kebijakan yang dibatasi port, dan itulah kasus yang paling mungkin bertahan tanpa perubahan setelah tiga putaran pemecahan masalah.

Buktikan cakupan dengan lalu lintas yang cocok

Setelah SA anak terpasang, kirim satu permintaan yang pasti jatuh di dalam rentang yang diterima. Perhatikan penghitung, bukan ikon status: ip -s xfrm state dan penghitung di balik ip xfrm policy bertambah ketika paket dicocokkan dan dilindungi. Jumlah byte yang tetap nol setelah lalu lintas nyata berarti kernel tidak pernah memilih kebijakan itu.

Nol itu adalah masalah perutean atau urutan kebijakan, bukan masalah kripto. Itu juga terlihat identik dengan penolakan pemilih dari sudut pandang pengguna, karena itulah penghitung layak dikumpulkan sebelum Anda membuka profil lagi. Penghitung yang hanya naik di satu arah justru menunjuk ke jalur balik.

Akhiri dengan menuliskan pasangan yang diterima ke tiket, di samping rentang yang semula diminta. Jaga pilihan tetap sesempit kebutuhan, karena menghapus galat dengan mengganti rentang privat dengan semua alamat memberi akses jauh lebih banyak daripada yang disetujui untuk akun.