AdGuard Home LAN мекенжайыңыздан WireGuard клиенттеріне жауап береді

Тоннель қосулы, брандмауэр 53 портты рұқсат етеді, AdGuard Home жұмыс істеп тұр, бірақ WireGuard клиенті үшін атаулар әлі де шешілмейді. Сұрау әдеттегідей келеді және жауап әдеттегідей шығады, сондықтан резолвердегі пакеттік есептегіштер қалыпты көрінеді және қызмет кінәсіз болып көрінеді. Дұрыс болмайтын нәрсе сол жауаптағы бастапқы адрес: ол клиент сұрамаған жергілікті адрестен шығады, және клиенттің stub резолвері оны лақтырып жібереді. AdGuard Home конфигурациясындағы бір тізім бұл шешімді қабылдайды, және оның әдеттегі әдепкі мәні шешімді ядроға қалдырады.

Сұрау келеді, жауап басқа жерден шығады

10.6.0.1 адресін өзінің шешушісі ретінде конфигурациялаған клиент 10.6.0.1 порт 53-ке UDP сұрауын жібереді. Сол пакет тоннель арқылы өтіп, хостқа жетеді, және AdGuard Home оған жауап береді. Алайда, желіде жауап — жаңа пакет болып табылады, оның бастапқы мекенжайын клиенттің күтуімен емес, хосттың стекі таңдайды.

Клиенттің шешушісі қосылған сокет болса, яғни systemd-resolved, dnsmasq және көбінесе басқа stub шешушілер қолданатын болса, ол тек дәл сол адреске жіберілген жауаптарды қабылдайды. 10.6.0.1 адресіне жіберілген сұрауға 192.168.1.10 адресінен келген жауап парсингке дейін жойылады. Шешуші табысты жауапты тіркейді, клиент уақыттың аяқталғанын тіркейді, және екеуі де шындықты айтып отыр.

Сондықтан есептегіштер өтірік айтпайды және клиент те өтірік айтпайды. Сізге қажет дәлел үш жерде болады, осы тәртіппен: тыңдаушыға бекітілген мекенжай, ядро клиентке қайту үшін қолданатын маршрут және нақты жауап пакеттегі бастапқы мекенжай.

Ядро жауап қайнарын қалай таңдайды

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_hostsDNS тыңдаушысы пайдаланатын жергілікті мекенжайлардың тізімі. Әдепкі жөнелтілген нұсқасы - бұл жалпы белгі (*), яғни барлық жергілікті мекенжайларда қабылдауды білдіреді және ядро әр жауапқа сәйкес мекенжайды таңдайды. Клиенттердің сұраған мекенжайымен жалпы белгіні ауыстыру сокетті өзгертеді және әр жауаптағы бастапқы мекенжайды өзгертеді.

Тізім бірден көп жазбаны қамти алады, бұл екі желіге қызмет көрсететін резольвер үшін маңызды.10.6.0.1және192.168.1.10тізімдерін беру екі байланған сокетті жасайды, және кез келген біріне келген сұрауға сол мекенжайдан жауап беріледі. Бұл көпшілік адамдардың жалпы белгінің бұрыннан да сол әрекетті қамтамасыз ететініне сенетіні сияқты мінез-құлық.

YAML қарапайым, және ол мекенжай сіздің туннель клиенттеріңізге қолдану үшін айтылған, хосттың негізгі мекенжайы емес:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Бір резольвердің екі орнатылуы неліктен келіспейді

Бұл контексте «плагин арқылы басқарылатын» дегеніміз, резолвер басқа пакет арқылы орнатылған және бақыланатын дегенді білдіреді: маршрутизатордың фирмалық бағдарламалық пакеті, NAS пакеті немесе үй автоматтандыру қосымшасы. Сол пакет әдетте өздігінен AdGuard Home-ның YAML көшірмесін жеткізеді және процесті өз кестесі бойынша қайта іске қосады, ал автономды нұсқауды сіз өзіңіз конфигурациялайтын сатушы бинарлық файлы немесе контейнер болып табылады. Дегенмен, екеуінде де жеке конфигурациялық файлдары және жеке байланыс параметрлері бар екі тәуелсіз процесс қарастырылады, тіпті екеуі де бір түпкі тізім мен бірдей сүзгі тізімдерін оқыса да. Біреуі нақты туннель мекенжайына байлануы мүмкін, ал екіншісі жұлдызшамен наследует алады, және веб-интерфейс екі жағынан да бірдей көрінеді.

Міне, сондықтан «сол шешуші бұрын көшіру алдында жұмыс істеген» дегеннің қазіргі байланыс туралы ешқандай дәлелі жоқ. Сокетті тексеріңіз, содан кейін жұмыс істеп тұрған процесс шын мәнінде жүктеген конфигурация файлын тексеріңіз. Басқа каталогтағы ескі көшірме өзгерістің әсері жоқ сияқты болғанының жиі себебі болып табылады.

Оны бекітіңіз, содан кейін туннель жағынан тексеріңіз

өзгертіңіз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 пулына қайта оралу үшін қажет маршруттың жоқтығын түзетпейді. Олар бастапқы мекенжайдан бұрын немесе кейін сәтсіз болады, және әрқайсысының өз иесі бар.

Сондай-ақ ол өзгерте алмайдышешуші қай жоғарғы серверге сұрау жолдайтынын, жеке атауға арналған жеке жауапты қайта байлау қорғауы қабылдамайтынын немесе клиент өзінің іздеу домендерін қалай қолданатынын білдіреді. Бұл бөлек басқарулар. Жауап көзі дұрыс болмаса, байлау мекенжайын өзгертіңіз, ал дұрыс болса, басқа нәрсені өзгертіңіз.