WireGuard eşi yeniden başlatmadan sonra kayboluyor: gerçek yapılandırmayı bulun

wg set ile eklediğiniz eş bütün öğleden sonra ping'lere yanıt verir ve yeniden başlatmadan sonra kaybolur. Hiçbir şey bozulmadı: çekirdek o eşi canlı arayüz dışında hiçbir yerde saklamadı ve açılışta arayüzü yeniden oluşturan her ne varsa onu dokunmadığınız bir dosyadan inşa etti. Onarım bir wg set daha değildir. Hangi bileşenin arayüze sahip olduğunu bulmak, o bileşenin durumunu düzenlemek ve ardından eşin tam olarak onu kaldıran yaşam döngüsü olayından sağ çıktığını kanıtlamaktır.

Bir kez bilerek yeniden üretin

Yeniden başlatma sorununu kendi gözünüzle görmeden düzeltmeyin. Konsol veya bant dışı erişim varsa eş listesini not edin, arayüzün sahibi olan hizmet üzerinden yeniden başlatın ve karşılaştırın. Eş hâlâ oradaysa, değişikliğiniz kalıcı duruma ulaşmış demektir ve yanlış olayı hata ayıklıyorsunuz.

Bunu yaparken üç gerçeği yazın: arayüzün adı, onu başlatan unit veya profil ve hayatta kalan eşteki el sıkışma sayacının sıfırlanıp sıfırlanmadığı. Sıfırlanmış sayaç arayüzün yok edilip yeniden oluşturulduğunu gösterir; değişmemiş sayaç ve kayıp eş, bir şeyin konfigürasyonu ayağınızın altında düzenlediğini gösterir.

Arayüzün sahibi kim?

WireGuard'ın kendisinin ne bir daemon'u ne de konfigürasyon dosyası var. Üstünde bir şey açılışta wg çağırır ve o şey gerçeğin kaynağıdır. Olağan adaylar [email protected], bir NetworkManager bağlantı profili, dağıtıma özgü bir ağ unit'i veya kendi veritabanını yazan bir yönetim panelidir.

Dağıtımınızın belgelerine değil sisteme sorun. systemctl status wg-quick@wg0 ve nmcli connection show genellikle bunu birer komutla çözer. İkisi de arayüzde hak iddia ediyorsa hatayı herhangi bir düzenleme yapmadan buldunuz: iki sahip her açılışta aynı aygıtı yeniden yazar ve son çalışan kazanır.

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

Çalışma durumu ile açılış durumu aynı dosya değildir

wg set canlı aygıtı netlink üzerinden yönetir. /etc/wireguard/wg0.conf, bir NetworkManager profili veya bir panelin veritabanını yazmaz. Sonrasında başarılı bir wg show çekirdeğin eşi kabul ettiğini kanıtlar, bir şeyin onu geri getireceğini değil.

Ters yönde ikinci bir tuzak var. wg-quick'in SaveConfig seçeneği, arayüz indirilirken geçerli arayüz durumunu konfigürasyon dosyasına geri yazar. Bu etkinken, arayüz ayaktayken dosyada yapılan bir düzenleme ardından gelen kapanışla üzerine yazılabilir ve o satırın orada olduğuna yemin edersiniz. Eş sürekli geri geliyorsa dosyayı durdurduktan sonra okuyun, öncesinde değil.

NetworkManager yine farklı davranır: profilin sahibi odur ve etkinleştirme sırasında uygular, bu yüzden etkin bir NetworkManager bağlantısının yanındaki elle düzenlenmiş .conf sadece dekorasyondur. Arayüz için tek bir sahip seçin ve diğer yöneticinin ona dokunmamasına izin verin.

Değişikliğin iki yere de inmesini sağlayın

Önce kalıcı durumu düzenleyin, sonra sahibin onu uygulamasına izin verin, en son canlı durumu doğrulayın. Bu sıra, herhangi bir adımdaki başarısızlığın üç yerine tek bir şeye işaret etmesi demektir.

# 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 canlı konfigürasyonu dosyanın kullandığı sözdizimiyle yazdırır, bu da ikisini doğrudan karşılaştırılabilir kılar. Bu çıktıya bir sır gibi davranın: içinde özel anahtarlar var, bu yüzden bir bilete veya sohbet kanalına yapıştırmayın. Eşlerin ortak anahtarlarını ve izin verilen IP'leri karşılaştırın ve bilerek kaldırdığınız eşin geri gelmediğini kontrol edin.

Yaşam döngüsü olayından sağ çıktığını kanıtlayın

Sahip üzerinden ikinci kez yeniden başlatın, ardından üç ayrı şeyi doğrulayın: eş wg show içinde görünüyor, trafikten sonra el sıkışma sayacı artıyor ve tünele bağlı uygulama gerçekten yanıt veriyor. Eski el sıkışmayla listelenen bir eş, yönlendirme veya anahtar sorunudur, kalıcılık sorunu değildir ve bu ayrım anlamsız bir konfigürasyon düzenlemesini önler.

Son olarak yeniden başlatmanın neyi geri getirdiğini kontrol edin. Bilerek kaldırdığınız bir eşi dirilten yeniden başlatma, aynı hatanın zıt işaretidir ve genellikle konfigürasyonun eski bir kopyasının hâlâ bir yerden yüklendiği anlamına gelir. Sahibi, dosya yolunu, eşin ortak anahtarını ve doğrulama komutlarını konfigürasyonun yanına not edin, böylece sonraki kişi bir üretim sunucusunu yeniden başlatarak bunu yeniden keşfetmesin.