Чаму 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. Запыт, які працуе толькі да наступнай перазагрузкі, — не завершаная змена.