ipsec.conf atau swanctl.conf? Pilih satu frontend strongSwan
ipsec.conf dan swanctl.conf milik pemuat strongSwan yang berbeda. Pastikan layanan yang berjalan sebelum menerjemahkan profil IKEv1 lama.
Profil IKEv1 yang berfungsi dari panduan lama mendarat di Ubuntu 24.04, dan percobaan pertama gagal karena daemon tidak pernah membaca berkas itu. Tanggapan biasanya adalah menyunting profil lagi. Pertanyaan sebenarnya adalah frontend strongSwan mana yang terpasang dan mana yang dipakai layanan yang berjalan. Sampai itu terjawab, setiap suntingan diarahkan ke pemuat yang mungkin tidak ada.
Dua berkas, dua pemuat, satu daemon
Susunan starter lama membaca ipsec.conf dan menyerahkan koneksi ke charon melalui integrasi manajemen lamanya. Titik masuk operasionalnya adalah perintah ipsec.
Susunan swanctl memuat definisi melalui VICI, membaca swanctl.conf, dan digerakkan oleh perintah swanctl. Daemon charon asli systemd terintegrasi dengan pendekatan itu.
Keduanya dapat dipasang di mesin yang sama, dan di situlah kebingungan dimulai. Berkas di bawah /etc hanya membuktikan bahwa seseorang menulisnya, bukan bahwa proses yang berjalan memuatnya. Memasang semua alternatif untuk melihat mana yang berfungsi menciptakan host dengan dua jalur manajemen dan tanpa pemilik yang jelas. Pilih satu susunan dan hapus atau nonaktifkan yang lain.
Baca paket dan unit yang terpasang
Mulailah dalam mode hanya-baca. Nama paket di Ubuntu 24.04 terpisah: strongswan-starter, strongswan-swanctl, dan charon-systemd. Paket yang hilang adalah informasi berguna, bukan instruksi untuk memasangnya.
Inventarisasi paket dan unit dalam satu langkah:
dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'
Lalu periksa unit aktif dan perintah mulainya. Nama unit memberi tahu daemon mana yang memiliki konfigurasi, dan baris perintah menegaskan berkas mana yang diperintahkan untuk dibaca. Unit yang diaktifkan tetapi tidak aktif menceritakan kisah berbeda dari unit yang berjalan sekarang.
Jika unit aktif adalah strongswan-starter, berkas yang penting adalah ipsec.conf. Jika itu charon-systemd dengan swanctl, ipsec.conf hanya hiasan.
Gunakan jalur kendali yang cocok
Setiap frontend punya pandangannya sendiri atas koneksi dan asosiasi. swanctl --list-conns menampilkan definisi yang dimuat dan swanctl --list-sas menampilkan asosiasi aktif. Jalur lama memakai ipsec statusall.
Mencampurnya menghasilkan galat yang menyesatkan. Soket VICI yang hilang atau permintaan kendali yang ditolak adalah masalah jalur manajemen, bukan bukti bahwa rekan menolak autentikasi.
Baca pandangan yang menjadi milik daemon yang berjalan, lalu tafsirkan hasilnya. Jika koneksi tidak ada dalam pandangan itu, masalahnya ada pada pemuatan, bukan negosiasi.
Format bukan versi IKE
Profil lama memilih IKEv1 dengan keyexchange=ikev1. Koneksi swanctl memakai pengaturan versi, di mana 1 memilih IKEv1. Itu dua kosakata untuk gagasan yang sama, bukan konversi.
Alamat rekan, identitas lokal dan jarak jauh, sumber kredensial, proposal, dan pemilih child harus dipetakan dengan sengaja. Menempelkan blok left/right ke sintaks swanctl tidak melakukan satu pun dari itu.
Mengubah hanya versi protokol adalah setengah-migrasi yang paling umum. Hasilnya berkas yang dimuat lalu gagal melakukan autentikasi karena alasan yang tidak berkaitan dengan versi. IKEv1 sendiri sudah usang menurut RFC 9395, jadi rekan yang ada dan masih memerlukannya layak mendapat batasan kompatibilitas yang terdokumentasi dan jalur migrasi, bukan default baru.
Periksa pemuat sebelum menyentuh profil
Jalankan pemeriksaan pemuat lebih dulu, lalu muat koneksi yang dimaksud, lalu nilai negosiasi, lalu jalur lalu lintas yang dilindungi. Setiap tahap punya tanda kegagalan berbeda.
Kedua jalur kendali menjawab pertanyaan pemuatan secara langsung:
swanctl --list-conns
ipsec statusall
Hanya satu dari perintah itu yang menjadi milik host Anda. Menjalankan keduanya dan membandingkan keluaran adalah cara menemukan mana yang membohongi Anda, bukan metode diagnostik.
Perlakukan kepemilikan paket, pemuatan konfigurasi, dan kompatibilitas protokol sebagai tiga pertanyaan terpisah. Berkas yang valid untuk satu frontend akan disunting berulang kali sementara daemon lain yang berjalan.