Tünel açık, güvenlik duvarı 53 numaralı portu izin veriyor, AdGuard Home çalışıyor ve yine de WireGuard istemcisi için isimler çözülmüyor. Sorgu normal şekilde geliyor ve cevap normal şekilde gidiyor, bu yüzden çözümleyici üzerindeki paket sayacı sağlıklı görünüyor ve servis masum görünüyor. Sorun olan ise o cevaptaki kaynak adresi: istemcinin hiç istemediği bir yerel adresten çıkıyor ve istemcinin geçici çözümleyicisi onu atıyor. AdGuard Home'un yapılandırmasındaki bir liste bunu belirliyor ve varsayılan ayar genellikle kararı çekirdeğe bırakıyor.

Sorgu geliyor, cevap başka bir yerden gidiyor

10.6.0.1'i çözümleyici olarak yapılandırmış bir istemci, 10.6.0.1 port 53'e bir UDP sorgusu gönderir. Bu paket tünelden geçer ve hosta ulaşır, ve AdGuard Home buna yanıt verir. Ancak kablo üzerinde, yanıt hostun yığını tarafından seçilen kaynak adresiyle yeni bir paket olarak gider, istemcinin beklediği adrese göre değil.

İstemcinin çözümleyicisi bağlı bir soket olduğunda, ki systemd-resolved, dnsmasq ve çoğu stub çözümleyici bunu kullanır, yalnızca gönderdiği adresten gelen yanıtları kabul eder. 10.6.0.1'e gönderilen bir sorguya 192.168.1.10 kaynaklı bir yanıt, herhangi bir ayrıştırma yapılmadan düşülür. Çözümleyici başarılı bir yanıtı kaydeder, istemci zaman aşımını kaydeder ve her ikisi de doğruyu söylüyordur.

Yani sayaçlar yalan söylemiyor ve müşteri de yalan söylemiyor. İhtiyacınız olan kanıt üç yerde, bu sırayla bulunur: dinleyiciye bağlı olan adres, çekirdeğin istemciye geri dönmek için kullanacağı rota ve gerçek yanıt paketindeki kaynak adresi.

Çekirdek yanıt kaynağını nasıl seçer

Bir UDP soketi0.0.0.0kendi kaynak adresine sahip değildir, bu yüzden her giden yanıt hedef için bir rota araması tetikler. Çekirdek sonra kaynağı bu rotadan alır: rotayla sabitlenmiş adres veya giden arayüzün birincil adresi. Sorgunun hedef adresi ile ilgili hiçbir şey hatırlanmaz.

Tek bir ağa bağlı bir hostta bu görünmez, çünkü yalnızca bir olası cevap vardır. Bir LAN adresi, bir WireGuard adresi ve bir yönetim adresi olan bir makinede, birkaç cevap olasıdır ve kazanan o anki yönlendirme tablosuna bağlıdır. Ekstra bir rota ekleyin, aynı arabirimde ikinci bir adres ekleyin, çözümleyicinin önünde bir NAT yönlendirmesi yapın veya AdGuard’u kendi isim alanına sahip bir konteynerde çalıştırın, seçilen kaynak istemcinin sorguladığından farklı olabilir.

ss -lunp | grep :53Hangi oyunda olduğunuzu gösterir.0.0.0.0:53üzerinde bir dinleyici, joker karakter durumudur;10.6.0.1:53üzerinde bir dinleyici zaten cevabı sabitlemiştir. Soketi okumak, YAML’i okumaktan daha hızlıdır ve son kaydedilen yerine aslında çalışanı yansıtır.

bind_hosts'un gerçekten kontrol ettiği şey

AdGuard Home'undns.bind_hostsDNS dinleyicisinin kullandığı yerel adreslerin listesi. Varsayılan olarak gönderilen, her yerel adreste kabul anlamına gelen joker karakterdir ve yanıt başına kaynak adresi kernel seçer. Joker karakteri, istemcilerin sorguladığı adresle değiştirmek, soketi ve her yanıt üzerindeki kaynak adresini değiştirir.

Liste birden fazla giriş alabilir, bu iki ağ hizmeti veren bir çözümleyici için önemlidir.10.6.0.1ve192.168.1.10listelenmesi iki bağlı soket verir ve gelen bir sorgu hangi sokete geldiyse, o adresten yanıtlanır. Bu, çoğu kişinin joker karakterin zaten sağladığını varsaydığı davranıştır.

YAML basittir ve içindeki adres, tünel istemcilerinizin kullanması söylenen adrestir, sunucunun birincil adresi değil:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Bir çözümleyicinin iki kurulumu neden anlaşamıyor

Bu bağlamda eklenti tarafından yönetilen, çözümleyicinin başka bir paket tarafından yüklendiği ve denetlendiği anlamına gelir: bir yönlendirici yazılım paketi, bir NAS paketi veya bir ev otomasyonu eklentisi. Bu paket genellikle kendi AdGuard Home YAML kopyasını içerir ve işlemi kendi planına göre yeniden başlatır; oysa bağımsız bir örnek, sizin yapılandırdığınız satıcı ikili dosyası veya konteynerdir. Her durumda, aynı üst akış listesi ve aynı filtre listelerini okusa bile, ayrı yapılandırma dosyaları ve ayrı bağlama seçenekleri olan iki bağımsız süreçle karşı karşıyasınız. Biri belirli tünel adresine bağlanabilirken, diğeri joker karakteri devralır ve web arayüzü her iki tarafta da aynı görünür.

İşte bu yüzden "aynı çözücü göçten önce çalışıyordu" ifadesi, mevcut bağlama dair hiçbir şey kanıtlamaz. Soketi kontrol edin, sonra çalışan işlemin gerçekten yüklediği yapılandırma dosyasını kontrol edin. Başka bir dizindeki eski bir kopya, düzenlemenin hiç etkisi olmadığı izlenimini vermesinin yaygın bir nedenidir.

Onu sabitleyin, sonra tünel tarafından test edin

Değiştirbind_hoststünel adresine, servisi yeniden başlatın ve soketin taşındığını onaylayın:ss -lunp | grep :53şimdi göstermeli10.6.0.1:53ve joker karakter girişi yok. Hâlâ gösteriyorsa0.0.0.0,çalışan süreç, düzenlediğiniz dosyayı okumuyor.

O zaman istemciden test yapın, çünkü önemli olan tek taraf odur. Bir sorgu iledig @10.6.0.1 example.comkullanıcının yaptığı yolu egzersiz yapar ve ev sahipliğinde bir yakalama iletcpdump -ni wg0 udp port 53yanıtın kabloda kaynak adresini gösterir. Bunu istemcinin çözümleyici ayarındaki adresle karşılaştırın; eşit olduklarında, zaman aşımı artık gizem olmaktan çıkar.

ip route get 10.6.0.2kalan herhangi bir tuhaflığı açıklar, çünkü istemciye geri gönderilecek arayüzü ve kaynağı yazdırır. Bu çıktıda LAN arayüzü belirtilmişse, bağlama değişikliği tüm düzeltme değildir ve okunacak bir sonraki şey yönlendirme tablosudur.

Bağlama ayarının düzeltemediği şey

Dinleyiciyi sabitlemek, tünel alt ağını dışarıda bırakan bir erişim listesini, sorguya izin verip yanıta izin vermeyen bir güvenlik duvarı kuralını veya WireGuard havuzuna geri dönüş için eksik bir rotayı onarmaz. Bunlar kaynak adresinden önce veya sonra başarısız olur ve her birinin farklı bir sahibi vardır.

Ayrıca değiştirmezçözümleyicinin ileriye hangi üst sunucuya gönderdiğini, özel bir ad için özel bir yanıtı reddedip reddetmediğini veya istemcinin kendi arama alanlarını nasıl uyguladığını. Bunlar ayrı kontrollerdir. Yanıt kaynağı yanlış olduğunda bağlama adresini değiştirin ve yanlış olmadığında başka bir şeyi değiştirin.

İlgili makaleler