Peer yang Anda tambahkan dengan wg set menjawab ping sepanjang sore dan hilang setelah reboot. Tidak ada yang rusak: kernel tidak pernah menyimpan peer itu di tempat lain selain di antarmuka yang hidup, dan apa pun yang membuat ulang antarmuka saat boot membangunnya dari berkas yang tidak Anda sentuh. Perbaikannya bukan wg set lain. Perbaikannya adalah mencari tahu komponen mana yang memiliki antarmuka, mengubah keadaan komponen itu, lalu membuktikan peer bertahan dari peristiwa siklus hidup yang menghapusnya.

Reproduksi sekali, dengan sengaja

Jangan perbaiki masalah restart sebelum Anda bisa melihatnya terjadi. Dengan akses konsol atau out-of-band tersedia, catat daftar peer, restart melalui layanan yang memiliki antarmuka, dan bandingkan. Jika peer masih ada, perubahan Anda sudah mencapai keadaan persisten dan Anda men-debug peristiwa yang salah.

Catat tiga fakta saat melakukannya: nama antarmuka, unit atau profil yang memulainya, dan apakah penghitung jabat tangan pada peer yang bertahan direset. Penghitung yang direset berarti antarmuka dihancurkan dan dibuat ulang; penghitung yang tidak berubah dengan peer yang hilang berarti sesuatu mengedit konfigurasi di bawah kaki Anda.

Siapa yang memiliki antarmuka?

WireGuard sendiri tidak punya daemon dan tidak punya berkas konfigurasi. Sesuatu di atasnya memanggil wg saat boot, dan sesuatu itulah sumber kebenarannya. Kandidat yang biasa adalah [email protected], profil koneksi NetworkManager, unit jaringan khusus distribusi, atau panel manajemen yang menulis basis datanya sendiri.

Tanyakan ke sistem, bukan ke dokumentasi distribusi Anda. systemctl status wg-quick@wg0 dan nmcli connection show biasanya menyelesaikannya dengan satu perintah masing-masing. Jika keduanya mengklaim antarmuka, Anda sudah menemukan bug sebelum mengedit apa pun: dua pemilik menulis ulang perangkat yang sama pada setiap start, dan yang terakhir berjalan menang.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

Keadaan runtime dan keadaan startup bukan berkas yang sama

wg set memanipulasi perangkat yang hidup melalui netlink. Ia tidak menulis /etc/wireguard/wg0.conf, profil NetworkManager, atau basis data panel. wg show yang berhasil sesudahnya membuktikan kernel menerima peer, bukan bahwa sesuatu akan memulihkannya.

Ada jebakan kedua ke arah sebaliknya. Opsi SaveConfig dari wg-quick menulis keadaan antarmuka saat ini kembali ke berkas konfigurasi ketika antarmuka diturunkan. Jika opsi itu aktif, suntingan pada berkas yang dilakukan saat antarmuka hidup bisa ditimpa oleh pematian berikutnya, dan Anda akan bersumpah baris itu tadinya ada. Jika peer terus kembali, baca berkas setelah penghentian, bukan sebelumnya.

NetworkManager berperilaku lain lagi: ia memiliki profil dan menerapkannya saat aktivasi, jadi .conf yang diedit tangan di samping koneksi NetworkManager yang aktif hanya hiasan. Pilih satu pemilik untuk antarmuka dan biarkan manajer lain tidak mengusiknya.

Pastikan suntingan mendarat di kedua tempat

Edit dulu keadaan persisten, lalu biarkan pemilik menerapkannya, lalu verifikasi keadaan yang hidup. Urutan itu berarti kegagalan pada langkah mana pun menunjuk ke satu hal, bukan tiga.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf mencetak konfigurasi yang hidup dalam sintaksis yang sama dengan yang dipakai berkas, sehingga keduanya bisa dibandingkan langsung. Perlakukan keluaran itu sebagai rahasia: isinya kunci privat, jadi jangan menempelkannya ke tiket atau kanal obrolan. Bandingkan kunci publik peer dan IP yang diizinkan, dan periksa bahwa peer yang sengaja Anda hapus tidak kembali.

Buktikan ia bertahan dari peristiwa siklus hidup

Restart melalui pemilik untuk kedua kalinya, lalu pastikan tiga hal terpisah: peer muncul di wg show, penghitung jabat tangan bertambah setelah ada lalu lintas, dan aplikasi yang bergantung pada terowongan benar-benar menjawab. Peer yang terdaftar dengan jabat tangan lama adalah masalah perutean atau kunci, bukan masalah persistensi, dan pembedaan itu menghemat suntingan konfigurasi yang sia-sia.

Terakhir, periksa apa yang dipulihkan oleh restart. Restart yang menghidupkan kembali peer yang sengaja Anda hapus adalah bug yang sama dengan tanda berlawanan, dan biasanya berarti salinan konfigurasi lama masih dimuat dari suatu tempat. Catat pemilik, jalur berkas, kunci publik peer, dan perintah verifikasi di samping konfigurasi, supaya orang berikutnya tidak menemukannya lagi dengan me-restart host produksi.

Artikel terkait