Внутренние DNS-имена через VPN: как открыть CRM по имени в офисе и дома

Менеджер пишет: «CRM не открывается». Вы просите попробовать адрес 10.20.0.15, и всё работает. Через минуту выясняется, что привычное имя crm.corp.example в браузере выдаёт «сайт не найден». Соблазн сказать «значит, сломался VPN» понятен, но он неточен: VPN, судя по открытому IP, как раз жив. Не работает что-то другое, и это «другое» нужно найти, а не лечить всё подряд.

В статье разберём одну ситуацию на учебном примере. Внутренний домен у нас corp.example, приложение называется crm.corp.example. Ноутбук сотрудника бывает в двух положениях: в офисной сети и дома, где он подключён через WireGuard-подобный VPN. Задача в том, чтобы в обоих случаях человек вводил один и тот же адрес и попадал в одно и то же приложение, хотя путь до него разный. Все адреса и имена здесь условные, они придуманы для объяснения и не описывают чью-либо реальную сеть.

Два вопроса, которые браузер задаёт подряд

Когда вы вводите имя в адресную строку, происходят два разных действия. Сначала система спрашивает: «Какой адрес у crm.corp.example?». Это поиск имени. Потом браузер открывает соединение с полученным адресом. Это передача трафика. Между ними нет ничего общего, кроме того, что результат первого действия служит входом второго.

Отсюда следует рабочий приём: сломаться может любой из двух шагов, и симптомы у них похожи («не открывается»), а лечение разное. Открытие по IP доказывает, что второй шаг в целом проходит: пакеты до приложения доходят, оно отвечает. Значит, подозрение падает на первый шаг. Но и здесь есть оговорка: первый шаг может завершиться «успешно», вернув не тот адрес. Тогда имя разрешилось, а приложение не открылось, и разговор о DNS бессмыслен, пока не проверено, куда этот адрес ведёт.

Поэтому у нас получается не два состояния («работает» и «не работает»), а четыре исхода:

• имя не разрешилось, адрес доступен, если ввести его вручную. Классическая картина нашей CRM;
• имя разрешилось в верный адрес, но соединение не проходит: проблема в маршруте или в правилах доступа;
• имя разрешилось в неверный адрес, например во внешний, потому что запрос ушёл публичному резолверу;
• имя разрешилось верно, соединение проходит, но приложение отвечает ошибкой. Это уже не сеть.

Исправный DNS не заменяет маршрут: можно получить идеальный ответ «10.20.0.15» и не иметь пути к этому адресу. Верно и обратное: безупречный маршрут не поможет, если имя никто не умеет превращать в адрес. Эти две части системы не знают друг о друге и не исправляют чужие ошибки.

Кто вообще знает про corp.example

Публичные DNS-серверы ничего не знают о corp.example. Это внутренняя зона, и отвечает за неё конкретный сервер, у которого есть записи вроде crm → 10.20.0.15. В нашем учебном примере это DNS-сервер офиса с адресом 10.20.0.2. Он может быть отдельной машиной, службой на роутере или контроллере домена, для примера это неважно. Важно то, что ответить на вопрос про внутреннее имя может только он (или его реплики), а любой посторонний резолвер скажет «такого имени нет».

Из этого вытекает неприятное следствие: «поменять DNS на другой» не решает задачу, о чём бы ни шла речь. Если ноутбук спрашивает не того, кто хранит зону, правильный ответ получить невозможно, как бы хорош ни был этот резолвер в остальном. Поэтому менять адрес DNS на ноутбуке наугад не нужно: сначала надо выяснить, к кому система обращается сейчас и должна ли она обращаться к другому.

Полезно задать себе три вопроса про саму зону, ещё не трогая клиентов:

1. Какой сервер авторитетно отвечает за corp.example?
2. Есть ли в зоне запись для crm и какой адрес она возвращает?
3. Если у сервера несколько интерфейсов, на какие из них он принимает запросы: только на офисный, или и на VPN-адрес тоже?

Третий вопрос часто забывают. DNS-служба может слушать лишь адрес в офисной подсети. Тогда из офиса всё работает, а через туннель запрос доходит до машины, но в ответ не приходит ничего: служба просто не принимает соединения на том интерфейсе, куда он пришёл. Снаружи это выглядит как таймаут, и легко принять его за «плохой маршрут».

Ноутбук в офисе: самый простой путь

В офисе ноутбук получает сетевые параметры по DHCP, и вместе с адресом приходит список DNS-серверов. Обычно это тот самый 10.20.0.2. Запрос про crm.corp.example уходит на него, приходит 10.20.0.15, браузер открывает соединение внутри локальной сети. Никакого VPN в цепочке нет, шлюзов тоже: оба узла в одной сети или за ближайшим внутренним роутером.

Отдельная мелочь касается коротких имён. Если люди привыкли набирать просто crm, это работает благодаря списку доменов поиска: к короткому имени система дописывает суффикс и получает crm.corp.example. В документации NetBird эти настройки описаны как Search Domains: они дополняют короткие имена (NetBird DNS). Это удобная привычка, но полагаться на неё стоит осознанно: короткое имя разрешается только пока суффикс есть в списке на конкретном клиенте. Полное имя такой зависимости не имеет, поэтому для инструкций сотрудникам и закладок надёжнее полное.

Тот же ноутбук дома

Дома картина другая. Домашний роутер выдаёт ноутбуку свой DNS, часто собственный адрес роутера вроде 192.168.1.1, который, в свою очередь, пересылает запросы провайдеру или публичному резолверу. Для него corp.example просто неизвестное имя. Поэтому при включённом туннеле, но неправильных настройках имён получается именно то, с чего мы начали: IP работает, имя нет.

Подключение к VPN само по себе добавляет только путь. Туннель создаёт интерфейс и таблицу направлений: куда класть пакеты, адресованные в офисную подсеть. В WireGuard эту роль играет параметр AllowedIPs: по справочной странице wg(8), он определяет, какие адреса допустимы во входящем трафике от peer и куда направляется исходящий, причём IPv4 и IPv6 перечисляются отдельно. Если там записана сеть 10.20.0.0/24, пакеты к 10.20.0.15 пойдут в туннель. Но где живёт сам DNS-сервер и каким резолвером пользуется ноутбук, этот параметр не решает. Он про адреса назначения, а не про имена.

Вот почему подключение туннеля и настройка имён — две разные работы. Первая отвечает на вопрос «как добраться», вторая на вопрос «кого спросить».

Что должно произойти, чтобы дома имя заработало

Нужны две вещи, и обе должны выполняться одновременно:

• запросы про corp.example должны уходить на офисный DNS 10.20.0.2, а не на домашний роутер;
• пакеты до 10.20.0.2 должны идти через туннель, то есть адрес сервера должен входить в маршрутизируемые через VPN сети.

Вторая часть настолько очевидна, что про неё забывают. Администратор прописывает клиенту «DNS через VPN: 10.20.0.2», а в AllowedIPs значится только подсеть, где живёт CRM, и адреса DNS-сервера там нет, потому что он в другой подсети офиса, например в управляющей. Запрос уходит не в туннель, а в обычный интернет через домашний роутер, где адрес 10.20.0.2 не значит ничего. Результат: таймаут и подозрение на DNS, хотя DNS в порядке, а виноват маршрут. И здесь тоже срабатывает развилка из начала: исправный DNS-сервер без пути к нему бесполезен.

Split DNS: отправлять в офис только то, что офисное

Теперь главный вопрос конфигурации: куда отправлять все остальные имена? Если направить через офисный DNS вообще всё, личные сайты сотрудника, обновления и видеозвонки станут зависеть от того, как офисный резолвер справляется с внешними именами, и от канала до офиса. Обычно так делать не хочется. Разумнее схема «разделённого DNS»: внутреннюю зону спрашивать у офиса, остальное у обычного резолвера.

В NetBird для этого есть понятия, которые хорошо ложатся на задачу. По документации NetBird DNS, Match Domains направляют запросы заданного домена к выбранному DNS-серверу, а primary nameserver обрабатывает остальные имена. Применительно к нашему примеру: для домена corp.example выбираем 10.20.0.2, а всё прочее остаётся там, где было. Как реализован split DNS в других клиентах, зависит от платформы и программы: идея та же, названия настроек и места их хранения разные, поэтому детали стоит сверять с документацией конкретного клиента.

В той же документации подчёркнуто, что NetBird DNS и адреса локальной сети — разные уровни конфигурации. Это ещё одна форма нашей главной мысли: настройка имён не создаёт маршрут, а маршрут не создаёт имена. Если вы выбрали сервер для домена, до этого сервера всё равно должен быть путь.

Таблица положений ноутбука

Третья строка таблицы и есть наш исходный симптом. Четвёртая показывает, что даже после правильной настройки остаются два места, где можно споткнуться, и оба связаны с тем, что DNS-сервер сам является узлом сети со своим адресом и своими правилами.

Проверяем по шагам, ничего не меняя

Порядок проверки такой, чтобы каждый шаг сужал круг подозреваемых. Конкретные команды зависят от операционной системы, поэтому опишем, что проверяется, а не как это называется в каждой оболочке.

1. Адрес приложения. Откройте CRM по IP. Если работает, соединение с приложением возможно, и маршрут до него есть хотя бы для этого адреса.
2. Адрес DNS-сервера. Проверьте, что 10.20.0.2 достижим из дома через туннель, например пробным обращением к нему. Если нет, чините маршрут: смотрите, входит ли адрес в AllowedIPs, и нет ли отдельной подсети, которую забыли добавить.
3. Ответ именно этого сервера. Задайте вопрос про crm.corp.example напрямую серверу 10.20.0.2, указав его явно. Если вернулся ожидаемый адрес, запись и служба в порядке. Если тишина, смотрите, слушает ли служба нужный интерфейс и пропускает ли файрвол запросы с адресов VPN.
4. Выбор резолвера системой. Задайте тот же вопрос без явного сервера, как это делает браузер. Если ответа нет, а прямой запрос работал, проблема в том, к кому система направляет запрос про эту зону: правило для домена не применилось или не выбран нужный интерфейс.
5. Результат в приложении. Когда имя вернуло верный адрес, откройте CRM по имени. Если не открывается, снова смотрите на адрес, на сертификат и настройки самого приложения.

Здесь есть тонкость, которая сначала удивляет: прямой запрос к серверу и обычное разрешение имени могут давать разные результаты. Это нормально, потому что первое обходит выбор резолвера, а второе его использует. Расхождение между ними как раз и показывает, где искать: между ними лежит только выбор резолвера и правила для домена.

Когда имя находится, а приложение не открывается

Отдельная группа проблем начинается после успешного ответа DNS. Запрос вернул 10.20.0.15, но страница не грузится. Тут снова полезно вернуться к двум вопросам из начала и спросить: куда именно ведёт полученный адрес из этого положения?

• Адрес в другой подсети, чем ожидалось. Бывает, что внутренний DNS отдаёт офисный адрес, а в туннеле нужна подсеть, которой нет в списке разрешённых адресов. Имя разрешено, пакеты не идут.
• Запись для двух сетей. Один и тот же сервис может иметь внутренний и внешний адреса. Если DNS отдаёт тот, что рассчитан на офис, домашнему клиенту он не подойдёт, пока не настроена отдельная логика ответов. Это уже решение уровня архитектуры, и принимать его стоит осознанно, а не добавлять вторую запись наугад.
• Ответ от приложения. Если соединение установилось, но видна ошибка сертификата или перенаправление на другое имя, сеть исправна, дело в настройках веб-сервера.

Про сертификат стоит сказать отдельно. Приложение по IP может открываться с предупреждением, а по имени без него, потому что сертификат выпущен на имя, а не на адрес. Это нормально и не связано с VPN. Но если вы привыкли открывать CRM по IP, не удивляйтесь, что именно имя становится первым настоящим тестом всей цепочки.

Как устроен ответ, когда в списке несколько DNS

Дома у ноутбука часто оказывается несколько DNS-серверов одновременно: домашний, который выдал роутер, и офисный, который добавил клиент VPN. Если правила для домена не заданы, система выбирает по собственной логике, и на разных платформах она отличается. Один и тот же ноутбук может иногда находить CRM, а иногда нет: когда первым спрошен офисный сервер, всё хорошо, когда домашний, ответ «имя не найдено». Такие плавающие симптомы пугают сильнее постоянных, хотя причина одна и та же.

Правило для домена эту неопределённость снимает: запрос про corp.example идёт на конкретный сервер, а не по очереди ко всем. Поэтому, если картина нестабильна, не стоит менять порядок серверов местами и надеяться. Надёжнее явно привязать зону к серверу и убедиться, что остальные имена продолжают работать как раньше.

Суффиксы и привычка писать коротко

Пользователи редко набирают полные имена. «crm» вместо crm.corp.example работает в офисе, где DHCP выдаёт список доменов поиска, и перестаёт работать дома, если туннель этот список не передал. Тогда сотрудник говорит: «В офисе открывается, дома нет», и это снова выглядит как проблема VPN. На самом деле отличается список суффиксов, а не туннель.

Как уже сказано, Search Domains в NetBird DNS дополняют короткие имена. Поэтому в клиенте, где такой список можно задать, домен corp.example стоит прописать и там. Но есть и более надёжный путь: приучить людей к полному имени и закладкам. Короткие имена удобны, пока их обеспечивает чужая настройка, и неудобны, когда она пропала. К тому же у короткого имени есть риск неоднозначности: если в списке несколько суффиксов, одно и то же слово может превратиться в разные адреса.

Что менять нельзя, пока не понятна причина

Несколько действий выглядят как лечение, но маскируют проблему:

• Добавить запись в файл hosts на ноутбуке. Сработает, но только на этом ноутбуке, и когда адрес в DNS изменится, файл будет врать. Это временная заплатка, а не решение.
• Расширить список разрешённых адресов до всей сети. Это откроет больше, чем нужно, и не обязательно исправит имя. Лучше добавить ровно тот адрес или подсеть, которых не хватает.
• Отправить через VPN весь трафик ради одного имени. Это меняет поведение всех приложений на устройстве и нагружает канал, хотя достаточно правила для одной зоны.
• Заменить внутренний DNS публичным. Публичный резолвер не знает внутренних записей, и это сломает ту часть, которая работала.

Если конфигурацию туннеля приходится править на работающем сервере, помните про различие, о котором говорит wg(8): изменение работающего интерфейса и файла конфигурации — разные действия, а syncconf применяет разницу, не пересоздавая все peer. Если правка сделана только в файле, работающий интерфейс её не увидит, и наоборот: правка на лету пропадёт после перезапуска, если не попала в файл. И ещё одно предупреждение оттуда же: вывод wg showconf и машинный дамп могут содержать секреты, поэтому не вставляйте их в тикеты и чаты целиком, когда просите коллег помочь.

Где всё это живёт: роль сервера

Если офисного сервера с DNS и VPN-узлом нет или хочется вынести точку входа из офисной сети, ресурсы для этого скромные. Туннель и небольшой DNS-сервис не требуют многого, но точный запас по нагрузке зависит от числа клиентов и характера трафика, и его стоит определять тестом, а не угадыванием. Для пробы подойдёт VPS: у MAATRIX в предложении есть тарифы от Ba с 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe до более крупных, а на сервере доступен root-доступ (аренда VPS MAATRIX). Ресурсы плана — отправная точка, а не обещание ёмкости: сначала подключите несколько устройств и посмотрите, как ведёт себя ваш набор задач.

Важно и другое: сервер вне офиса только добавляет ещё один узел в цепочку. Если на нём находится VPN-точка, а DNS остаётся в офисе, путь до DNS должен существовать уже от этой точки. Мы снова возвращаемся к маршруту: каждое звено должно знать, как добраться до следующего.

Если же вы ещё выбираете, как подключать домашние устройства, и хотите, чтобы туннель был на роутере, а не на каждом ноутбуке, посмотрите разбор VPN на всех устройствах дома через один роутер. Там вопрос о том, где находится клиент туннеля, а имена остаются отдельной задачей и потребуют ровно тех же проверок.

Один адрес, два пути

Вернёмся к ноутбуку. В офисе он спрашивает 10.20.0.2 по локальной сети, получает 10.20.0.15 и открывает CRM по локальному пути. Дома он видит правило для corp.example, отправляет вопрос через туннель на тот же 10.20.0.2, получает тот же 10.20.0.15 и открывает CRM, на этот раз через VPN. Остальные имена в обоих случаях разрешаются так, как привык ноутбук, и никто не замечает перемен.

Для сотрудника разницы нет: в строке crm.corp.example, закладка одна, инструкция одна. Для администратора различий две, и обе проверяемы по отдельности: кто отвечает на вопрос про имя и по какой дороге идут пакеты к найденному адресу. Пока эти вопросы не смешиваются, фраза «CRM не открывается» перестаёт быть диагнозом и превращается в короткий список шагов, из которых каждый можно проверить за минуту.