Файл resolver macOS для локального домену поруч із VPN

Ваш робочий VPN чудово розв'язує назви компанії, а домашній принтер залишається недоступним за назвою, і звичайне рішення, до якого вдаються люди, — спрямувати весь Mac на домашній маршрутизатор. Це значно більша зміна, ніж потребує проблема. macOS може надіслати один DNS-суфікс на свій власний сервер через невеликий файл resolver, залишивши кожен інший запит точно там, де він був.

Спочатку межа дозволів: це для домену, яким ви керуєте або на налаштування якого маєте повноваження. Це не шлях в обхід примусової політики DNS організації чи її обмежень локальної мережі.

Один файл із вузьким завданням

Припустімо, локальна зона — lab.example.org, а її сервер відповідає на 192.168.55.1. На Mac, де вам дозволено внести зміну, адміністратор створює звичайний текстовий файл, ім'я якого збігається з самим доменом, /etc/resolver/lab.example.org, що містить один рядок nameserver 192.168.55.1. Цього каталогу може не бути в новій системі, тож створіть його з правами адміністратора і перед записом перевірте, чи не зайнятий там файл програмним забезпеченням керування.

Документація Apple щодо налаштування resolver описує конвенцію: ім'я файлу задає домен, коли всередині файлу немає окремого параметра домену. Це правило іменування і є вся хитрість, і саме тому файл має називатися за зоною, а не за сервером.

Як macOS вибирає між resolver

Активним може бути більше одного клієнта resolver, і перемагає найконкретніший відповідний домен. Тому resolver для lab.example.org має іншу область дії, ніж типовий resolver, а конкретніший піддомен із власним файлом знову може отримати пріоритет. Саме це дозволяє робочому VPN зберегти власний суфікс, поки ваша лабораторна зона йде в інше місце. Ніщо в цій схемі не є глобальним, і це варто запам'ятати.

Залиште /etc/resolv.conf у спокої. macOS сама записує цей файл, і в ньому ніколи не було повної картини розв'язання назв для конкретного домену. Налаштування може надходити й із системної бази конфігурації, а не з файлів у цьому каталозі, тому профіль керування може перекрити написане вами.

Три речі, яких файл не може дати

Сервер має бути доступним. Якщо VPN блокує локальну мережу або корпоративний маршрут перехоплює діапазон адрес сервера, навіть цілком правильний файл суфікса не зможе доставити запит. Зверніться з цим до власника мережі, а не розширюйте локальні винятки самостійно.

Зона має містити правильну відповідь, і найкраще перевіряти це повним ім'ям, наприклад printer.lab.example.org. Коротке ім'я може запустити поведінку доменів пошуку і зрештою поставити інше питання, ніж ви хотіли.

Нарешті, застосунок має мати змогу використати відповідь. Розв'язання імені принтера не дає доступу до його адреси і не відкриває службу за нею. Поверненій адресі все ще потрібен дозволений маршрут і політика доступу, що дозволяє з'єднання. Файл resolver змінює місце, де шукається ім'я; він не резервує шлях для результату.

Перевіряйте вибір, а не замінюйте DNS

Перевірте, що macOS насправді використовує зараз, і запитайте повне ім'я зсередини самого застосунку або з інструмента, що розв'язує так само, як застосунки. Прямий запит до 192.168.55.1 доводить, що сервер відповідає; він не доводить, що macOS обрала цей сервер для звичайних пошуків. Це різні факти, і лише другий описує те, що відчує ваш браузер.

Якщо інший resolver уже претендує на той самий суфікс, з'ясуйте, кому він належить, перш ніж додавати підказки пріоритету. Задокументований параметр search_order упорядковує клієнтів, які поділяють домен; це не глобальний перемикач переваги, що змушує загальний resolver вигравати кожен запит.

Переконайтеся, що назви компанії все ще розв'язуються з під'єднаним VPN, потім запишіть файл і його призначення у свої локальні нотатки. Коли схему згортають, видаліть лише цей файл і повторно перевірте обидва простори імен, а не скидайте всі DNS-налаштування мережі.