Два вопроса смешиваются, когда частная служба открывается удалённым пользователям. Первый — какое имя должны использовать клиенты; второй — какие источники должна допускать служба. Отвечайте на них в этом порядке, потому что правильное имя за неправильным правилом доступа всё равно терпит неудачу, а правильное правило за именем, которое не разрешается, никогда не проверяется.

Условие первое: какой путь резолвера есть у клиентов?

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

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Публичный резолвер не узнает частную зону только потому, что ноутбук подключился к VPN.

Суффикс заслуживает такого же внимания. Используйте поддомен домена, который контролирует организация, чтобы владение и планирование сертификатов оставались явными. Избегайте .local: спецификация multicast DNS привязывает этот суффикс к link-local разрешению, а маршрутизируемый туннель не воспроизводит такое поведение за вас.

Условие второе: какой источник получает служба?

Правила допуска пишутся относительно адресов, поэтому полезный вопрос — какой адрес служба видит после маршрутизации и трансляции. Для примера службы на 10.20.30.40 офисные клиенты приходят из 10.20.30.0/24, а удалённые клиенты — из отдельного пула, например 10.99.0.0/24.

Если шлюз транслирует удалённый пул, служба видит транслятор, и правило, написанное для 10.99.0.0/24, не совпадёт.

Читайте это со стороны службы, а не со стороны клиента. Журнал слушателя или захват пакетов на хосте службы показывает источник, который действительно пришёл; собственный адрес клиента — лишь догадка о том, что пережило путь.

Условие третье: имя привязано к службе или к хосту?

Имя, указывающее на адрес одной машины, привязывает каждого клиента к этой машине. Имя, указывающее на балансировщик нагрузки или стабильный адрес службы, переживает замену хоста за ним. Выбирайте осознанно, потому что изменить это позже значит изменить закладки каждого клиента и субъект каждого сертификата.

Для одной внутренней службы прямая запись обычно подходит и проще для осмысления.

Для всего, что будет заменено, перестроено или масштабировано, стабильный фронтенд стоит дополнительной конфигурации. Тест прост: если вы можете заменить бэкенд, не сообщая пользователям, имя привязано к службе; если нет — к хосту.

Проверьте два решения по отдельности

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

curl -sv --max-time 5 https://files.corp.example/health

Затем один раз проверьте запрещённый источник и запишите результат.

Держите две записи отдельно в документации: имя и его зона, допущенные источники и владелец правила. Когда одно меняется, другое не обязано.

Где решение обычно идёт не так

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

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

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

Похожие статьи