Pi-hole v6, WireGuard istemcilerinin DNS sorgularını neden yok sayıyor

Pi-hole v6, 53 numaralı bağlantı noktasında bir DNS sorgusu alır ve ardından gelen paketin yanıtlanmasına izin verilip verilmediğine karar verir. Bir WireGuard ana bilgisayarında bu ikinci karar, LAN'dan bakıldığında çözümleyici sağlıklı görünürken istemcinin neden zaman aşımına uğradığının olağan nedenidir. Bağlantı noktası açık, FTL çalışıyor, yine de 10.90.0.1'den hiçbir şey dönmüyor. Yanıt çıkmadan önce üç şey etkileşir: dns.interface, dns.listeningMode ve ikisinin önündeki güvenlik duvarı.

Dinleyen soket kimin yanıt alacağına karar vermez

FTL, 53 numaralı bağlantı noktasında UDP ve TCP dinleyicileri açar. Varsayılan yapılandırmada soket genellikle wildcard olur, bu yüzden ss -lunp | grep :53 VPN istemcilerine hizmet verilsin ya da verilmesin 0.0.0.0:53 ve [::]:53 gösterir. Wildcard soket paketi kabul eder, ardından FTL yanıt vermeden önce arayüz ve kaynak kurallarını uygular. Bu yüzden "bağlantı noktası dinliyor" ifadesi bir tünel istemcisi hakkında çok az şey kanıtlar.

Etkin olduğunu düşündüğünüz dosya yerine çalışan yapılandırmayı okuyun. pihole-FTL --config dns.interface ve pihole-FTL --config dns.listeningMode gerçek değerleri yazdırır ve bir kapsayıcı, ortam değişkeni veya dağıtım yöneticisi ayarın sahibi olduğunda bunlar ana bilgisayarın dosyasından farklı olabilir. Pi-hole FTL yapılandırma başvurusu modları ve bunlardan hangisinin arayüze dayandığını listeler.

LOCAL hangi alt ağı, SINGLE hangi arayüzü sorar

LOCAL, varsayılan mod, kaynak adresi ana bilgisayarın arayüzlerinden birinde yapılandırılmış bir alt ağa ait olan sorguları yanıtlar. 10.90.0.1/24 olan basit bir wg0 bu testi geçer, çünkü 10.90.0.2'deki istemci tünelin alt ağı içindedir. Eşin diğer tarafında yönlendirilmiş bir istemci, ya da başka bir önekte NAT arkasına gizlenmiş bir istemci, paket wg0'a gelmiş olsa da geçemez ve günlükte hiçbir sorgu görünmez.

SINGLE soruyu değiştirir. dns.interface içinde adlandırılan arayüze gelen sorguları loopback dahil kabul eder ve kaynak alt ağını yok sayar. Zincirlenmiş veya yönlendirilmiş bir VPN topolojisinde ayakta kalan mod budur. İki anahtarı birlikte ayarlayın, çünkü adlandırılmış arayüz olmadan bir mod tam bir talimat değildir:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND soketi değiştirir ve bunun bir bedeli vardır

BIND wildcard soketi filtrelemez; 53 numaralı bağlantı noktasını yalnızca adlandırılmış arayüzde var olan adreslere bağlar, bu yüzden çekirdek başka yere gelen paketleri reddeder. SINGLE'dan daha katıdır ve onun eşanlamlısı değildir. Bedel açılışta görünür: FTL başladığında wg0 yukarıda değilse bağlanacak adres olmayabilir ve arayüz görünüp FTL yeniden başlayana kadar çözümleyici dinleyicisiz çalışabilir.

Başlangıç sırasını kontrol ettiğinizde BIND seçin, örneğin WireGuard arayüzünden sonra sıralanmış bir systemd birimiyle, ve çekirdeğin başıboş paketleri FTL görmeden önce atmasını istediğinizde. Tünel gelip gittiğinde veya arayüzü FTL'den sonra başlayan bir araç oluşturduğunda SINGLE seçin.

Güvenlik duvarı ikinci kapıdır

Doğru bir FTL modu bile ana bilgisayarın güvenlik duvarı wg0 üzerinde 53 numaralı bağlantı noktasını atarsa başarısız olur. Her iki protokol için VPN kaynak aralığına izin verin ve internet tarafını kapalı tutun. nftables'ta, inet filter tablosundaki mevcut input zinciriyle kurallar şöyle görünür:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Tünel IPv6 taşıyorsa eşleşen IPv6 kuralları ekleyin ve bunları zincirin drop politikasından önce koyun. Ana bilgisayar ufw veya firewalld kullanıyorsa, araçları karıştırmak yerine aynı eşleşmeyi o yöneticide ifade edin. 53 numaralı bağlantı noktasını internet yönlendiricisinden iletmeyin; istemciler çözümleyicinin VPN adresine tünel üzerinden ulaşmalıdır.

İki yol ayrı kalır. İstemci sorguları FTL'de sonlanır. FTL'nin kendi üst akış aramaları ana bilgisayarın yönlendirme tablosuna göre çıkar, bu tablo tüneli kullanabilir ya da kullanmayabilir, bu yüzden yanıt veren ama işe yarar bir şey döndürmeyen bir çözümleyici üst akış sorunudur. Web yönetimi ve API kendi bağlantı noktalarında dinler ve kendi kısıtlamalarına ihtiyaç duyar.

Yanıtı ve reddi doğrulayın

Bir VPN istemcisinden çözümleyicinin adresini her iki protokolde sorgulayın: dig @10.90.0.1 example.com ve dig +tcp @10.90.0.1 example.com. Ardından FTL'nin sorguyu kaydettiğini doğrulamak için yönetim arayüzündeki sorgu günlüğüne bakın. Günlük kaydı olmadan istemci zaman aşımı güvenlik duvarına veya arayüz filtresine işaret eder; yanıtsız günlük kaydı üst akış çözümlemesine işaret eder.

Olumsuz yolu VPN dışındaki bir ana bilgisayardan test edin. dig @10.90.0.1 example.com zaman aşımına uğramalı ve ss -lunp çözümleyicide 53 numaralı bağlantı noktasının genel bir adrese bağlı olduğunu göstermemelidir. Hizmeti bir kez yeniden başlatın, sonra ana bilgisayarı yeniden başlatın ve wg0 yeniden göründükten sonra çözümleyicinin hâlâ yanıt verdiğini doğrulayın. Yalnızca bir sonraki yeniden başlatmaya kadar çalışan bir sorgu tamamlanmış bir değişiklik değildir.