Как читать маршрутизацию VPN DNS для каждого подключения из resolvectl
resolvectl status показывает серверы, домены и маршрут по умолчанию для каждого подключения. Читайте их вместе, затем запросите имя и отметьте, какое подключение ответило.
Запустите resolvectl status и получите стену блоков по подключениям, каждый со своими серверами и своей строкой доменов. Маршрутизацию определяет список доменов, а не адрес сервера имён, потому что локальный stub пересылает каждый запрос тому подключению, которое заявляет имя. Прочитайте эти заявки до того, как читать ответ, затем запросите имя и проверьте, какое подключение его создало. Неверный ответ от верного подключения — это другая проблема, чем верный ответ от неверного.
Что сообщает каждый блок по подключению
Каждый блок перечисляет серверы, которые резолвер будет использовать для этого интерфейса, список доменов и то, является ли подключение маршрутом по умолчанию. Список доменов — это набор заявок, и резолвер применяет совпадение по самому длинному суффиксу: запрос для host.corp.example заявляет подключение с corp.example раньше того, у которого только маршрут по умолчанию. Два подключения, заявляющие один и тот же суффикс, оставляют результат приоритету и порядку, поэтому дубликаты заслуживают внимания первыми. Строка текущего сервера показывает, какой из перечисленных серверов используется в этот момент.
Stub-адрес вроде 127.0.0.53 в /etc/resolv.conf говорит только о том, что stub впереди. Он не называет вышестоящий источник, который ответил, поэтому диагностика, основанная только на resolv.conf, заходит в тупик.
Правильно читайте три типа записей домена
| Запись | Что она заявляет | Обычная ошибка |
|---|---|---|
| corp.example | домен маршрутизации и суффикс поиска: имена под ним идут к этому подключению, а строка добавляется к голым именам | удалён, потому что маршрутизация вроде бы работает и так |
| ~corp.example | только маршрут: имена под ним идут к этому подключению, но суффикс не добавляется | предположено, что он нужен для маршрутизации |
| ~. | маршрут по умолчанию: заявляет запросы, которые не покрывает ни одно другое подключение | оставлен активным в разделённом профиле, поэтому публичные имена идут через туннель |
Тильда меняет поведение поиска, а не маршрутизацию. Запись без тильды — это и домен маршрутизации, и домен поиска, поэтому имена под ней отправляются к этому подключению, а к односоставным именам добавляется суффикс. Запись с тильдой маршрутизирует тот же суффикс, но держит его вне списка поиска. Поэтому удаление тильды меняет то, какие голые имена разрешаются, и поэтому отсутствующая тильда — это проблема поиска, а не сбой разделённого DNS.
Запись маршрута по умолчанию заявляет всё, что не покрывает ни одно другое подключение. Профиль полного туннеля обычно хочет её, а разделённый профиль обычно нет, потому что публичные имена тогда идут к приватному резолверу и могут там не разрешиться. Читайте таблицу относительно замысла профиля, а не копируйте флаги между профилями. Когда два подключения заявляют один суффикс, решите вопрос приоритета, прежде чем править что-либо ещё.
Запросите имя и посмотрите, какое подключение ответило
Подкоманда query печатает адрес, протокол и подключение или область, которые создали ответ. Проверьте одно имя, которое должен заявить приватный суффикс, и одно обычное публичное имя, затем сравните сообщённые источники. Если приватное имя отвечает с беспроводного подключения, заявка отсутствует или туннель не работает; если публичное имя в разделённом профиле отвечает из туннеля, маршрут по умолчанию слишком широк. Эти два сбоя в браузере выглядят одинаково, а в этом выводе наоборот.
resolvectl status
resolvectl query host.corp.exampleСледите и за сообщённым протоколом, потому что ответ из кеша или из файла hosts может прийти без обращения к какому-либо вышестоящему источнику. Ответ из кеша доказывает, что имя когда-то разрешилось, а не то, что текущая политика маршрутизирует его правильно.
Держите маршрутизацию имён отдельно от маршрутизации пакетов
Решение резолвера не создаёт путь. Выбранному серверу всё ещё нужен маршрут к своему адресу, а возвращённому адресу всё ещё нужен маршрут в приватную сеть, поэтому правильная политика DNS может сосуществовать с соединением, которое никогда не открывается. Когда имя разрешается, а приложение терпит неудачу, изучите адрес и маршрут вместо того, чтобы снова менять DNS. Разрешение имён и достижимость — два вопроса с двумя разными владельцами.
Приложения могут полностью обойти системный резолвер через собственную настройку защищённого DNS или встроенный резолвер. Результат resolvectl описывает системный путь, и браузер, который его игнорирует, будет расходиться с каждым вашим тестом. Проверьте эту настройку, прежде чем заключать, что политика сломана.
Запишите адрес, в который разрешилось имя, рядом с подключением. Правильное имя, указывающее на неправильный адрес, — это проблема записи, а не маршрутизации.
Проверьте снова после того, как подключение изменится
Переподключение или смена беспроводной сети заново строит состояние подключения, и сетевой менеджер может переустановить свои домены и серверы поверх всего, что задано вручную. Затем запросите те же два имени и сравните с записанной базовой линией. Если ручная правка исчезла, исправление относится к профилю подключения а не к команде оболочки. Именно запись до и после делает это видимым.
Делитесь только теми именами и контекстом серверов, которые нужны отчёту, потому что внутренние суффиксы раскрывают топологию. Документация systemd-resolved о маршрутизации доменов охватывает правило самого длинного совпадения и поведение тильды, и одно прочтение предотвращает большинство ошибок в таблице выше: маршрутизация запросов в systemd-resolved.