Дайце сваёй хатняй VPN уласныя DNS-запісы для nas.home.arpa

Калі тунель узняты, апошні крок — звычайна імя, якое працуе, замест адрасу, які вы ўстаўляеце ў закладку. Запіс хоста ў dnsmasq плюс адрас рэзалвера, да якога кліент можа дасягнуць, робяць гэта двума файламі і без multicast. Рашэнне, якое сапраўды патрабуе роздуму, вузнейшае: ці кліент адпраўляе ўвесь DNS праз хатні рэзалвер, ці толькі імёны пад home.arpa? Усё ніжэй мяркуе ўзгодненую ўстаноўку WireGuard з кліентам Linux і лабараторным рэзалверам, якім хатні адміністратар ужо кіруе.

Тры спосабы даць кліенту рэзалвер

Для ноўтбука, які час ад часу далучаецца да тунеля, 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 зарэзервавана для жылых сетак і не з'яўляецца глабальна унікальным, таму іншая сетка можа цалкам законна выкарыстоўваць тое ж імя. Гэта лакальная зручнасць, а не надзейны ідэнтыфікатар. Трымайце запіс актуальным, калі сэрвіс пераязджае, і выдаляйце палітыку рэзалвера, калі лабараторыю выводзяць з эксплуатацыі, замест таго каб пакідаць ноўтбук, які паказвае на адрас, да якога ён можа дасягнуць толькі праз тунель, якога ўжо няма.