Mode trap strongSwan: mengapa tunnel IPsec menunggu lalu lintas

Tidak ada CHILD SA yang muncul di keluaran status, tunnel tampak mati, lalu ping ke subnet jauh menaikkannya. Dalam penyiapan IPsec sesuai permintaan, urutan itu memang desainnya, bukan kerusakan. Kebijakan trap memasang selektor dan menunggu, dan paket pertama yang cocok dengannya itulah yang memulai IKE dan negosiasi CHILD SA.

Sebagian kebingungannya soal kosakata: “up” dipakai untuk dua keadaan berbeda. Konfigurasi telah dimuat dan kebijakan kernel ada, tetapi asosiasi data tidak. Monitor yang hanya menghitung SA aktif akan melaporkan situs sehat sebagai mati selama tidak ada yang mengirim lalu lintas ke sana.

Tunnel sesuai permintaan yang menganggur tidak punya CHILD SA untuk ditampilkan

Entri trap tidak mengautentikasi apa pun dengan sendirinya. Ia meminta kernel memegang kebijakan untuk lalu lintas terpilih dan menaikkan acquisition saat sebuah paket membutuhkan kebijakan itu. Daemon menerima acquisition, mencocokkannya dengan definisi child, dan bernegosiasi dari sana. Sampai titik itu tidak ada IKE SA untuk ditampilkan juga, karena itu kedua daftar bisa kosong bersamaan.

Urutan itulah yang membuat log mudah dibaca. Acquisition datang lebih dulu, lalu IKE_SA_INIT dan IKE_AUTH, lalu CHILD SA. Jika log berakhir tepat setelah acquisition, pemicunya bekerja. Negosiasi gagal, dan pertanyaan berikutnya soal kredensial, proposal, atau keterjangkauan, bukan soal trap.

Dengan backend kernel Linux Anda bisa melihat kebijakan sebelum ada SA apa pun. Jalankan ip xfrm policy dan cari selektor dengan arah out dan templat yang menunjuk ke koneksi. Entri itu adalah keadaan sesuai permintaan, dan keberadaannya adalah hal pertama yang perlu dikonfirmasi.

start_action menentukan apakah ada yang menunggu sama sekali

Setiap child di swanctl.conf membawa start_action. start dimulai saat konfigurasi dimuat, trap memasang kebijakan dan menunggu, dan none menyerahkan inisiasi ke hal lain. Hanya trap menghasilkan perilaku “ping dan ia naik” yang dijelaskan di atas.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Dua selektor lalu lintas menentukan apa yang dianggap menarik, dan paket dari host di luar prefiks itu tidak memicu trap; ia dirutekan seperti biasa. Melebarkan selektor agar pemicu lebih agresif juga melebarkan cakupan yang diklaim tunnel lindungi, jadi turunkan dari lalu lintas yang benar-benar ingin Anda enkripsi.

Referensi swanctl.conf mencantumkan nilai yang diterima, bersama aksi close dan DPD terpisah yang mengatur apa yang terjadi setelah SA ada.

Cari tahu apakah pemicunya terpicu sama sekali

Mulai dengan swanctl --list-conns dan pastikan child dimuat dengan aksi yang Anda maksud. Lalu kirim satu paket dari host di dalam local_ts ke alamat di dalam remote_ts dan amati swanctl --list-sas. Jika keluarannya tidak berubah, tidak ada acquisition yang mencapai daemon.

Dua alasan umum trap yang senyap: paket sudah di-source-NAT sebelum mengenai kebijakan dan tidak lagi cocok dengan local_ts, atau koneksi tidak pernah dimuat karena kesalahan sintaksis atau kredensial. Jalankan ulang swanctl --load-all dan baca keluarannya sebelum menyentuh selektor. Koneksi yang gagal dimuat tidak memasang kebijakan, jadi tidak ada yang bisa dipicu oleh lalu lintas.

Arah juga penting: trap yang dipasang untuk lalu lintas keluar tidak dimulai oleh paket masuk. Jika sisi jauh yang harus menaikkan tunnel, ia butuh trap sendiri, atau sisi ini butuh start.

Menunggu paket pertama tidak selalu pertukaran yang tepat

Sesi interaktif merasakan biaya penyiapan. Permintaan pertama membayar pertukaran IKE dan negosiasi CHILD, dan klien dengan tenggat pendek bisa menyerah sebelum SA ada. start proaktif menghapus penundaan paket pertama itu. Tetapi ia menjaga tunnel tetap naik untuk lalu lintas yang mungkin tidak pernah datang.

Tiga fakta menentukan pilihan: seberapa sering jalur dipakai, apakah permintaan pertama punya tenggat ketat, dan apakah peer dapat dijangkau saat boot. Lalu lintas batch sesekali dan peer yang mungkin offline saat boot keduanya mendukung trap. Klien yang peka latensi dan peer yang selalu dapat dijangkau mendukung start. Jika kedua sisi bisa memulai, sepakati siapa pemilik pemicunya agar tidak ada negosiasi ganda.

Kebijakan yang terpasang juga bukan jaminan anti-kebocoran. Jika syaratnya fail-closed, firewall harus menjatuhkan lalu lintas tanpa SA, dan aturan itu hidup di luar definisi child.

Catat tiga baris yang mengakhiri perdebatan berikutnya

Tuliskan selektor, aksi saat mulai, dan keluaran perintah yang menunjukkan kebijakan ada tanpa SA. Tiga baris itu memisahkan “sesuai permintaan dan menganggur” dari “tidak dimuat” lain kali seseorang melaporkan tunnel mati. Mencatatnya butuh satu menit. Tanpanya, investigasi yang sama dimulai dari nol.

Uji dari host yang benar-benar berada di dalam selektor. Ping dari router itu sendiri sering menempuh jalur berbeda dan tidak membuktikan apa pun tentang kebijakan yang melindungi subnet di belakangnya.