Дайте на домашния си VPN собствени DNS записи за nas.home.arpa

Публикувайте едно име от dnsmasq, насочете резолвера през WireGuard, после изберете между изпращане на DNS към целия клиент и split-DNS само за home.arpa.

След като тунелът е вдигнат, последната стъпка обикновено е име, което работи, вместо адрес, който поставяте в отметка. Запис за хост в dnsmasq плюс адрес на резолвер, до който клиентът достига, прави това с два файла и без multicast. Решението, което наистина изисква размисъл, е по-тясно: дали клиентът изпраща целия DNS през домашния резолвер, или само имената под home.arpa? Всичко по-долу предполага одобрена настройка на WireGuard с клиент Linux и лабораторен резолвер, който домашният администратор вече управлява.

Три начина да дадете на клиента резолвер

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

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

Публикувайте записа при резолвера, който притежава зоната

Дръжте ролите разделени, преди да пишете конфигурация: адресът на VPN клиента, резолверът и услугата са три различни хоста с три различни задачи. В тази лаборатория те са 10.77.0.2 за клиента, 192.168.50.53 за dnsmasq и 192.168.50.20 за NAS, като тунелът маршрутизира домашната LAN.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

Редът host-record дава адреса, а редът local= задържа непознатите въпроси за home.arpa в този резолвер, вместо да ги препраща нагоре. Прочетете първо съществуващата конфигурация и съгласувайте всичко, което вече дефинира сървър, интерфейс или същия локален домейн; надграждането на фрагмент върху конфликтен дава резолвер, който се зарежда спокойно и отговаря грешно. Ръководството на dnsmasq дефинира двете директиви и контролите за слушане.

След това проверете работещата услуга, а не файла. Тест на конфигурацията плюс рестарт е минимумът, а ефективният отговор е това, което връща заявката.

Маршрутизирайте резолвера, не само уеб страницата

AllowedIPs на WireGuard решава кои дестинации влизат в тунела. Ако адресът на резолвера е извън него, заявката излиза по нормалния маршрут и никога не достига до dnsmasq, въпреки че самият NAS е достъпен. Включете адреса на резолвера или LAN префикса, който го съдържа, и проверете политиката за препращане на шлюза от другата страна.

Разрешете UDP и TCP на порт 53 от оторизирания диапазон на тунела, с обратен път към адреса на тунела на клиента. Не препращайте порт 53 от WAN, за да улесните тестването: отворен рекурсивен резолвер на домашна връзка се открива в рамките на часове. Свързването с интерфейс не е политика за достъп само по себе си.

Проверете отговора преди приложението

Първо попитайте резолвера директно, после системата, после приложението. Всяка стъпка изолира едно звено от веригата, а разликата между тях е диагнозата.

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

TCP заявката си заслужава да се изпълни, защото отрязан UDP отговор налага повторен опит, а политика, която изхвърля TCP 53, създава откази, които изглеждат периодични. Стъпката getent показва какво всъщност прави конфигурацията на резолвера на машината, което не винаги е това, което сте изпратили.

Решете какво се случва, когато тунелът не работи

Ако общият DNS на клиента сочи към 192.168.50.53, всяко разрешаване на имена спира, когато тунелът не е вдигнат. Това е приемливо на машина, която е полезна само с тунела, и неприемливо на лаптоп, който използва и Wi-Fi в кафене. Split-DNS избягва въпроса напълно, защото само търсенията на home.arpa зависят от домашния резолвер.

Запомнете какво е името: home.arpa е запазено за жилищни мрежи и не е глобално уникално, така че друга мрежа може законно да използва същото име. Това е местно удобство, а не надежден идентификатор. Поддържайте записа актуален, когато услугата се мести, и премахнете политиката на резолвера, когато лабораторията се изведе от експлоатация, вместо да оставите лаптоп, сочещ към адрес, до който достига само през тунел, който вече не съществува.

Подобни статии