Неге Pi-hole v6 WireGuard клиенттерінің DNS сұрауларын елемейді

Pi-hole v6 53 портында DNS сұрауын қабылдайды, содан кейін келген пакетке жауап беруге рұқсат бар-жоғын шешеді. WireGuard хосттарында бұл екінші шешім әдетте клиенттің неге уақыт шегіне тап болатынын түсіндіреді, ал шешуші LAN жағынан сау көрінеді. Порт ашық, FTL жұмыс істеп тұр, бірақ 10.90.0.1-ден ештеңе қайтпайды. Жауап шықпас бұрын үш нәрсе әрекеттеседі: dns.interface, dns.listeningMode және екеуінің алдындағы брандмауэр.

Тыңдаушы сокет кім жауап алатынын шешпейді

FTL 53 портында UDP және TCP тыңдаушыларын ашады. Әдепкі конфигурацияда сокет көбіне wildcard болады, сондықтан ss -lunp | grep :53 VPN клиенттеріне қызмет көрсетілсе де, көрсетілмесе де 0.0.0.0:53 және [::]:53 көрсетеді. wildcard сокет пакетті қабылдайды, содан кейін FTL жауап бермес бұрын интерфейс және көз ережелерін қолданады. Сондықтан «порт тыңдап тұр» деген сөз туннель клиенті туралы өте азды дәлелдейді.

Белсенді деп ойлайтын файлды емес, жұмыс істеп тұрған конфигурацияны оқыңыз. pihole-FTL --config dns.interface және pihole-FTL --config dns.listeningMode нақты мәндерді шығарады және контейнер, орта айнымалысы немесе орналастыру менеджері бұл параметрге ие болса, олар хост файлынан өзгеше болуы мүмкін. Pi-hole FTL конфигурация анықтамалығы режимдерді және олардың қайсысы интерфейске сүйенетінін тізімдейді.

LOCAL қай қосымша желіні, SINGLE қай интерфейсті сұрайды

LOCAL, әдепкі режим, көз мекенжайы хосттың бір интерфейсінде конфигурацияланған қосымша желіге жататын сұрауларға жауап береді. 10.90.0.1/24 бар қарапайым wg0 бұл сынақтан өтеді, өйткені 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-ден қатаңырақ және оның синонимі емес. Баға жүктелу кезінде байқалады: егер FTL басталғанда wg0 көтерілмесе, байланыстыратын мекенжай болмауы мүмкін, және интерфейс пайда болып FTL қайта іске қосылғанша шешуші тыңдаушысыз жұмыс істей алады.

Іске қосу тәртібін бақылайтын болсаңыз BIND таңдаңыз, мысалы WireGuard интерфейсінен кейін реттелген systemd бірлігі, және ядро FTL көрмес бұрын адасқан пакеттерді тастағанын қаласаңыз. Туннель келіп-кететін болса немесе интерфейсті FTL-ден кейін басталатын құрал жасаса, SINGLE таңдаңыз.

Брандмауэр — екінші қақпа

Дұрыс FTL режимі де хост брандмауэры wg0-де 53 портын тастаса, сәтсіз болады. Екі протокол үшін VPN көз ауқымын рұқсат етіп, интернет жағын жабық ұстаңыз. nftables-те, inet filter кестесіндегі бар input тізбегімен, ережелер былай көрінеді:

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 ережелерін қосып, оларды тізбектің drop саясатының алдына қойыңыз. Егер хост 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 қайта пайда болғаннан кейін шешушінің әлі жауап беретінін растаңыз. Тек келесі қайта жүктеуге дейін жұмыс істейтін сұрау — аяқталған өзгеріс емес.