Файл рэзалвера macOS для лакальнага дамена побач з VPN

Ваш працоўны VPN ідэальна развязвае назвы кампаній, а прынтар дома застаецца недасяжным па назве, і звычайнае рашэнне, да якога звяртаюцца людзі, — накіраваць увесь Mac на хатні роўтар. Гэта значна большая змена, чым патрабуе праблема. macOS можа адправіць адзін суфікс DNS на ўласны сервер праз невялікі файл рэзалвера, пакідаючы кожны іншы запыт дакладна там, дзе ён быў.

Мяжа дазволаў ідзе першай: гэта для дамена, які вы адмініструеце або на наладжванне якога атрымалі дазвол. Гэта не маршрут у абыход абавязковай палітыкі DNS арганізацыі ці яе абмежаванняў лакальнай сеткі.

Адзін файл з вузкай задачай

Выкажам здагадку, што лакальная зона называецца lab.example.org і яе сервер адказвае на 192.168.55.1. На Mac, дзе вам дазволена ўнесці змену, адміністратар стварае звычайны тэкставы файл, імем якога з'яўляецца сам дамен, /etc/resolver/lab.example.org, які змяшчае адзін nameserver 192.168.55.1 радок. Каталога можа не існаваць у новай сістэме, таму стварыце яго з правамі адміністратара і паглядзіце перад запісам, ці ўжо не валодае праграма кіравання файлам там.

Канфігурацыя рэзалвера Apple дакументуе звычай, паводле якога імя файла задае дамен, калі ўнутры файла не з'яўляецца асобная налада дамена. Гэтае правіла наймення і ёсць увесь фокус, і менавіта таму файл трэба называць па зоне, а не па серверы.

Як macOS выбірае сярод рэзалвераў

Актыўнымі могуць быць больш за адзін кліент рэзалвера, і перамагае найбольш дакладны адпаведны дамен. Рэзалвер для lab.example.org мае таму іншую сферу дзеяння, чым рэзалвер па змаўчанні, а больш дакладны паддамен са сваім файлам можа зноў атрымаць перавагу. Менавіта гэта дазваляе працоўнаму VPN захаваць свой суфікс, пакуль ваша лабараторная зона ідзе ў іншае месца. Нішто ў гэтай схеме не з'яўляецца глабальным, і гэта варта запомніць.

Пакіньце /etc/resolv.conf у спакоі. macOS сам запісвае гэты файл, і ён ніколі не ўтрымліваў поўнай карціны развязання, спецыфічнага для дамена. Канфігурацыя таксама можа прыходзіць з базы даных сістэмнай канфігурацыі, а не з файлаў у гэтым каталогу, і менавіта таму профіль кіравання можа перакрыць напісанае вамі.

Тры рэчы, якіх файл не можа даць

Сервер павінен быць дасяжным. Калі VPN блакуе лакальную сетку, або карпаратыўны маршрут захоплівае дыяпазон адрасоў сервера, цалкам правільны файл суфікса ўсё роўна не зможа даставіць запыт. Перадайце гэта ўладальніку сеткі, а не пашырайце лакальныя выключэнні самастойна.

Зона павінна ўтрымліваць правільны адказ, і лепш за ўсё гэта правяраць цалкам кваліфікаваным імем, такім як printer.lab.example.org. Кароткае імя можа выклікаць паводзіны пошуку дамена і ў выніку задаць іншае пытанне, чым тое, якое вы мелі на ўвазе.

Нарэшце, праграма павінна мець магчымасць скарыстацца адказам. Развязанне імені прынтара не дае доступу да яго адраса і не адкрывае службу за ім. Атрыманы адрас усё яшчэ патрабуе дазволенага маршруту і палітыкі доступу, якая дазваляе злучэнне. Файл рэзалвера змяняе, дзе шукаецца імя; ён не рэзервуе шлях для выніку.

Праверце выбар, а не замяняйце DNS

Паглядзіце, што macOS фактычна выкарыстоўвае цяпер, і запытайце цалкам кваліфікаванае імя знутры самой праграмы або з інструмента, які развязвае так, як гэта робяць праграмы. Прамы запыт на 192.168.55.1 даказвае, што сервер адказвае; ён не даказвае, што macOS выбраў гэты сервер для звычайных пошукаў. Гэта розныя факты, і толькі другі апісвае тое, што адчуе ваш браўзер.

Калі іншы рэзалвер ужо заяўляе той самы суфікс, высветліце, каму ён належыць, перш чым дадаваць падказкі прыярытэту. Дакументаваная search_order налада ўпарадкоўвае кліентаў, якія падзяляюць дамен; гэта не глабальны перамыкач пераваг, які прымушае агульны рэзалвер перамагаць у кожным запыце.

Пацвердзіце, што назвы кампаній па-ранейшаму развязваюцца пры падключаным VPN, затым запішыце файл і яго прызначэнне ў свае лакальныя нататкі. Калі схема спыняе дзейнасць, выдаліце толькі гэты файл і пераправерце абедзве прасторы імёнаў, а не скідайце ўсе сеткавыя налады DNS.