Зошто Pi-hole v6 ги игнорира DNS барањата од WireGuard клиентите

Pi-hole v6 прима DNS барање на портата 53 и потоа одлучува дали пакетот што пристигнал смее да добие одговор. На WireGuard домаќин таа втора одлука обично е причината зошто клиентот добива истек на времето, додека резолверот изгледа здраво од LAN. Портата е отворена, FTL работи, а сепак ништо не се враќа од 10.90.0.1. Три работи дејствуваат заедно пред одговорот да излезе: dns.interface, dns.listeningMode и огнениот ѕид пред двете.

Слушачкиот сокет не одлучува кој добива одговор

FTL отвора UDP и TCP слушачи на портата 53. Во стандардната конфигурација сокетот често е wildcard, па ss -lunp | grep :53 покажува 0.0.0.0:53 и [::]:53 без оглед на тоа дали се опслужуваат VPN клиенти. Wildcard сокетот го прифаќа пакетот, потоа FTL ги применува своите правила за интерфејс и извор пред да одговори. Затоа фразата „портата слуша“ докажува многу малку за клиент на тунел.

Читајте ја конфигурацијата што работи, а не датотеката што мислите дека е активна. pihole-FTL --config dns.interface и pihole-FTL --config dns.listeningMode ги печатат ефективните вредности и тие може да се разликуваат од датотеката на домаќинот кога контејнер, променлива на околината или менаџер за распоредување ја поседува поставката. Референца за конфигурација на Pi-hole FTL ги наведува режимите и кој од нив се потпира на интерфејсот.

LOCAL прашува која подмрежа, SINGLE прашува кој интерфејс

LOCAL, стандардниот режим, одговара на барања чија изворна адреса припаѓа на подмрежа конфигурирана на еден од интерфејсите на домаќинот. Едноставен wg0 со 10.90.0.1/24 го поминува тој тест, бидејќи клиентот на 10.90.0.2 седи во подмрежата на тунелот. Клиент со рутирање од другата страна на партнер, или клиент скриен зад NAT во друг префикс, не го поминува, иако пакетот пристигнал на wg0, и во дневникот не се појавува ниту едно барање.

SINGLE го менува прашањето. Ги прифаќа барањата што пристигнуваат на интерфејсот наведен во dns.interface, вклучувајќи loopback, и ја игнорира изворната подмрежа. Тоа е режимот што издржува верижна или рутирана VPN топологија. Поставете ги двата клуча заедно, бидејќи режим без наведен интерфејс не е целосна инструкција:

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

BIND го менува сокетот и тоа има цена

BIND не филтрира wildcard сокет; ја врзува портата 53 само со адреси што постојат на наведениот интерфејс, па јадрото ги одбива пакетите што пристигнуваат на друго место. Построг е од SINGLE и не е негов синоним. Цената се појавува при подигнување: ако wg0 не е подигнат кога FTL стартува, може да нема адреса за врзување, а резолверот може да работи без слушач додека интерфејсот не се појави и FTL не се рестартира.

Изберете BIND кога го контролирате редоследот на подигнување, на пример системска единица на systemd подредена по интерфејсот WireGuard, и кога сакате јадрото да ги отфрли заскитаните пакети пред FTL да ги види. Изберете SINGLE кога тунелот доаѓа и си оди, или кога интерфејсот го создава алатка што стартува по FTL.

Огнениот ѕид е втората порта

Точниот FTL режим сепак пропаѓа ако огнениот ѕид на домаќинот ја отфрли портата 53 на wg0. Дозволете опсегот на извори на VPN за двата протокола и држете ја интернетската страна затворена. Во nftables, со постоечкиот input ланец во табелата inet filter, правилата изгледаат вака:

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

Додадете соодветни IPv6 правила ако тунелот носи IPv6 и ставете ги пред политиката за отфрлање на ланецот. Ако домаќинот користи ufw или firewalld, изразете го истото совпаѓање во тој менаџер наместо да мешате алатки. Не проследувајте ја портата 53 од интернет рутерот; клиентите треба да ја достигнат VPN адресата на резолверот низ тунелот.

Две патеки остануваат одвоени. Барањата на клиентите завршуваат на FTL. Сопствените барања на FTL кон горниот тек излегуваат според табелата за рутирање на домаќинот, која може или не може да го користи тунелот, па резолвер што одговара но не враќа ништо корисно е проблем на горниот тек. Веб-администрацијата и API слушаат на сопствени порти и им треба сопствено ограничување.

Проверете го одговорот и одбивањето

Од VPN клиент, прашајте ја адресата на резолверот преку двата протокола: dig @10.90.0.1 example.com и dig +tcp @10.90.0.1 example.com. Потоа проверете го дневникот на барања во административниот интерфејс за да потврдите дека FTL го запишал барањето. Истек на времето кај клиентот без запис во дневникот укажува на огнениот ѕид или филтерот на интерфејсот; запис без одговор укажува на решавање на горниот тек.

Тестирајте ја негативната патека од домаќин надвор од VPN. dig @10.90.0.1 example.com треба да истече, а ss -lunp на резолверот не треба да покажува порта 53 врзана за јавна адреса. Рестартирајте ја услугата еднаш, потоа рестартирајте го домаќинот и потврдете дека резолверот и понатаму одговара откако wg0 пак ќе се појави. Барање што работи само до следното рестартирање не е завршена промена.