Niyə Pi-hole v6 WireGuard müştərilərindən gələn DNS sorğularına məhəl qoymur

Pi-hole v6 53 portunda DNS sorğusu qəbul edir və sonra gələn paketin cavablandırılmasına icazə verilib-verilmədiyini müəyyən edir. WireGuard hostunda bu ikinci qərar adətən müştərinin niyə timeout aldığını izah edir, halbuki resolver LAN-dan sağlam görünür. Port açıqdır, FTL işləyir, amma 10.90.0.1-dən heç nə qayıtmır. Cavab çıxmazdan əvvəl üç şey qarşılıqlı təsir edir: dns.interface, dns.listeningMode və hər ikisinin qarşısındakı firewall.

Dinləyən soket kimin cavab alacağına qərar vermir

FTL 53 portunda UDP və TCP dinləyiciləri açır. Standart konfiqurasiyada soket çox vaxt wildcard olur, ona görə ss -lunp | grep :53 0.0.0.0:53 və [::]:53 ünvanlarını göstərir, VPN müştərilərinə xidmət olunsun ya olunmasın. Wildcard soket paketi qəbul edir, sonra FTL cavab verməzdən əvvəl interfeys və mənbə qaydalarını tətbiq edir. Buna görə "port dinlənir" ifadəsi tunel müştərisi haqqında çox az şey sübut edir.

Aktiv hesab etdiyiniz fayl yerinə işləyən konfiqurasiyanı oxuyun. pihole-FTL --config dns.interface və pihole-FTL --config dns.listeningMode faktiki dəyərləri göstərir və onlar host faylından fərqlənə bilər, çünki konteyner, mühit dəyişəni və ya yerləşdirmə meneceri bu parametri idarə edir. Pi-hole FTL konfiqurasiya arayışı rejimləri və hansının interfeysə bağlı olduğunu sadalayır.

LOCAL hansı subneti, SINGLE hansı interfeysi soruşur

Standart olan LOCAL, mənbə ünvanı host interfeyslərindən birində konfiqurasiya edilmiş subnetə aid olan sorğulara cavab verir. 10.90.0.1/24 ilə sadə wg0 bu testi keçir, çünki 10.90.0.2-dəki müştəri tunel subnetinin içindədir. Peer-in o biri tərəfində marşrutlaşdırılmış müştəri, ya da fərqli prefiksdə NAT arxasında gizlənən müştəri, paket wg0-a gəlsə də bu testi keçmir və jurnalda heç bir sorğu görünmür.

SINGLE sualı dəyişir. O, dns.interface ilə adlandırılan interfeysdə gələn sorğuları qəbul edir, loopback daxil olmaqla, və mənbə subnetini nəzərə almır. Zəncirlənmiş və ya marşrutlaşdırılmış VPN topologiyasında işləyən rejim budur. Hər iki açarı birlikdə təyin edin, çünki adı çəkilməyən interfeyssiz rejim tam təlimat deyil:

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

BIND soketi dəyişir və bunun bir qiyməti var

BIND wildcard soketi filtrləmir; 53 portunu yalnız adlandırılmış interfeysdə mövcud olan ünvanlara bağlayır, ona görə kernel başqa yerə gələn paketləri rədd edir. O, SINGLE-dan daha sərtdir və onun sinonimi deyil. Qiymət açılışda görünür: FTL başlayanda wg0 qalxmırsa, bağlanacaq ünvan olmaya bilər və interfeys görünüb FTL yenidən başlayana qədər resolver dinləyicisiz işləyə bilər.

BIND-i başlama sırasına nəzarət etdiyiniz halda seçin, məsələn WireGuard interfeysindən sonra sıralanmış systemd unit-i ilə, və kernelin kənar paketləri FTL görəməzdən əvvəl atmasını istədikdə. SINGLE-ı tunel gəlib-getdikdə və ya interfeys FTL-dan sonra başlayan alətlə yaradıldıqda seçin.

Firewall ikinci qapıdır

Düzgün FTL rejimi də host firewall-u wg0 üzərində 53 portunu atırsa uğursuz olur. Hər iki protokol üçün VPN mənbə aralığına icazə verin və internet tərəfini bağlı saxlayın. nftables-da, inet filter cədvəlindəki mövcud input zənciri ilə qaydalar belə 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

Tunel IPv6 daşıyırsa uyğun IPv6 qaydaları əlavə edin və onları zəncirin drop siyasətindən əvvəl yerləşdirin. Host ufw və ya firewalld istifadə edirsə, alətləri qarışdırmaq əvəzinə eyni uyğunluğu həmin menecerdə ifadə edin. 53 portunu internet marşrutlaşdırıcısından yönləndirməyin; müştərilər resolverin VPN ünvanına tunel vasitəsilə çatmalıdır.

İki yol ayrı qalır. Müştəri sorğuları FTL-da bitir. FTL-in öz upstream axtarışları host marşrutlaşdırma cədvəlinə uyğun çıxır və bu cədvəl tuneldən istifadə edə bilər və ya etməyə bilər, ona görə cavab verən amma faydalı heç nə qaytarmayan resolver upstream problemidir. Veb admin və API öz portlarında dinləyir və öz məhdudiyyətlərinə ehtiyac duyur.

Cavabı və imtinanı yoxlayın

VPN müştərisindən resolver ünvanına hər iki protokol üzrə sorğu göndərin: dig @10.90.0.1 example.com və dig +tcp @10.90.0.1 example.com. Sonra FTL-in sorğunu qeyd etdiyini təsdiqləmək üçün admin interfeysindəki sorğu jurnalına baxın. Jurnalda qeyd olmadan müştəri timeout-u firewall və ya interfeys filtrinə işarə edir; cavabsız jurnal qeydi isə upstream həllinə işarə edir.

Mənfi yolu VPN-dən kənar bir hostdan yoxlayın. dig @10.90.0.1 example.com timeout verməlidir və ss -lunp resolverdə 53 portunun publik ünvana bağlı görünməməlidir. Xidməti bir dəfə yenidən başladın, sonra hostu yenidən yükləyin və wg0 yenidən göründükdən sonra resolverin hələ də cavab verdiyini təsdiqləyin. Yalnız növbəti yenidən yükləməyə qədər işləyən sorğu bitmiş dəyişiklik deyil.