AdGuard Home адказвае кліентам WireGuard з вашага LAN-адрасу

Тунэль працуе, файрвол дазваляе порт 53, AdGuard Home працуе, але имёны ўсё яшчэ не вырашаюцца для кліента WireGuard. Запыт паступае нармальна, адказ адпраўляецца нармальна, таму лічыльнікі пакетаў на рэзалверы паказваюць здаровую актыўнасць, і сэрвіс выглядае бязвінна. Праблема ў зыходным адрасе адказу: ён адпраўляецца з лакальнага адраса, які кліент ніколі не запытаў, і рэзалвер кліента ігнаруе яго. Адзін спіс у канфігурацыі AdGuard Home вызначае гэта, і звычайны стандарт перадае рашэнне ядру.

Запыт прыходзіць, адказ сыходзіць з іншага месца

Кліент, настроены з 10.6.0.1 у якасці свайго рэзалвера, адпраўляе UDP-запыт на 10.6.0.1 порт 53. Гэты пакет праходзіць праз тунэль і трапляе на хост, і AdGuard Home адказвае на яго. Але ў сетцы адказ становіцца новым пакетам, чый зыходны адрас выбіраецца стеку хоста, а не чакаемым ад кліента.

Калі рэзалвер кліента з'яўляецца падключаным сокетам, што выкарыстоўваецца systemd-resolved, dnsmasq і большасцю стамб-рэзалвераў, ён прымае толькі адказы з таго ж дакладнага адрасу, на які быў адпраўлены запыт. Адказ з крыніцай 192.168.1.10 на запыт, адпраўлены на 10.6.0.1, адкідваецца яшчэ да разбору. Рэзалвер запісвае паспяховы адказ, кліент лагуе тайм-аут, і абодва кажуць праўду.

Такім чынам, лічыльнікі не блуняць і кліент таксама не блуняць. Доказ, які вам патрэбны, знаходзіцца ў трох месцах у наступным парадку: адрас, да якога прывязаны слухач, маршрут, які ядро ​​вылучыць назад да кліента, і адрас крыніцы ў рэальным пакеце адказу.

Як ядро ​​выбірае крыніцу адказу

UDP-сокет, прывязаны да0.0.0.0не мае ўласнага адраса крыніцы, таму кожны выходны адказ выклікае пошук маршруту да адраса прызначэння. Затым ядро ​​бярэ адрас крыніцы з гэтага маршруту: адрас, прывязаны маршрутам, або асноўны адрас выхаднога інтэрфейсу. Нічога пра адрас прызначэння запыту не запамінаецца.

На хосте з адным дамашнім адрасам гэта невідочна, бо ёсць толькі адзін слушны адказ. На машыне з LAN-адрасам, адрасам WireGuard і адміністрацыйным адрасам магчымыя некалькі адказаў, і выбар залежыць ад табліцы маршрутаў на дадзены момант. Дадайце дадатковы маршрут, другі адрас на тым жа інтэрфейсе, перанакіраванне NAT перад рэзалверам або запусціце AdGuard у кантэйнеры з уласным прасторам імёнаў, і выбраны крыніца можа адрознівацца ад таго, што запытаў кліент.

ss -lunp | grep :53паказвае, у якой гульні вы знаходзіцеся. Слухач на0.0.0.0:53з'яўляецца ўзорам для ўсіх выпадкаў; слухач на10.6.0.1:53ужо замацаваў адказ. Чытанне сокета хутчэйшае за чытанне YAML і адлюстроўвае тое, што сапраўды працуе, а не тое, што было апошнім захаваўся.

Што фактычна кантралюе bind_hosts

AdGuard Homedns.bind_hostsгэты спіс лакальных адрасоў, якія выкарыстоўвае DNS-слухач. Па змоўчанні дастаўляецца універсальны адрас, што азначае прыняць на любым лакальным адрасе і дазволіць ядру выбраць крыніцу для кожнага адказу. Замена універсальнага адраса на адрас, па якім кліенты робяць запыт, змяняе сокет і з ім крыніцу на кожны адказ.

Спіс можа ўключаць некалькі запісаў, што важна для рэзалвера, які абслугоўвае дзве сеткі. Уключэнне10.6.0.1і192.168.1.10дае два звязаныя сокеты, і запыт, які паступае на любы з іх, адказваецца з таго адраса, на які ён паступіў. Гэта паводзіны, якое многія ўжо чакаюць ад універсальнага адраса.

YAML просты, і адрас у ім — гэта той, які быў паведамлены вашым тунельным кліентам, а не асноўны адрас хоста:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Чаму дзве ўсталёўкі аднаго рэзалвера не супадаюць

Кіраваны плагінам, у гэтым кантэксце, азначае, што рэзалютар быў усталяваны і кантралюецца іншым пакетам: пакетам прашыўкі маршрутызатара, пакетам NAS або дапаўненнем аўтаматызацыі дома. Звычайна гэты пакет дастаўляе ўласную копію YAML AdGuard Home і перазапускае працэс па ўласным раскладзе, у той час як асобны інстанс — гэта бінарны файл або кантэйнер вытворцы, які вы наладжваеце самі. У любым выпадку вы маеце справу з двума незалежнымі працэсамі з асобнымі файламi канфігурацый і асобнымі выбарамі сувязі, нават калі абодва чытаюць той самы спіс upstream і тыя ж фільтруючыя спісы. Адзін можа звязаць канкрэтны тунэльны адрас, у той час як другі атрымлівае універсальны адрас, а вэб-інтэрфейс выглядае ідэнтычна з абодвух бакоў.

That is why "the same resolver worked before the migration" proves nothing about the current binding. Check the socket, then check the configuration file the running process actually loaded. A stale copy in another directory is a common reason the edit appears to have no effect.

Pin it, then test from the tunnel side

Changebind_hoststo the tunnel address, restart the service, and confirm the socket moved:ss -lunp | grep :53should now show10.6.0.1:53and no wildcard entry. If it still shows0.0.0.0,the running process is not reading the file you edited.

Then test from the client, because that is the only side that matters. A query withdig @10.6.0.1 example.comexercises the path the user exercises, and a capture on the host withtcpdump -ni wg0 udp port 53паказвае зыходны адрас адказу ў сетцы. Параўнайце яго з адрасам у настройках рэзалвера кліента; калі яны роўныя, тайм-аут перастае быць загадкай.

ip route get 10.6.0.2тлумачыць любыя астатнія дзіўнасці, бо выводзіць інтэрфейс і крыніцу, якую хост выкарыстае для адказу кліенту. Калі гэты вывад паказвае інтэрфейс LAN, змена біндзіравання не з’яўляецца поўным рашэннем, і наступным крокам будзе чытанне маршрутызацыйнай табліцы.

Што нельга выправіць настройкай біндзіравання

Прыкрэпленне слухача не выпраўляе спіс доступу, які не ўключае падсетку тунэля, правіла файрвола, якое дазваляе запыт, але не адказ, або адсутны маршрут назад да пула WireGuard. Гэтыя памылкі ўзнікаюць раней ці пазней за зыходны адрас, і кожная мае іншага ўладальніка.

Гэта таксама не змяняеда каго рэзалвер перасылае вышэй, ці адхіляе абарона пры перазвязыванні прыватны адказ для прыватнага імя, ці як кліент выкарыстоўвае ўласныя дамены пошуку. Гэта асобныя элементы кіравання. Змяняйце адрас прывязкі, калі крыніца адказу няправільная, і змяняйце нешта іншае, калі яна правільная.