AdGuard Home одговара WireGuard клијентима са ваше LAN адресе
Веза на 0.0.0.0 омогућава кернелу да изабере извор одговора. На хосту са више мрежних интерфејса тај одговор може доћи са адресе до које тунел не може да стигне.
Тунел је успостављен, заштитни зид дозвољава порт 53, AdGuard Home ради, а имена и даље не могу да се разрешавају за WireGuard клијента. Уобичајено, упит стиже, а одговор нормално излази, тако да бројачи пакета на резолверу изгледају здраво и услуга делује невино. Оно што крене наопако је изворна адреса тог одговора: одлази са локалне адресе коју клијент никада није тражио, и клијентов stub резолвер га одбацује. Један списак у конфигурацији 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нема своју изворну адресу, тако да сваки излазни одговор покреће претрагу руте до одредишта. Језгро онда узима извор са те руте: адресу коју рута постави или примарну адресу излазног интерфејса. Ништа о адреси одредишта упита није запамћено.
На једно домаћинском хосту ово је невидљиво, јер постоји само један вероватан одговор. На машини која има ЛАН адресу, Адресу ВиреГуарда и управљачку адресу, неколико одговора је могуће, и победник зависи од табеле рутирања у том моменту. Додајте додатни пут, другу адресу на истом интерфејсу, НАТ пренамеравање испред резолвера, или покрените АдГуард у контејнеру са својим сопственим именским простором, и изабрани извор може се разликовати од оног који је клијент упитао.
ss -lunp | grep :53приказује у којој игри се налазите. Слушалац на0.0.0.0:53је случај универзалног симбола; слушалац на10.6.0.1:53је већ закључао одговор. Читање сокета је брже од читања ЈАМЛ-а и одражава оно што је заправо покренуто, а не оно што је последње сачувано.
Оно што bind_hosts заправо контролише
АдГуард Хоум-овdns.bind_hostsје списак локалних адреса које DNS слушалац користи. Подразумевано је послат знак глобалног замена (wildcard), што значи да прихвата на свакој локалној адреси и даје јединствену адресу извора по одговору. Замена wildcard-а адресом на коју клијенти шаљу упите мења сокет, а самим тим и адресу извора на сваком одговору.
Списак може да садржи више уноса, што је важно за резолвер који служи две мреже. Листинг10.6.0.1и192.168.1.10даје два повезана сокета, и упит који стигне на било који од њих се одговара са адресе на коју је стигао. То је понашање које већина људи претпоставља да wildcard већ пружа.
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објашњава све преостале чудности, јер штампа интерфејс и извор који би хост употребио назад ка клијенту. Ако тај излаз именује ЛАН интерфејс, промена привезивања није читаво решење и следећа ствар за читање је табела рутирања.
Шта подешавање привезивања не може да поправи
Фиксирање слушаоца не исправља листу приступа која изоставља тунел субнет, ни правило у заштитном зиду које дозвољава упит али не и одговор, нити недостајућу руту назад ка WireGuard пулу. То не успева раније или касније него адреса извора, и свака има другачијег власника.
Такође не мењака кому узстриму резолвер прослеђује, да ли заштита од поновног повезивања одбацује приватни одговор за приватно име, или како клијент примењује своје претраживачке домене. То су одвојене контроле. Промените адресу везе када је извор одговора погрешан, а промените нешто друго када није.