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 Home.dns.bind_hostsє списком локальних адрес, які використовує DNS-сервер. Стандартне значення, яке постачається, — це універсальна адреса (wildcard), що означає прийом на всіх локальних адресах і дозволяє ядру вибирати джерело для кожної відповіді. Замінюючи універсальну адресу на адресу, яку запитують клієнти, змінюється сокет, а разом із ним і адреса джерела у кожній відповіді.

Список може містити більше одного запису, що має значення для резольвера, який обслуговує дві мережі. Перерахування10.6.0.1і192.168.1.10дає два прив’язані сокети, і запит, що надходить на будь-який з них, відповідається з адреси, на яку він надійшов. Це та поведінка, яку більшість людей вважає стандартною для універсальної адреси.

YAML простий, і адреса в ньому — це та, яку вашим клієнтам тунелю повідомили використовувати, а не основна адреса хоста:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Чому два встановлення одного резольвера не погоджуються

У цьому контексті `керований плагіном` означає, що резольвер був встановлений і контролюється іншим пакетом: пакет прошивки маршрутизатора, пакет NAS або доповнення для домашньої автоматизації. Зазвичай цей пакет постачає власну копію YAML AdGuard Home і перезапускає процес за власним розкладом, тоді як автономний екземпляр — це двійковий файл або контейнер від постачальника, який ви налаштовуєте самостійно. У будь-якому випадку ви маєте дві незалежні процеси з окремими файлами конфігурації та окремими прив’язками, навіть якщо обидва читають той самий список upstream і ті самі списки фільтрів. Один може прив’язати конкретну адресу тунелю, тоді як інший успадковує універсальну прив’язку, і веб-інтерфейс виглядає однаково з обох сторін.

Ось чому «той самий резолвер працював до міграції» нічого не доводить щодо поточного прив'язування. Перевірте сокет, потім перевірте конфігураційний файл, який фактично завантажив запущений процес. Стара копія в іншому каталозі — поширена причина, чому редагування не приносить ефекту.

Закріпіть його, а потім перевірте з боку тунелю

Змінітьbind_hostsна адресу тунелю, перезапустіть службу і підтвердьте, що сокет перемістився:ss -lunp | grep :53тепер має показувати10.6.0.1:53і без універсального запису. Якщо все ще показує0.0.0.0,запущений процес не читає файл, який ви редагували.

Потім перевірте з боку клієнта, бо саме цей бік має значення. Запит ізdig @10.6.0.1 example.comтестує шлях, який використовує користувач, а захоплення на хості зtcpdump -ni wg0 udp port 53показує адресу джерела відповіді у мережі. Порівняйте її з адресою у налаштуваннях резольвера клієнта; коли вони збігаються, таймаут перестає бути загадкою.

ip route get 10.6.0.2пояснює будь-які залишкові незвичайності, тому що він виводить інтерфейс та джерело, які хост використовував би для повернення до клієнта. Якщо цей вивід називає LAN-інтерфейс, зміна прив’язки не є повним вирішенням, і наступне, що потрібно перевірити, це таблиця маршрутизації.

Що не може виправити налаштування прив’язки

Закріплення прослуховувача не виправляє список доступу, який пропускає підмережу тунелю, правило брандмауера, що дозволяє запит, але не відповідь, або відсутній маршрут назад до пулу WireGuard. Вони не працюють раніше або пізніше за адресу джерела, і кожен має свого власника.

Це також не змінюєдо якого upstream резольвер пересилає запит, чи відхиляє захист від переназначення приватну відповідь для приватного імені, або як клієнт застосовує власні пошукові домени. Це окремі механізми контролю. Змініть адресу прив'язки, коли джерело відповіді неправильне, і змініть щось інше, коли воно правильне.