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 се отфрла пред да започне било какво парсирање. Резолверот бележи успешен одговор, клиентот бележи време на истекување, и двата прикажуваат точни информации.

Значи, броилките не лажат и клиентот исто така не лажe. Доказите што ви се потребни се на три места, во овој редослед: адресата на која слушателот е поврзан, рутата што го користи јадрото за враќање кај клиентот и изворната адреса на вистинскиот пакет со одговор.

Како јадрото ја избира изворната адреса на одговорот

UDP приклучок поврзан со0.0.0.0нема своја изворна адреса, така што секој излегувачки одговор предизвикува пребарување на рута до дестинацијата. Јадрото потоа ја зема изворната адреса од таа рута: адресата која е забележана од рутата, или примарната адреса на излезниот интерфејс. Ништо во врска со адресата на дестинација на прашањето не се памети.

На хост со едно домаќинство ова е невидливо, бидејќи има само еден веројатен одговор. На машина што држи ЛАН адреса, 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 слушачот. Стандардниот испорачан е универзалниот знак, што значи дека прифаќа на секој локален адрес и дозволува јадрото да го избере изворот по одговор. Замена на универзалниот знак со адресата на која клиентите прашуваат го менува сокетот, и со него изворната адреса на секој одговор.

Листата може да има повеќе од една ставка, што е важно кај резолвер кој служи две мрежи. Листирање на10.6.0.1и192.168.1.10дава два поврзани сокети, и прашање кое пристигнува на кој било од нив се одговара од адресата на која пристигнало. Тоа е однесувањето кое повеќето луѓе го претпоставуваат дека универзалниот знак веќе го обезбедува.

YAML е едноставен, и адресата во него е таа која на вашите тунел клиенти им беше кажано да ја користат, а не примарната адреса на домаќинот:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Зошто две инсталации на еден резолвер се разликуваат

Управувано со приклучок, во овој контекст, значи дека резолверот бил инсталиран и се надгледува од друг пакет: пакет за рутер фирмвер, NAS пакет, или додаток за автоматизација на домот. Тој пакет обично го носи својот копија од YAML на AdGuard Home и го рестартира процесот според својот распоред, додека самостојната инстанца е бинарниот фајл или контејнерот на продавачот што го конфигурирате сами. Во секој случај, се работи за два независни процеси со одделни конфигурациски фајлови и одделни опции за поврзување, дури и кога двата читаат иста листа на извори и исти филтер листи. Едниот може да се поврзе на специфичната адреса на тунелот, додека другиот го наследува џокерот, а веб интерфејсот изгледа идентично од двете страни.

Затоа „истиот резолвер работеше пред миграцијата“ не докажува ништо за тековното поврзување. Проверете го сокетот, а потоа проверете ја конфигурациската датотека која ја вчитува тековниот процес. Застарена копија во друг директориум е чест причинител зошто уредувањето изгледа дека нема ефект.

Зацврстете го, а потоа тестирајте од страната на тунелот

Променете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

Зацврстувањето на слушателот не го поправа листата на пристап која го изоставува тунелскиот подсет, правилото на firewall кое го дозволува барањето но не и одговорот, или недостасувањето рута назад до WireGuard базенот. Тие не успеваат порано или подоцна од изворната адреса, и секој има различен сопственик.

Исто така, не ја менувана кој upstream резолверот го пренасочува, дали заштитата од повторно поврзување ја отфрла приватниот одговор за приватното име, или како клиентот ги применува своите сопствени домени за пребарување. Тоа се одделни контроли. Променете ја адресата на приврзување кога изворот на одговорот е погрешен и променете нешто друго кога не е.