DNS değişikliklerinden sonra WireGuard hâlâ eski uç noktayı kullanıyor

Sunucunun DNS kaydı taşındıktan sonra tünel trafik geçirmeyi bıraktı, oysa ad aynı makineden doğru çözülüyor. Bu iki olgu birbiriyle çelişmiyor. Bir WireGuard yapılandırması bir uç nokta tutar ve araç, adı o yapılandırmayı uyguladığı anda çözer, bu yüzden çalışan arayüz saatler önce aldığı adresi kullanmaya devam edebilir. Anahtarları değiştirmeden veya tünel aralığına dokunmadan önce arayüzün ne kullandığını denetleyin.

Ad bir kez çözülür, sürekli değil

Temel WireGuard yapılandırması uç noktayı adres ve bağlantı noktası olarak alır ve arayüzü kaldıran araç ana makine adını o anda çözer. Temel protokolde hiçbir şey DNS'i bir zamanlamaya göre sorgulamaz ve istemci uygulaması üstüne kendi yenileme davranışını ekleyebilir. Çözülen adresi, adres ailesini ve bağlantı noktasını adın yanına not etmek o boşluğu görünür kılar. Böyle bir kayıt olmadan arayüz başka bir yerle konuşurken yapılandırma doğru görünür.

Gerçek bir otomatik güncelleme vardır ve bilinmeye değer çünkü DNS yenilemesine benzer ama o değildir. Doğru kimlik doğrulanmış trafik yeni bir adresten geldiğinde eş uç noktası yer değiştirebilir, bu da ad çözümlemesi değil dolaşma. Eşi izler, bu yüzden eski uç noktanın hiç temas etmediği ilgisiz yeni bir sunucuyu keşfedemez.

Kaydı kullanımdaki adresle karşılaştırın

Belgelenen adı istemcinin kullandığı çözümleyici üzerinden sorgulayın, sonra arayüze hangi uç noktayı tuttuğunu sorun. İki yanıt bu sayfanın geri kalanını belirleyen karşılaştırmadır:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

Bu satırların kullandığı show alt komutları wg(8) kılavuzunda belgelenmiştir. Yalnızca adresi değil adres ailesini de karşılaştırın, çünkü IPv6 girdisi kazanmış bir kayıt, IPv4 adresi değişmiş bir kayıttan farklı bir karşılaştırmadır. Uç nokta kayıttan farklıysa arayüz eski bilgiyle çalışıyordur ve ad hiçbir zaman sorun olmamıştır. İkisi uyuşuyor ve tünel yine de başarısız oluyorsa profile değil dinleyiciye ve kurallara geçin.

El sıkışma zaman damgası o bloktadır çünkü uç nokta tek başına eşe ulaşılıp ulaşılamadığını söylemez. Doğru uç noktanın yanındaki eski zaman damgası yol sorunudur, çözümleme sorunu değildir ve bu ayrım sırada neye dokunacağınızı değiştirir.

Arayüzün yöneticisi aracılığıyla yeniden başlatın

Uç noktanın eski olduğu doğrulandıktan sonra, onu arayüzün sahibi olan mekanizma üzerinden yenileyin çalışan yapılandırmayı düzenlemek yerine. wg-quick tarafından başlatılan bir arayüz için bu bir indirip kaldırmadır, systemd birimi için yeniden başlatmadır ve bir yöneticiye ait arayüz için o yöneticide yapılan değişikliktir, çünkü çalışma sırasındaki düzenleme bir sonraki uygulamada üzerine yazılır:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Sonra yerine geçen dinleyicinin ve kimliğinin amaçladığınız hizmet olduğunu doğrulayın. DNS taşınması kimlik değişikliği değildir, bu yüzden doğrulamadığınız bir anahtara güvenmek için asla vesile olmamalıdır. Arayüz artık yeni adresi bildiriyor ve hâlâ el sıkışma üretilmiyorsa arıza yeni ağ yoluna veya dinleyiciye taşınmıştır, bu ilerlemedir, aynı arızanın iki kez tekrarı değil.

Önce el sıkışma, sonra veri yolu

Kontrol listesi seçmeden önce iki sonucu ayırın. Başarısız bir uygulama altında başarılı olan el sıkışma veri yolu sorunudur: rotalar, izin verilen önekler veya tünel içindeki DNS. Hiç gerçekleşmeyen el sıkışma uç noktada erişilebilirlik veya kimlik sorunudur. İkisini karıştırmak kimsenin yeniden üretemeyeceği bir rapor ve üç ilgisiz düzenleme içeren bir değişiklik günlüğü üretir.

Adı, çözülen adresi, kullanılan uç noktayı ve el sıkışmanın tamamlanıp tamamlanmadığını not edin. Bu dört olgu bu arızanın sürekli sorduğu soruyu yanıtlar ve bir sonraki olayı iki dakikalık bir denetime dönüştürür. Ad bakımı ve istemci benimsemesi ayrı işler olarak kalır: kaydı düzeltmek benimsemeyi gerçekleştirmez ve arayüzü yeniden başlatmak hâlâ yanlış olan bir kaydı düzeltmez.