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 и повечето stub резолвери, той приема само отговори от точно адреса, към който е изпратил заявката. Отговор, идващ от 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'sdns.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 и рестартира процеса според собственото си разписание, докато самостоятелният екземпляр е бинарният файл или контейнерът на доставчика, който конфигурирате сами. По всякакъв начин имате предвид два независими процеса с отделни конфигурационни файлове и отделни избори за свързване, дори когато и двата използват един и същ списък на 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 интерфейса, промяната на bind не е цялото решение и следващото нещо за проверка е таблицата за маршрутизиране.

Какво не може да поправи настройката на bind

Закрепването на слушателя не ремонтира списък за достъп, който пропуска тунелната подмрежа, правило на защитната стена, което разрешава заявката, но не и отговора, или липсващ маршрут обратно към WireGuard пула. Те не успяват по-рано или по-късно от изходния адрес и всеки има различен собственик.

Също така не променякъм кой upstream резолверът препраща, независимо дали защитата срещу препосочване отхвърля частен отговор за частно име, или как клиентът прилага собствените си търсещи домейни. Това са отделни контролни елементи. Променете адреса на свързване, когато източникът на отговора е грешен, и променете нещо друго, когато не е.