ipsec.conf atau swanctl.conf? Pilih satu frontend strongSwan

Profil IKEv1 yang berfungsi daripada panduan lama mendarat di Ubuntu 24.04, dan percubaan pertama gagal kerana daemon tidak pernah membaca fail itu. Tindak balas biasa ialah menyunting profil itu sekali lagi. Soalan sebenar ialah frontend strongSwan mana yang dipasang dan mana yang digunakan oleh perkhidmatan yang berjalan. Sehingga itu dijawab, setiap suntingan tertuju kepada pemuat yang mungkin tidak wujud.

Dua fail, dua pemuat, satu daemon

Susunan starter lama membaca ipsec.conf dan menyerahkan sambungan kepada charon melalui integrasi pengurusan lamanya. Titik masuk operasinya ialah arahan ipsec.

Susunan swanctl memuatkan definisi melalui VICI, membaca swanctl.conf dan dipandu oleh arahan swanctl. Daemon charon asli systemd berintegrasi dengan pendekatan itu.

Kedua-duanya boleh dipasang pada mesin yang sama, dan di situlah kekeliruan bermula. Fail di bawah /etc hanya membuktikan seseorang telah menulisnya, bukan bahawa proses yang berjalan telah memuatkannya. Memasang setiap alternatif untuk melihat mana yang berfungsi menghasilkan hos dengan dua laluan pengurusan dan tanpa pemilik yang jelas. Pilih satu susunan dan buang atau lumpuhkan yang lain.

Baca pakej dan unit yang dipasang

Mulakan dalam mod baca sahaja. Nama pakej pada Ubuntu 24.04 adalah berasingan: strongswan-starter, strongswan-swanctl dan charon-systemd. Pakej yang tiada ialah maklumat berguna, bukan arahan untuk memasangnya.

Senaraikan pakej dan unit dalam satu langkah:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

Kemudian periksa unit aktif dan arahan permulaannya. Nama unit memberitahu daemon mana yang memiliki konfigurasi, dan baris arahan mengesahkan fail mana yang diarahkan untuk dibaca. Unit yang didayakan tetapi tidak aktif menceritakan kisah berbeza daripada yang sedang berjalan sekarang.

Jika unit aktif ialah strongswan-starter, fail yang penting ialah ipsec.conf. Jika ia charon-systemd dengan swanctl, ipsec.conf hanyalah hiasan.

Gunakan laluan kawalan yang sepadan

Setiap frontend mempunyai pandangannya sendiri tentang sambungan dan persatuan. swanctl --list-conns menunjukkan definisi yang dimuatkan dan swanctl --list-sas menunjukkan persatuan aktif. Laluan lama menggunakan ipsec statusall.

Mencampurkannya menghasilkan ralat yang mengelirukan. Soket VICI yang tiada atau permintaan kawalan yang ditolak ialah masalah laluan pengurusan, bukan bukti bahawa rakan menolak pengesahan.

Baca pandangan yang menjadi milik daemon yang berjalan, kemudian tafsirkan hasilnya. Jika sambungan tiada dalam pandangan itu, masalahnya ialah pemuatan, bukan rundingan.

Format bukan versi IKE

Profil lama memilih IKEv1 dengan keyexchange=ikev1. Sambungan swanctl menggunakan tetapan versi, di mana 1 memilih IKEv1. Itu dua kosa kata untuk idea yang sama, bukan penukaran.

Alamat rakan, identiti tempatan dan jauh, sumber kelayakan, cadangan dan pemilih child mesti dipetakan dengan sengaja. Menampal blok left/right ke dalam sintaks swanctl tidak melakukan apa-apa daripadanya.

Menukar hanya versi protokol ialah separuh-migrasi yang paling biasa. Ia menghasilkan fail yang dimuatkan dan kemudian gagal pengesahan atas sebab yang tidak berkaitan dengan versi. IKEv1 sendiri sudah lapuk menurut RFC 9395, jadi rakan sedia ada yang masih memerlukannya wajar mendapat sekatan keserasian yang didokumentasikan dan laluan migrasi, bukan lalai baharu.

Periksa pemuat sebelum menyentuh profil

Jalankan pemeriksaan pemuat dahulu, kemudian muatkan sambungan yang dimaksudkan, kemudian nilai rundingan, kemudian laluan trafik yang dilindungi. Setiap peringkat mempunyai tandatangan kegagalan yang berbeza.

Kedua-dua laluan kawalan menjawab soalan pemuatan secara langsung:

swanctl --list-conns
ipsec statusall

Hanya satu daripada arahan itu milik hos anda. Menjalankan kedua-duanya dan membandingkan output ialah cara menemui mana yang menipu anda, bukan kaedah diagnostik.

Anggap pemilikan pakej, pemuatan konfigurasi dan keserasian protokol sebagai tiga soalan berasingan. Fail yang sah untuk satu frontend akan disunting berulang kali sementara daemon lain yang sedang berjalan.