Как проверить Linux-систему, где accept-dns включён, но openresolv возвращает ошибку и resolv.conf остаётся прежним: карта systemd-resolved, NetworkManager, DHCP и resolvconf без ручной подстановки публичного DNS.
Не редактируйте resolv.conf первым шагом
Сохраните вывод о типе файла /etc/resolv.conf: обычный файл или символическая ссылка и её цель. Затем запишите текущие nameserver и search без публикации внутренних доменов. Ручная замена содержимого может быть немедленно перезаписана NetworkManager, DHCP, systemd-resolved или openresolv и скроет исходную причину. Официальная документация Tailscale прямо описывает несколько Linux DNS managers и возможную конкуренцию. Если система рабочая для обычного интернета, не подставляйте публичный resolver из чужого issue: внутренние имена tailnet и организации могут перестать разрешаться.
Определите фактического владельца
Проверьте активность systemd-resolved, конфигурацию DNS в NetworkManager и наличие resolvconf или openresolv. Сопоставьте это с тем, куда ведёт /etc/resolv.conf. Не делайте вывод только по установленному пакету: установленный openresolv не обязательно является текущим владельцем файла. Зафиксируйте также, создаёт ли DHCP-клиент записи после переподключения обычного интерфейса. Карта должна дать один основной путь и возможного конкурента. Пока два сервиса одновременно заявляют управление, не переключайте accept-dns и не перезапускайте всё сразу — это потеряет порядок событий.
Сверьте состояние Tailscale
Запишите версию Tailscale, состояние подключения, включён ли accept-dns и опубликованы ли в tailnet DNS-настройки. Официальная FAQ объясняет, что клиент может применять DNS от Tailscale, а настройку разрешено отключить для конкретного устройства. Это не гарантирует успешную запись при конфликтующем менеджере. Сравните разрешение одного внутреннего имени и обычного публичного домена, не публикуя само внутреннее имя. Если IP-связность tailnet работает, а имя нет, это локализует DNS; если не работает и IP, сначала решайте базовое соединение отдельно.
Проведите один обратимый контроль
После сохранения исходной карты выберите только официальный переключатель accept-dns: отключите его, проверьте, вернулся ли системный DNS к ожидаемому владельцу, затем включите обратно и снова снимите состояние. Не редактируйте файл между шагами. Если openresolv сообщает об отсутствии интерфейсов, запишите exit status и список зарегистрированных интерфейсов без адресов. Не создавайте фиктивный интерфейс и не добавляйте внешний DNS ради прохождения команды. Контроль должен показать, реагирует ли текущий DNS manager на штатный запрос Tailscale, а не заставить систему выглядеть исправной.
Пакет данных и безопасная граница
Для отчёта приложите дистрибутив, версии Tailscale и openresolv, тип /etc/resolv.conf, список активных DNS managers, статус accept-dns и результаты двух имён в обезличенном виде. Удалите tailnet, внутренние суффиксы, IP-адреса и содержимое корпоративных search domains. Критерий остановки — подтверждён один владелец, но штатное переключение Tailscale воспроизводимо завершается ошибкой либо файл остаётся неизменным. После этого эскалируйте журнал, не заменяя resolver вручную: изменение может скрыть дефект и направить приватные запросы не тому оператору.
Материал подготовлен редакцией VOne с применением ИИ для построения диагностической структуры; технические границы проверены по первичным источникам, а публичное обсуждение использовано только как обезличенный сигнал боли.
Источники и проверка
- tailscale.com: официальная документация проверено 2026-08-13
- tailscale.com: официальная документация проверено 2026-08-13
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.