strongSwan tetap mati setelah peer reboot: pulihkan satu terowongan

Tinggalkan restart daemon. Pasang inisiasi dan DPD pada koneksi yang harus kembali, lalu verifikasi berdasarkan nama dan buktikan layanannya, bukan daemonnya.

Gateway jarak jauh di-reboot, kembali dalam satu menit, dan daemon strongSwan lokal terus berjalan sementara terowongan masih mati. Tugas cron yang melakukan grep ESTABLISHED dan me-restart daemon pada akhirnya akan menutupi itu, dan juga akan memutus setiap terowongan tak terkait di mesin sambil mungkin melewatkan yang gagal. Pemulihan menjadi milik koneksi yang harus kembali, dinyatakan dalam pengaturan yang bertahan setelah reload. Runbook ini menyiapkannya untuk satu koneksi dan membuktikan hasilnya berdasarkan nama.

Tinggalkan restart global, simpan buktinya

Restart daemon membawa dua cacat spesifik: ia menghancurkan state setiap koneksi, dan tidak memberi tahu peristiwa mana yang sebenarnya gagal. Teks status yang Anda grep bisa berasal dari koneksi lain, sementara child yang dibutuhkan duduk diam karena tidak ada yang memicunya.

Baca koneksi yang dimuat dan asosiasi yang aktif sebelum mengubah apa pun, agar Anda punya gambaran sebelum untuk dibandingkan setelah peer kembali.

swanctl --list-conns
swanctl --list-sas

Pasang inisiasi dan percobaan ulang pada koneksi yang kembali

Dalam penerapan swanctl.conf, pengaturan ini berada di tingkat koneksi dan child, bukan dalam kebijakan global. Fragmen di bawah adalah contoh sisi inisiator yang mengasumsikan proposal, autentikasi, dan selektor sudah benar.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action memutuskan apa yang terjadi saat child dimuat: start memulai segera, sedangkan trap memasang kebijakan yang memicu inisiasi ketika lalu lintas yang cocok muncul. Menulis trap|start membutuhkan strongSwan 5.9.6 atau lebih baru, jadi periksa versinya sebelum menyalin baris tersebut. dpd_action=restart meminta negosiasi baru begitu peer dinyatakan mati, dan keyingtries=0 di tingkat koneksi memungkinkan percobaan lebih lanjut hingga berhasil atau terjadi kesalahan permanen. Di bawah IKEv2, dpd_timeout tidak berpengaruh sama sekali, karena transmisi ulang biasa yang menentukan kapan peer tidak merespons.

Penundaan dalam contoh itu adalah titik awal, bukan tenggat universal. Pilih berdasarkan berapa lama reboot peer berlangsung dan berapa banyak transmisi ulang yang bersedia Anda tanggung.

Ketahui peristiwa mana yang sedang Anda pulihkan

Tiga kegagalan tampak identik di dasbor dan membutuhkan pengaturan berbeda. Koneksi awal yang tidak pernah naik adalah masalah konfigurasi atau keterjangkauan. Peer yang berhenti menjawab adalah kasus DPD. Child yang ditutup secara eksplisit oleh peer adalah peristiwa kebijakan dengan close_action sendiri, yang tidak pernah diamati DPD. Membaca log di sekitar gangguan memberi tahu Anda yang mana dari ketiganya, dan jawabannya mengubah perbaikannya.

Jangan tambahkan inisiasi ulang agresif pada koneksi yang sengaja ditutup operator untuk pemeliharaan, atau terowongan muncul lagi di tengah jendela. Untuk desain sesuai permintaan, trap yang dipertahankan sudah cukup, karena lalu lintas yang cocok membangun kembali child tanpa timer apa pun.

Verifikasi berdasarkan nama, bukan status daemon

Baca koneksi dan child-nya berdasarkan nama saat peer masih mati, lalu lagi setelah kembali; perbedaan antara kedua keluaran itulah buktinya.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

Lalu konfirmasi layanannya, bukan asosiasinya. Asosiasi keamanan child yang baru plus permintaan yang berhasil ke tujuan privat di belakangnya adalah pasangan fakta yang penting, dan daemon yang berjalan dengan terowongan tak terkait yang sehat tidak membuktikan keduanya.

Jika child tidak pernah memulai, periksa apakah lalu lintas uji cocok persis dengan selektor yang dikonfigurasi, termasuk protokol dan port. Jika memulai dan gagal, baca kesalahan autentikasi atau proposal alih-alih menyembunyikannya di balik loop tanpa akhir, karena keyingtries=0 akan dengan senang hati mengulang penolakan permanen selamanya.

Muat perubahan dalam jendela dan uji ulang

Reload lebih aman daripada me-restart daemon, dan tetap tidak gratis: mengganti atau membongkar child dapat menutup asosiasi yang sudah dimulai atau menjatuhkan trap-nya.

Muat selama jendela pemeliharaan, simpan file sebelumnya, dan pastikan koneksi muncul dengan pengaturan yang Anda maksud, bukan dengan default.

swanctl --load-conns
swanctl --list-conns

Kembalikan dengan memulihkan file sebelumnya dan memuatnya lagi, lalu ulangi dua perintah yang sama. Terowongan yang hanya kembali setelah restart daemon belum diperbaiki, melainkan direset.

Artikel terkait