Не резолвится имя компьютера в локальной сети

Обновлено: 03.07.2024

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

Применяется к: Windows Server 2012 R2, Windows Server 2016
Исходный номер КБ: 292822

Симптомы

Компьютер под управлением Microsoft Windows 2000 Server или Microsoft Windows Server 2003 может иметь проблемы с подключением, если сервер настроен следующим образом:

Служба маршрутного и удаленного доступа настроена для разрешения входящих подключений.
На сервере, на который запущен маршрут и удаленный доступ, установлена и настроена служба Windows доменного имени (DNS) или Windows Сервер имени Интернета (WINS).

После подключения удаленного компьютера к серверу маршрутов и удаленного доступа с помощью подключения к виртуальной частной сети (VPN) может возникать один или несколько следующих симптомов:

Сервер не отвечает, когда клиент запрашивает обновление.
Возможные причины:
-Сервер не является сервером ISA.
-Сервер не съехался.

При попытке с помощью сервера маршрутизов и удаленного доступа с локального компьютера с помощью имени NetBIOS сервера или полностью квалифицированного доменного имени (FQDN) компьютер пытается цитировать неправильный IP-адрес.

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

Нет серверов Logon, доступных для обслуживания вашего запроса logon

Эта проблема обычно затрагивает компьютеры с сервером малого бизнеса, так как эта версия Windows Server часто является единственным сервером в сети. Однако эта проблема может затронуть Windows 2000-сервер или любой сервер на Windows Server 2003 и сервер удаленного доступа, работающий с DNS или службой WINS.

Причина

Когда удаленный компьютер подключается к серверу маршрутного и удаленного доступа с помощью набора или VPN-подключения, сервер создает адаптер протокола точки к точке для связи с удаленным компьютером. Затем сервер может зарегистрировать IP-адрес этого адаптера PPP в DNS или базе данных WINS.

Когда сервер маршрутивки и удаленного доступа регистрирует IP-адрес своего адаптера PPP в DNS или WINS, при попытке подключения к серверу на локальных компьютерах могут возникнуть ошибки. Вы получаете эти ошибки, так как серверы DNS или WINS могут возвращать IP-адрес адаптеров PPP на компьютеры, запрашивающий DNS или WINS для IP-адреса сервера. Затем компьютеры пытаются подключиться к IP-адресу адаптеров PPP. Из-за того, что локальные компьютеры не могут достичь адаптеров PPP, подключение не удается.

Решение

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения см. в дополнительных сведениях о том, как создать и восстановить реестр в Windows

Чтобы устранить эту проблему, настройте сервер маршрутов и удаленного доступа, чтобы он не зарегистрировал IP-адрес адаптеров PPP в DNS или базе данных WINS. Для этого выполните следующие действия:

Настройка сервера маршрутов и удаленного доступа для публикации только IP-адреса локального сетевого адаптера в DNS

Выполните действия в этом разделе только в том случае, если на сервере маршрутики и удаленного доступа работает служба DNS. Если на сервере не работает служба DNS, перейдите к серверу Настройка маршрутного и удаленного доступа, чтобы зарегистрировать только IP-адрес локального сетевого адаптера в разделе WINS.

Добавление значений реестра PublishAddresses и RegisterDnsARecords для служб DNS и Netlogon

Выберите Начните, выберите Выполнить, введите regedit, а затем выберите ОК.

Найдите и выберите следующий подкай реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

В меню Редактирование указать значение New, а затем выберите строковую ценность, чтобы добавить следующее значение реестра:

Имя значения: PublishAddresses
Тип данных: REG_SZ
Данные о значении: IP-адрес локального сетевого адаптера сервера. Если необходимо указать несколько IP-адресов, разделять адреса с пробелами.

Найдите и выберите следующий подкай реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

В меню Редактирование указать значение New, а затем выберите значение DWORD, чтобы добавить следующее значение реестра:

Имя значения: RegisterDnsARecords
Тип данных: REG_DWORD
Данные значения: 0

Закрой редактор реестра, а затем перезапустите службы DNS и Netlogon. Чтобы перезапустить службу, выберите Пуск, указать на программы или все программы, указать на административные средства, а затем выбрать службы. В консоли Services щелкните правой кнопкой мыши службу и выберите перезапуск.

Добавление записей A в DNS

Выполните эти действия только в том случае, если сервер маршрутивки и удаленного доступа является контроллером домена.

Выберите Начните, указать на программы или все программы, указать на административные средства, а затем выберите DNS.

В консоли DNS раздвигаем объект сервера, расширяем папку Зоны смотра вперед, а затем выберите папку для локального домена.

В меню Действия выберите Новый хост.

В текстовом поле IP-адреса введите IP-адрес локального сетевого адаптера сервера.

Оставьте поле Имя пустым, выберите Создать связанную запись PTR, а затем выберите Add Host.

Если сервер является глобальным сервером каталогов, перейдите к шагу 7. Если сервер не является глобальным сервером каталогов, вам не нужно выполнить действия с 7 по 11. Чтобы определить, является ли сервер глобальным сервером каталогов, выполните следующие действия:

Выберите Начните, указать на программы или все программы, указать на административные средства, а затем выберите сайты и службы Active Directory.
В консоли Active Directory Sites and Services разложите папку Sites, расширьте сайт, содержащий сервер, а затем расширите объект сервера.
Щелкните правой кнопкой мыши NTDS Параметры, а затем выберите Свойства.
На вкладке General найдите поле "Глобальный каталог". Если этот контрольный ящик проверяется, сервер — это сервер глобального каталога.

В папке Зоны forward Lookup в консоли DNS разложите папку для локального домена, разложите папку MSDCS и выберите папку GC.

В меню Действия выберите Новый хост.

В поле IP-адрес введите IP-адрес локального сетевого адаптера сервера.

Оставьте поле Имя пустым, выберите Создать связанную запись PTR, а затем выберите Add Host.

Настройка сервера маршрутов и удаленного доступа для регистрации только IP-адреса локального сетевого адаптера в WINS

Выполните действия в этом разделе только в том случае, если на сервере маршрутов и удаленного доступа работает служба WINS. Кроме того, если на сервере работает сервер малого бизнеса 2000 SP1, сервер малого бизнеса 2000 SP1a или Windows Small Business Server 2003, вам не нужно завершать действия в этом разделе. По умолчанию эти версии сервера Windows настраиваются, чтобы предотвратить регистрацию IP-адреса адаптеров PPP в базе данных WINS.

Добавление значения реестра DisableNetbiosOverTcpip для службы маршрутизации и удаленного доступа

Значение реестра DisableNetbiosOverTcpip отключает протокол NetBIOS по TCP/IP (NetBT) для подключений к удаленному доступу. Таким образом, сервер не будет регистрировать адаптер PPP в базе данных WINS. Знайте, что при добавлении этого значения клиенты удаленного доступа не могут просматривать локализованную сеть через "Мои сетевые места" или "Сетевое соседство". Иногда это также может привести к неудаче подключения к удаленному доступу на компьютерах с более старыми версиями Windows. Например, подключение к удаленному доступу может быть неудачным на 98 компьютерах Microsoft Windows и на компьютерах microsoft Windows NT 4.0 Workstation. Альтернативу использованию реестра DisableNetbiosOverTcpip см. в разделе Обходное решение.

Если сервер работает Windows 2000 Server SP2 или более ранней версии, необходимо обновить сервер с помощью SP3 или SP4, чтобы значение реестра DisableNetbiosOverTcpip работало. Если не обновить сервер, служба маршрутинга и удаленного доступа не будет использовать это значение реестра, и проблема не будет устранена.

Выберите Начните, выберите Выполнить, введите regedit, а затем выберите ОК.

Найдите и выберите следующий подкай реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\IP

Имя значения: DisableNetbiosOverTcpip
Тип данных: REG_DWORD
Данные значения: 1

Закрой редактор реестра, а затем перезапустите службу маршрутов и удаленного доступа. Чтобы перезапустить службу, выберите Пуск, указать на программы или все программы, указать на административные средства, а затем выбрать службы. В консоли Services щелкните правой кнопкой мыши службу и выберите перезапуск.

Очистка базы данных WINS

Выберите Начните, указать на программы или все программы, указать на административные средства, а затем выбрать WINS.
Развяжите объект сервера, щелкните правой кнопкой мыши Активные регистрации, а затем выберите Удалить владельца.
В диалоговом окне Удалить владельца выберите IP-адрес сервера.
Если на сервере WINS нет партнеров репликации, выберите Удалить только с этого сервера, а затем выберите ОК. Если на сервере WINS имеется один или несколько партнеров репликации, выберите удаление Replicate на другие серверы (надгробие) и выберите ОК.

Сервер WINS будет автоматически восстанавливать базу данных, так как компьютеры в сети регистрируют свои имена NetBIOS. Вы можете Windows компьютеры в сети, чтобы зарегистрировать их имена NetBIOS немедленно, запуская nbtstat -RR команду.

Обходной путь

В качестве обхода этой проблемы можно настроить подключения удаленного доступа к статическому пулу IP-адресов, который находится на другой подсети IP, чем на локальных компьютерах. В этом случае локальные компьютеры не будут пытаться подключиться к адаптеру PPP, если он регистрируется в DNS или WINS, так как адаптер PPP находится на другой подсети IP.

Чтобы указать статичный пул адресов в консоли маршрутизировать и удаленный доступ, щелкните правой кнопкой мыши ServerName, выберите Свойства, выберите вкладку IP, выберите пул статических адресов, а затем выберите Добавить. Добавьте диапазон, который не использует ту же подсеть IP, что и локальные компьютеры. Например, если локальные компьютеры используют подсеть 10.0.0.0, добавьте статический пул, использующий подсеть 172.168.0.0. Если на сервере маршрутизации и удаленного доступа работает ISA Server 2000, необходимо добавить эту подсеть в локализованную адресную таблицу. Этот сценарий наиболее распространен в small Business Server 2000.

Здравствуйте. Есть машинка, на ней стоит свежая Win7 Максимальная x64, билд 7600 RU.

На ней с перебоями работает разрешение имен. Инет приходит через Ethernet от домашнего роутера (Acorp W422G_v3), к которому машинка цепляется по DHCP. DHCP наряду с айпишниками раздает клиентам адреса DNS-серверов в явном виде, то есть не relay самого роутера, а в моем случае OpenDNS (208.67.222.222, 208.67.220.220).

Аналогично не резолвятся имена в других приложениях.

Вывод ipconfig /all:

Я, если честно, не понимаю, как такое вообще возможно - разве механизм разрешения имен в ping и nslookup не один и тот же?

И да, пробовал прописать другие DNS (провайдерские, гугловский, и т.п.) - то же самое. Пробовал статически вписать DNS и айпишники - все равно то же самое.

Причем данная ситуация наблюдается случайным образом - иногда резолвинг работает, иногда нет. Подозреваю, что это что-то связанное со сбросом какого-либо кэша по времени (ARP, DNS), но не знаю куда копать. ipconfig /flushdns ничего не дает.

В Linux и WinXP все нормально работает.

Конфигурация компьютера
Процессор: Intel Core i7-3770K
Материнская плата: ASUS P8Z77-V LE PLUS
Память: Crucial Ballistix Tactical Tracer DDR3-1600 16 Гб (2 x 8 Гб)
HDD: Samsung SSD 850 PRO 256 Гб, WD Green WD20EZRX 2 Тб
Видеокарта: ASUS ROG-STRIX-GTX1080-O8G-11GBPS
Звук: Realtek ALC889 HD Audio
Блок питания: be quiet! Straight Power 11 650W
CD/DVD: ASUS DRW-24B5ST
Монитор: ASUS VG248QE 24"
ОС: Windows 8.1 Pro x64
Индекс производительности Windows: 8,1
Прочее: корпус: Fractal Design Define R4

Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.

Петя, ю а май хиро.

В общем, дело не в ipv6 (ping -4 тоже не работает), дело в службе dnscache, которая, видимо, за каким-то дьяволом пытается резолвить имена через netbios, а не DNS.
По ссылке что вы дали, люди решили проблему, но у кого-то не работало, у кого-то работало. ну его нафиг.
Я поступил топорней - вырубил DNS-кэш нафиг (net stop dnscache), и пустил DNS-запросы через привычный dnsmasq на отдельной машине.

Проблема решена, хоть и костыльно, конечно.

Последний раз редактировалось mexico, 20-06-2010 в 01:08 .

mexico,
А серверов провайдера без всяких заморочек не хватает?
При чем тут netbios?

А серверов провайдера без всяких заморочек не хватает? »

Не-а. Я и их ставил, не в них дело. Про UDP 53 не надо - азы же.

Поскольку у меня есть сторонний DNS-кэш на Linux, я не стал заморачиваться и искать причины (я не в ладах с вендой, да и время - деньги), а просто отключил виндовый кэш. Работает - и ладно.

Если предложите 100% работающий способ обойтись без этого костыля - буду только рад.

Последний раз редактировалось mexico, 20-06-2010 в 01:13 .

mexico,
Nslookup действительно кэш DNS не нужен.

При отключении windows кэша DNS вы заставляете лишний раз ПК клиента определять IP по мнемонике используя запросы по сети на ваш DNS (если они есть у него в кэше, то он просто их отправит), по времени это доли секунд.

Реестр по кэшу DNS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache

Выглядет это так:

ping DC2 разрешает, а

ping DC2.domain.local нет

Ответы

Доброго дня, друзья.

An error occurred while signing a message using the inserted smart card: Provider could not perform the action since the context was acquired as silent.

An error occurred while retrieving a digital certificate from the inserted smart card. Invalid type specified.

An error occurred while retrieving a digital certificate from the inserted smart card. Incorrect function.

An error occurred while retrieving a digital certificate from the inserted smart card. Keyset does not exist

An error occurred while retrieving a digital certificate from the inserted smart card. 0x81000001

An error occurred while retrieving a digital certificate from the inserted smart card. The handle is invalid.

Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 30 января 2018 г. 7:39

Все ответы

Все хосты в сети не резолвятся или только определенные?

проверьте присутствуют ли эти записи в DNS

А также еще одна странная вещь.

на больных серверах ipconfig /flushdns для очистки совести ;)

Откуда такая уверенность? Из того, что за три года ошибка проявилась в первый раз? Это не основание.

Ну вот, что выдала проверка:

PS C:\Users\admin> Get-DNSClientServerAddress -AddressFamily IPv4 | select -expand ServerAddresses | foreach

Name Type TTL Section IPAddress
---- ---- --- ------- ---------
dc5.domain.local AAAA 1200 Question ::1
dc5.domain.local A 1200 Question 172.16.100.9

Server: 172.16.100.13
dc5.domain.local AAAA 1200 Question ::1
dc5.domain.local A 1200 Question 172.16.100.9

Server: 127.0.0.1
dc5.domain.local AAAA 1200 Question ::1
dc5.domain.local A 1200 Question 172.16.100.9

PS C:\Users\admin> Get-DNSClientServerAddress -AddressFamily IPv4 | select -expand ServerAddresses | foreach

Name Type TTL Section IPAddress
---- ---- --- ------- ---------
DC2.domain.local A 3600 Answer 172.16.100.12

Server: 172.16.100.13
DC2.domain.local A 3600 Answer 172.16.100.12

Server: 127.0.0.1
DC2.domain.local A 3600 Answer 172.16.100.12

PS C:\Users\admin> Get-DNSClientServerAddress -AddressFamily IPv4 | select -expand ServerAddresses | foreach

Name Type TTL Section IPAddress
---- ---- --- ------- ---------
DC3.domain.local A 3600 Answer 172.16.100.13

Server: 172.16.100.13
DC3.domain.local A 3600 Answer 172.16.100.13

Server: 127.0.0.1
DC3.domain.local A 3600 Answer 172.16.100.13

nslookup сервер.лицензирования сервер.DNS

1. Проверка репликации was successful на всех

2. А вот, что дал dcdiag /q

There are warning or error events within the last 24 hours after the

SYSVOL has been shared. Failing SYSVOL replication problems may cause

Group Policy problems.
. DC2 failed test DFSREvent

An error event occurred. EventID: 0x0000165B

Time Generated: 01/16/2018 08:41:34

The session setup from computer 'Alt-A306250' failed because the security database does not contain a trust account 'Alt-A306250$' referenced by the specified computer.

An error event occurred. EventID: 0x000016AD

Time Generated: 01/16/2018 08:43:24

The session setup from the computer Alt-A14543 failed to authenticate. The following error occurred:

An error event occurred. EventID: 0x000016AD

Time Generated: 01/16/2018 08:43:48

The session setup from the computer Alt-A306250 failed to authenticate. The following error occurred:

An error event occurred. EventID: 0x000016AD

Time Generated: 01/16/2018 08:51:56

The session setup from the computer Alt-A8942 failed to authenticate. The following error occurred:

An error event occurred. EventID: 0x00003006

Time Generated: 01/16/2018 08:54:43

The SAM database was unable to lockout the account of Administrator due to a resource error, such as a hard disk write failure (the specific error code is in the error data) . Accounts are locked after a certain number of bad passwords are provided so please consider resetting the password of the account mentioned above.

An error event occurred. EventID: 0x0000165B

Time Generated: 01/16/2018 08:55:14

The session setup from computer 'Alt-A8942' failed because the security database does not contain a trust account 'Alt-A8942$' referenced by the specified computer.

An error event occurred. EventID: 0x00003006

Time Generated: 01/16/2018 08:58:47

An error event occurred. EventID: 0x0000165B

Time Generated: 01/16/2018 09:06:27

The session setup from computer 'Alt-A10900' failed because the security database does not contain a trust account 'Alt-A10900$' referenced by the specified computer.

An error event occurred. EventID: 0x0000165B

Time Generated: 01/16/2018 09:06:37

The session setup from computer 'Alt-A21172' failed because the security database does not contain a trust account 'Alt-A21172$' referenced by the specified computer.

An error event occurred. EventID: 0x000016AD

Time Generated: 01/16/2018 09:08:28

The session setup from the computer Alt-A10900 failed to authenticate. The following error occurred:

An error event occurred. EventID: 0x000016AD

Time Generated: 01/16/2018 09:08:49

The session setup from the computer Alt-A21172 failed to authenticate. The following error occurred:

An error event occurred. EventID: 0x0000165B

Time Generated: 01/16/2018 09:12:02

The session setup from computer 'Alt-A00323-VB' failed because the security database does not contain a trust account 'Alt-A00323-VB$' referenced by the specified computer.

An error event occurred. EventID: 0x000016AD

Time Generated: 01/16/2018 09:14:05

The session setup from the computer Alt-A00323-VB failed to authenticate. The following error occurred:

An error event occurred. EventID: 0x0000165B

Time Generated: 01/16/2018 09:24:04

The session setup from computer 'Alt-A18166' failed because the security database does not contain a trust account 'Alt-A18166$' referenced by the specified computer.

An error event occurred. EventID: 0x000016AD

Time Generated: 01/16/2018 09:26:07

The session setup from the computer Alt-A18166 failed to authenticate. The following error occurred:

An error event occurred. EventID: 0x0000165B

Time Generated: 01/16/2018 09:26:23

The session setup from computer 'Alt-A306249' failed because the security database does not contain a trust account 'Alt-A306249$' referenced by the specified computer.

. DC2 failed test SystemLog

1. По DC2 отрабоатло корректно

2. По DC2.domain.local отработало корректно

3. А вот по 172.16.100.12 *** UnKnown can't find 172.16.100.12: Non-existent domain

4. 172.16.100.13 отработало корректно -это DC3

5. По DC3 отрабоатло корректно и по DC3.domain.local

6. 172.16.100.9 отработало корректно -это DC5

7. По DC5 отрабоатло корректно и по DC5.domain.local

>3. А вот по 172.16.100.12 *** UnKnown can't find 172.16.100.12: Non-existent domain

*** UnKnown can't find 172.16.100.12: Non-existent domain
> 172.16.100.12
Server: UnKnown
Address: 172.16.100.12

Name: dc2.domain.local
Address: 172.16.100.12

> 172.16.100.12
Server: UnKnown
Address: 172.16.100.12

Name: dc2.domain.local
Address: 172.16.100.12

C:\Users\admin>ping app
Ping request could not find host app. Please check the name and try again.

Pinging 172.16.100.2 with 32 bytes of data:
Reply from 172.16.100.2: bytes=32 time<1ms TTL=255
Reply from 172.16.100.2: bytes=32 time<1ms TTL=255
Reply from 172.16.100.2: bytes=32 time<1ms TTL=255
Reply from 172.16.100.2: bytes=32 time<1ms TTL=255

Поставил пакеты network-manager-openconnect network-manager-openconnect-gnome
Настроил соединение и оно даже подключилось. Проблема первая, каждый раз когда я подключался снова, он забывал имя пользователя, что раздражает. Я нашел решение и создал
баг. Решение простое, с консоли задаем свое имя в особом виде nmcli con mod prgcvp vpn.secrets 'form:main:username=yourName','save_passwords=yes'
После чего оно будет запомнено. Да, галочку «запомнить пароль» я ставил и пароль он даже запомнил, но вот в тексте галочки про имя пользователя ничего не сказано, так что он честно его забыл :) Напомню, что настройки менеджера лежат в /etc/NetworkManager/system-connections/.

И если параметры знаешь, то можно и руками отредактировать нужное соединение.

Подключаться стало удобно и возникла вторая проблема, имена ресурсов в VPN сети не разрешаются в адреса DNS сервером. Сервер есть, все настройки на месте, но nslookup someserver.local выдает ошибку, а nslookup someserver.local somednsIP выдет правильный ответ. Странно, подумал я, как так, сервер есть, отвечает, а если его конкретно не указать, ошибка? Ответ оказался прост. Когда systemd-resolved пытается найти адрес сервера по имени, он выступает фасадом для других DNS серверов. Делается это так, ссылка /etc/resolv.conf может указывать на несколько мест:

/run/systemd/resolve/stub-resolv.conf это опция по умолчанию и этот файл будет содержать примерно такое
nameserver 127.0.0.53
options edns0 trust-ad
search somedomain.local
/run/systemd/resolve/resolv.conf это можно использовать если функционал systemd-resolved чем то не устроил когда он прикидывается DNS сервером 127.0.0.53. В итоге это не пригодилось, так для информации пишу.

Саму ссылку /etc/resolv.conf вы можете сами настроить что бы смотрела в любое из мест.
Так вот, дело в том, что openconnect при подключении к VPN получает таблицу route, DNS сервера, а так же search domain и этот домен от VPN сервера приходил неверный (так неправильно настроен у нас). От сервера приходило somedomain.local, а надо было просто local что бы somesrver.local был распознан.

Когда systemd-resolved прикинулся локальным DNS сервером и через /etc/resolv.conf всех отправил к себе за разрешением имен, логика его работы такова. Для каждого коннекта, которые можно посмотреть командой nmcli connection show (это те коннекты, которые знает NetworkManager) systemd-resolved помнит DNS сервера, которые получил по DHCP. Это можно посмотреть командой:

Когда в 127.0.0.53 приходит запрос на разрешение имени, systemd-resolved смотрит search domain у каждого из коннектов (эти домены он при подключении от DHCP получил тоже). Домены можно посмотреть командой:

Далее имя хоста проверяется на частичное совпадение с теми доменами, которые прикреплены к коннектам и самое длинное совпадение и определяет какой конкретно DNS сервер вызвать. Либо все идет в DNS сервер где search domain "

От сервера компании мне приходил неверный search domain (somedomain.local) для VPN коннекта и потому когда я пытался разрешить адрес someserver.local, systemd-resolved их не мог найти, так как предполагал, что DNS сервера, полученные из этого соединения нужны что бы распознавать имена someserver.somedomain.local. Поправил я это подменив search domain в NetworkManager командой
nmcli connection modify yourConnectionName ipv4.dns-search «local»
Доменов может быть несколько через пробел. В итоге все заработало.
Помимо этого я удалил пакет avahi-daemon, так как службы bonjur, которые обслуживает этот демон по умолчанию тоже резолвятся на домене local, а в нашей сетке именно это имя используется для локальной сети и будут конфликты.

docker

Теперь в хост системе работает резолвинг адресов, но при запуске докера резолвинг локальных адресов в VPN может не работать по прежнему. И тут есть несколько вариантов.

Контейнер запущен с network_mode: host в таком случае будет использоваться для резольвинга то, что лежит в /run/systemd/resolve/resolv.conf и там у меня первый же днс сервер выбирается для резольва local и он для этого не подходит. Итог, не работает. Зато все сервисы хост машины видно из контейнера, что еще и неправильно.

Контейнер запущен с network_mode: bridge с созданием отдельной сети. В таком случае сервисы хоста будет не видно, помимо этого будет использован все тот же не работающий у меня /run/systemd/resolve/resolv.conf

Контейнер запущен без настроек сети и использует дефолтный bridge, созданный докером при инсталляции (docker0). В этом случае используется для резольва имен внутренний докеровский DNS, который судя по всему нормально взаимодействует с systemd-resolved и все резолвит как надо. В /etc/resolv.conf будет такое:

Если надо показать сервисы хост машины для доступа из контейнера, то просто запускаем сервисы слушать на docker0 IP и получаем доступ.

Не забываем открыть порты, например у меня ufw зарезал 8080 и пришлось открывать.
Было бы отлично если бы docker просто использовал systemd-resolved dns stub как в последнем описанном варианте всегда. Но к сожалению это не так. В версии systemd-resolved 248, которая только вышла и в дистрах ее нет в документации есть параметр DNSStubListenerExtra, который может задать адрес где слушать для stub. Подробности тут.

В итоге можно будет указать адрес где слушать не захардкоженный 127.0.0.53, а доступный изнутри докера и все будет работать, но пока нет.

Есть другое решение, когда контейнер пойдет на порт 53 мы будем перебрасывать его запросы в стаб systemd с помощью чего то вроде
socat UDP-LISTEN:53,fork,reuseaddr,bind=yourInterfaceIP UDP:127.0.0.53:53
Соответственно, этот DNS можно указать докеру при старте и весь функционал systemd будет работать. Но не стал это использовать.

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

Читайте также: