Bir WireGuard eşine erişilemiyor, diğeri çalışıyor: denetim listesi

Bir WireGuard eşi trafiği geçiriyor, ikincisi el sıkışmayı tamamlıyor ama tünelin arkasındaki hiçbir şeye asla ulaşmıyor. Çalışan eş, arayüzün, UDP bağlantı noktasının ve sunucu anahtarının büyük olasılıkla sorunsuz olduğunu söylüyor. İkinci eşin AllowedIPs'ini, iç kaynak adresini veya aralarındaki yönlendirme kurallarını hiç söylemiyor. Listeyi sırayla işleyin ve koşulu tutmayan ilk adımda durun.

Adım 1: Paketin izlemesi gereken yolu yazın

Aynı hub üzerindeki iki istemci birbirine otomatik olarak ulaşmaz. Hub ve kollar tasarımında sunucu paketi wg0 üzerinde alır ve onu yeniden wg0 dışına diğer eşe iletmesi gerekir, bu da IP iletimi ve bir iletim kuralı gerektirir. Doğrudan eşten eşe tasarımda her taraf diğerinin uç noktasına ve diğerinin tünel adresine AllowedIPs içinde ihtiyaç duyar. Herhangi bir yapılandırmayı okumadan önce hangi tasarımı hata ayıkladığınıza karar verin.

Beklenen yol ayrıca nereye bakacağınızı söyler. Paket hub üzerinden geçecekse, başarısız atlama ya gönderenin AllowedIPs'i, ya hub'ın iletimi ya da alıcının AllowedIPs'idir. Doğrudan gitmesi gerekiyorsa hub önemsizdir ve iki eşteki uç nokta alanları önemlidir.

Adım 2: AllowedIPs'i iki tarafta karşılaştırın, tek tarafta değil

WireGuard, AllowedIPs'i hem yönlendirme tablosu hem de erişim listesi olarak kullanır. Gönderirken tüneli seçmek için hedef adres eşin AllowedIPs'inde aranır; alırken iç kaynak adresinin gönderen eşin AllowedIPs'i içine düşmesi gerekir, aksi halde paket atılır. Herhangi bir tarafta eksik bir aralık aynı belirtiyi verir: taşıma çalışır, yük kaybolur.

Dosya yerine canlı durumu okuyun, çünkü yeniden yükleme sessizce başarısız olmuş olabilir: sudo wg show wg0 allowed-ips. Sunucuda başarısız eşin girdisi tünel adresini içermelidir, örneğin 10.90.0.3/32. İstemcide sunucu eşinin girdisi test ettiğiniz hedefi içermelidir, ister hub'ın tünel adresi ister uzak alt ağ olsun. Örtüşen aralıklar aramayı belirsizleştirir ve amaçlamadığınız bir eşi seçebilir, bu yüzden onları ayrı tutun.

Adım 3: İç kaynak adresini denetleyin

10.90.0.3'ü wg0 üzerinden yönlendiren ancak paketleri Wi-Fi adresinden gönderen istemci alıcı tarafından reddedilir, çünkü kaynak eşin AllowedIPs'i ile eşleşmez. Çekirdeğin gerçekte ne seçtiğini ip route get 10.90.0.3 from 10.90.0.2 ile, tünel arayüzüne atanan adresi ip -brief addr show wg0 ile doğrulayın.

Alıcı Linux ana bilgisayarında ters yol filtreleme ikinci kapıdır. Dönüş yolu rotasına sahip arayüzde katı bir rp_filter, dönüş yolu geldiği arayüzle eşleşmeyen tünel trafiğini düşürebilir. Devre dışı bırakmadan önce etkin değeri denetleyin; birçok topolojide doğru düzeltme bir rotadır, gevşetilmiş bir filtre değil.

Adım 4: Hub iletimini ve dönüş yolunu gözden geçirin

Hub eşler arasında iletmek zorundaysa çekirdeğin net.ipv4.ip_forward=1 değerine ihtiyacı vardır ve güvenlik duvarı iletilen akışı kabul etmelidir: wg0'e giriş, wg0'den çıkış, gönderenin tünel adresinden alıcının adresine. Yaygın bir arıza, UDP 51820'yi kabul eden bir giriş kuralı olup iletim kuralı olmamasıdır], bu yüzden el sıkışma başarılı olur ve yük ölür. Geçerli kuralları sudo nft list ruleset veya güvenlik duvarı yöneticinizin eşdeğeri ile listeleyin.

Ardından yanıtı denetleyin. Hedef ana bilgisayarın gönderene dönüş rotası olmalıdır, ya hub üzerinden ya da kendi ağ geçidi üzerinden. Hub tünel alt ağına da NAT yapıyorsa, çevirinin iletilen akışa uygulandığını ve yanıtın durum sona ermeden hub'a ulaştığını doğrulayın. Anahtar sorunu gibi görünen tek yönlü arıza çoğu zaman yalnızca bu dönüş rotasıdır.

Son olarak, el sıkışmayı veriden ayırın. El sıkışmayı tamamlayan ancak büyük aktarımlarda takılan eşin genellikle tam o yolda MTU veya MSS sorunu vardır, AllowedIPs sorunu değil. Önce küçük bir ping ile, sonra tam boyutlu bir ping ile test edin ve iki eşi karşılaştırın.

Adım 5: Tek bir şeyi değiştirin ve çalışan eşi bozmayın

Başarısız yolda tek bir değişiklik yapın ve iki eşi yeniden test edin. Her eşin AllowedIPs'ini 0.0.0.0/0 ile değiştirmek, zaten çalışan eşi bozmanın en hızlı yoludur, çünkü o arayüzdeki tüm trafik için yönlendirme kararını değiştirir. O tek girdiyi düzenleyin, yeniden yükleyin ve canlı durumu tekrar okuyun.

Hangi yolun başarılı olduğunu, hangisinin başarısız olduğunu ve her biri için tam komut çıktısını kaydedin. Bu karşılaştırma, VPN'in bozuk olduğuna dair genel bir rapordan daha değerlidir ve bir sonraki kişinin ilk isteyeceği şey budur.