WireGuard AllowedIPs: NetworkManager’ın hiç eklemediği yol

El sıkışma sayacı güncelleniyor, arayüz adresini koruyor ve karşı tarafa giden ping hiçbir yere ulaşmıyor. Bu bileşim insanları şaşırtıyor, çünkü çalışan bir el sıkışma tünelin hazır olduğunun kanıtı gibi görünüyor. Değil: bir tünel tamamen müzakere edilmiş olabilir ve yine de içine trafik yönlendiren tek bir yol bulunmayabilir, bunlar iki ayrı durum parçasının yaptığı iki ayrı iştir. Düzeltme tamamen bu ikisinden hangisinin eksik olduğuna bağlıdır, dolayısıyla ilk adım bunu bulmaktır.

wg-quick ikisini de istenmeden yapar. NetworkManager’ın yerleşik WireGuard desteği de varsayılan olarak eş yolları kurar, bu da şüphelileri devre dışı bir seçeneğe, başka bir yönlendirme tablosuna veya başka bir şey üzerinden içe aktarılmış bir yapılandırmaya daraltır.

Yolun peşine düşmeden önce tüneli doğrulayın

wg show arayüzü, eşi, uç noktayı ve son el sıkışmanın yaşını yazdırır, ip addr show ise adresin mevcut olduğunu doğrular. Yakın zamanda yapılmış bir el sıkışma anahtarların, uç noktanın ve UDP yolunun çalıştığı anlamına gelir. Bozuk olan her şey bunların akış aşağısında oturur: yönlendirme, filtreleme veya ad çözümleme.

Sonra çekirdeğe varsayımsal değil gerçek bir hedefle ne yapacağını sorun: ip route get 10.42.7.9. Yanıt, çıkış arayüzünü ve paketin taşıyacağı kaynak adresi adlandırır. Fiziksel bağdaştırıcıyı adlandırdığında, el sıkışma ne kadar sağlıklı görünürse görünsün paket tünele hiç girmez.

AllowedIPs hem bir süzgeç hem bir yol listesidir

AllowedIPs içindeki önekler iki iş yapar. Hangi eşin giden bir hedefi taşıyacağını seçerler ve gelen paketlerin kaynak adresini doğrularlar, ki bu kripto anahtarlı yönlendirmenin sınırıdır. wg-quick içinde otomatik yol kurulumunu da yönetirler ve tam olarak bu ek davranış, aynı yapılandırmanın terminalden çalışıp masaüstü istemcisinden çalışmamasının nedenidir.

Bu makalenin arkasındaki vakada profil, yerleşik destek yerine üçüncü taraf bir eklenti üzerinden içe aktarılmıştı ve arayüz önek yolu olmadan yükseldi. Tabloyu listelemek bunu hemen gösterir: ip route show yalnızca arayüz adresinin bağlı yolunu içerir ve uzak aralık için hiçbir şey yoktur.

Eş yolları hiç açık mı diye sorun

Herhangi bir şeyi değiştirmeden önce ayarı okuyun: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. peer-routes no gösterdiğinde, desteklenen onarım nmcli connection modify work-wg wireguard.peer-routes yes ve ardından yeniden bağlanmadır. Bunun yerine statik bir yol eklemek bir sonraki etkinleştirmeye kadar çalışır ve sonra sessizce kaybolur. O kayboluş ipucudur: her sabah bir bilmece olarak geri gelen yolu profil kurmuyor demektir.

Seçenek zaten açıksa, önekin başka bir tabloda yaşayıp yaşamadığını ip route show table all | grep 10 ile denetleyin. Ana tablo olmayan bir tablodaki yol eksik değildir, yalnızca ana tabloya bakan bir aramaya görünmezdir. Üstüne yinelenen bir giriş yığmak yerine ilke yönlendirmesini düzeltin.

Öneki çalışan sisteme değil, bağlantıya ekleyin

Bağlantı düzenleyicisinde WireGuard sayfası eşi ve AllowedIPs listesini tutar, IPv4 sayfası ise ek yolları tutar. Oraya eklenen bir yol profile ait olduğu için yeniden bağlanmaları atlatır. Komut satırında eşdeğeri, boş ağ geçidi biçiminde bağlantıya bir yol eklemek ve ardından değişikliğin uygulanması için bağlantıyı indirip kaldırmaktır.

İhtiyacınız olan konakları kapsayan en dar öneki seçin. Sağlayıcının /8 örneğini kopyalamak, içinde rastlantısal olarak bulunan yerel aralıkları yutabilir ve ortaya çıkan arızalar çok geniş bir yol gibi değil, bozuk bir tünel gibi görünür.

Bölünmüş tünellemeyi önek listesi belirler

Bölünmüş tünel için anahtar yoktur; önek listesi karardır. Ofis LAN’ı için bir aralık ve laboratuvar ağı için bir aralık taşıyan bir eş, tam olarak o hedefleri tünelden gönderir ve geri kalan her şeyi kendi hâline bırakır. Tek bir konak /32 gerektirir ve iki sitede çakışan aralıklar, biri alt ağı yeniden numaralandırana kadar konak öneklerine ihtiyaç duyar.

Tünelden hiçbir şey göndermemeyi seçmek aynı kararı sınırına taşır: asgari bir liste bağlantıyı ayakta tutar, olağan trafik ise her zamanki yolunu izler. Niyeti yazın, yoksa bir sonraki okuyucu kısa listeyi bir gözden kaçırma sanıp iyi niyetle uzatacaktır.

Yönlendirme tablosu için tek bir sahip

wg-quick ve NetworkManager ikisi de arayüzün yollarına sahip olduklarına inanır. wg-quick için yazılmış bir yapılandırmayı içe aktarıp ardından wg-quick hizmetini de başlatırsanız, davranışı hangisinin son çalıştığına bağlı olan yinelenen veya çelişkili girişler elde edersiniz. Tek bir sahip seçin ve diğerini kaldırın: bağlantıyı NetworkManager yönetiyorsa, o arayüz için wg-quick birimini devre dışı bırakın ve aynı aygıt için asla ikinci bir profil eklemeyin.

Bölünme bir hedef yerine fiziksel bir bağdaştırıcıyı izlemek zorunda kaldığında ilke yönlendirmesine geçmişsinizdir ve ilke yönlendirmesi de tek bir yazar gerektirir. ip route get komutunu yineleyerek doğrulayın, ardından uzak önek içindeki bir konağa seçtiği kaynak adresi yazdıran bir şeyle ulaşın. Profil ikisinden birini taşıyorsa IPv6 ve DNS’i ayrı ayrı denetleyin.