Ansible bilang sudah dimulai, tetapi WireGuard masih memakai konfigurasi lama

Putaran playbook berakhir hijau, unit WireGuard aktif, handshake bekerja, dan peer baru tetap tidak mencapai apa pun. Melihat playbook melaporkan sukses sementara server berjalan dengan konfigurasi kemarin sangat menjengkelkan, karena tidak ada yang salah pada keluarannya. Ansible melakukan tepat apa yang diminta: memastikan unit sudah dimulai, dan unit memang sudah berjalan. Menerapkan berkas konfigurasi yang ditulis ulang adalah tugas lain, dan hanya terjadi jika ada sesuatu yang meminta layanan membacanya ulang.

Perhatikan apa yang sebenarnya dilaporkan putaran kedua

Jalankan playbook dua kali dengan konfigurasi yang diubah dan bandingkan ringkasannya. Putaran kedua seharusnya menampilkan tugas unit sebagai ok, bukan changed, karena layanan yang sudah berjalan dibiarkan begitu saja menurut desain. Itulah idempotensi yang bekerja benar, sekaligus alasan berkas baru tidak pernah sampai ke kernel.

Tambahkan putaran pemeriksaan dengan keluaran diff untuk melihat tugas mana yang akan menyentuh apa pun.

ansible-playbook -i inventory site.yml --check --diff
systemctl show wg-quick@wg0 -p ActiveEnterTimestamp -p NRestarts
stat -c '%y %n' /etc/wireguard/wg0.conf

Ketiga stempel waktu menceritakan masalahnya sebelum Anda membaca satu baris log pun. Jika berkas konfigurasi lebih baru daripada saat unit menjadi aktif, antarmuka yang berjalan dibangun dari berkas lama, dan semua gejala berikutnya berasal dari sana.

Ini bukan cacat Ansible. Perilaku yang sama muncul pada alat manajemen konfigurasi apa pun yang memisahkan «pastikan berjalan» dari «pastikan menjalankan ini». Perbedaannya tampak berlebihan sampai merugikan Anda satu sore.

Dimulai adalah status, bukan muat ulang

state: started menegaskan suatu kondisi tentang unit. Ia tidak menjanjikan layanan membaca ulang masukannya, dan tidak bisa tahu bahwa berkas yang tidak pernah dibukanya telah berubah. Pada penerapan wg-quick, masukan mencakup konfigurasi antarmuka, alamat, rute, entri DNS, dan hook post-up apa pun.

Karena itu berkas yang diperbarui bisa memuat peer baru, alamat berbeda, atau direktif perutean yang berubah sementara antarmuka aktif tetap melayani kumpulan lama. Handshake masih berhasil karena kunci dan endpoint yang dimuat masih valid. Itulah yang membuat kegagalan sulit terlihat, dan mengapa orang mengejar DNS selama satu jam sebelum memeriksa stempel waktu.

Dua opsi modul lain sering disangka solusi. daemon_reload membuat systemd membaca ulang berkas unit, yang tidak relevan bagi berkas konfigurasi WireGuard. state: reloaded meminta unit menjalankan aksi muat ulangnya, dan apakah itu memenuhi kebutuhan Anda sepenuhnya bergantung pada unit. Keduanya bukan pengganti mengetahui masukan mana yang benar-benar dibaca proses yang berjalan.

Pasang berkasnya, lalu beri tahu handler

Pola yang menjaga idempotensi dan tetap menerapkan perubahan adalah pola biasa: tugas yang menulis berkas memberi tahu handler, dan handler hanya berjalan bila berkas benar-benar berubah. Putaran kedua tanpa suntingan tidak melakukan apa pun, dan itulah yang Anda inginkan.

- name: write the interface configuration
  ansible.builtin.template:
    src: wg0.conf.j2
    dest: /etc/wireguard/wg0.conf
    owner: root
    mode: "0600"
  notify: apply wg0

- name: ensure the interface unit is enabled
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    enabled: true
    state: started

- name: apply wg0
  listen: apply wg0
  ansible.builtin.systemd_service:
    name: wg-quick@wg0
    state: restarted

Handler berjalan di akhir play, setelah tugas yang memberitahunya, jadi tugas yang lebih belakang dalam play yang sama masih bisa melihat antarmuka lama. Jika urutan penting, kosongkan handler secara eksplisit dengan meta: flush_handlers sebelum tugas yang bergantung pada konfigurasi baru.

Gunakan restart alih-alih reload kecuali Anda sudah memverifikasi aksi muat ulang unit. Unit wg-quick hulu mendukungnya dan menyinkronkan konfigurasi WireGuard, tetapi tidak menjalankan ulang penyiapan alamat, rute, DNS, atau hook. Jadi reload setelah menambahkan direktif rute tampak berhasil dan tidak mengubah apa pun.

Bandingkan perangkat aktif dengan berkas

Pemeriksaan yang menutup kelas bug ini adalah perbandingan antara yang dipegang kernel dan yang dikatakan berkas. Dua perintah menghasilkan keluaran yang sebanding, dan selisihnya adalah penyimpangan.

sudo wg showconf wg0
sudo wg-quick strip wg0
sudo diff <(sudo wg showconf wg0) <(sudo wg-quick strip wg0)

wg showconf mencetak perangkat aktif, termasuk kunci privat, jadi perlakukan keluaran itu sebagai rahasia dan jangan menempelkannya di tiket. wg-quick strip mencetak berkas tanpa kunci khusus wg-quick, dan itulah sebabnya keduanya bisa dibandingkan.

Perbedaan pada daftar peer berarti berkas tidak pernah diterapkan. Perbedaan hanya pada kunci atau endpoint yang Anda duga akan berubah berarti sesuatu menerapkannya sebagian. Tidak ada perbedaan berarti konfigurasi mutakhir dan kesalahannya di tempat lain, yang sudah merupakan hasil berguna.

Bayar biaya mulai ulang secara sadar

Memulai ulang antarmuka memutus terowongan, dan jika terowongan itu membawa sesi administratif Anda, mulai ulang mengakhiri sesi yang memintanya. Letakkan handler di balik jendela perubahan, atau jalankan playbook dari jalur manajemen yang tidak bergantung pada mulai ulang antarmuka.

Biaya itulah yang membuat orang memilih reload. Itu naluri yang wajar, dan menjadi tepat begitu Anda tahu perubahan apa yang benar-benar diterapkan reload. Untuk perubahan peer dan kunci pada unit wg-quick hulu itu cukup; untuk pengalamatan, perutean, dan hook tidak. Menuntaskannya sekali lebih murah daripada menemukannya saat jendela perubahan.

Dokumentasi modul systemd_service menjelaskan perbedaan antara started, restarted, dan reloaded, dan layak dibaca sekali daripada disimpulkan dari ringkasan hijau. Semua dalam panduan ini berasal dari satu perbedaan itu.