При проверке связи не удалось обнаружить узел или dnscache

Автор Призрак, 22 июля 2019, 21:15

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

Вниз

Призрак

22 июля 2019, 21:15 Последнее редактирование: 22 июля 2019, 21:28 от Призрак
Здравствуйте, коллеги! Эта ошибка вызывает, скорее, недоумение, чем беспокойство. Как я понял, она не очень распространена и появляется по принципу "как карта ляжет".

Скончался шлюз, в одном из общежитий, на котором, кстати, был контроллер домена (не слишком умно кто-то сделал). Я сделал новый шлюз, с нового системного блока, в котором сломался новый же диск (гарантия уже прошла, поэтому взял два старых малой ёмкости и сделал зеркало). Накатил все обновления, поставил все нужные программы, в том числе антивирус. Удалил скончавшийся контроллер с помощью утилиты ntdsutil, зорко следя за тем, чтобы не спороть косяка и не удалить лишнего.

Но дело в том, что стало появляться надоедливое сообщение, про несовместимость процессора, что меня ужасно злило и не давало поставить все обновления (а вы говорили, чтобы я не ругался, как тут не ругаться?), поэтому я поставил программу wufus.

Конфигурация шлюза:

INTERNET

IP 89.250.XXX.XXX
MASK 255.255.255.248
GATEWAY 89.250.XXX.XXX


LAN

IP 192.168.50.1
MASK 255.255.255.0

DNS1 192.168.10.12
DNS2 192.168.10.13


OpenVPN

IP 10.8.0.5


DNS имя 192.168.10.12 VM-DC-01
DNS имя 192.168.10.13 VM-DC-02
DNS имя 192.168.10.4 server-gw-mail

Всё работает отлично (DNS из административного корпуса, OpenVPN сервер там), отклик есть, связь есть, но всё изменяется после перезагрузки сервера. Изначально появляется весёлое сообщение, при попытке провести пинг по имени хоста.

При проверке связи не удалось обнаружить узел server-gw-mail
Проверьте имя узла и повторите попытку


При этом интернета нет на сервере (ping ya.ru превышен интервал ожидания для запроса)

ping 192.168.10.4 - отклик есть

Так же откликаются все компьютеры, которые я пытаюсь вызвать,  по адресу, в том числе и указанные DNS.

Ввожу команду

nslookup server-gw-mail

Получаю ответ

vm-dc-01.pgfa.local
Address: 192.168.10.12

server-gw-mail.pgfa.local
Address: 192.168.10.4


То есть всё резолвится, значит сервер виден. Но интернета нет и по имени пинг не идёт. Решается всё перезапуском службы DNS клиент или dnscache, пинг появляется по именам, интернет работает на сервере. Вот что это может быть, неужели от той самой программы?

Для кого то депрессия и тоска это не просто состояния, это стиль жизни...

Призрак

#1
22 июля 2019, 22:10 Последнее редактирование: 22 июля 2019, 22:25 от Призрак
Да, и ещё дополнение. Шлюз в домен вводится. но там где центр управления сетями для LAN и OpenVPN адаптеров неопознанная (общественная) сеть, когда как у шлюзов доменная сеть. Что там не так? Переустановил только что драйвер, доменная сеть появилась. После перезагрузки опять неопознанная сеть, ошибка та же.
Для кого то депрессия и тоска это не просто состояния, это стиль жизни...

Уваров А.С.

Проверьте настройки брандмауэра в плане DNS для разных типов сетей. Также, чтобы работало определение сети должен быть включен на адаптере IPv6 и что-то еще из компонентов, не помню точно что.

Призрак

#3
23 июля 2019, 07:51 Последнее редактирование: 23 июля 2019, 07:56 от Призрак
Всё проверил, вместо брандмауэра у нас стоит Kaspersky Endpoint Security 10.1, который вырубает брандмауэр при установке. Причём на всех серверах.

Проблема в общежитии №2.

Я объясню ещё ситуацию так - в обоих общежитиях у нас нет физических контроллеров домена, потому  что там со студентами, в основном, работает сам провайдер, а наша сеть там отдельная. Поэтому то я и настроил релей в обоих случаях, на обоих шлюзах. При этом в общежитии №1, на шлюзе, при загрузке тоже показывает неопознанную сеть, я даже включил ipv6 и перезагрузил, но там сразу начинает всё работать, при загрузке, в обоих случаях указаны сервера DNS филиалов, которые находятся ближе всего к общежитиям, в случае же с общежитием №1 это 192.168.30.2 и 192.168.30.3. После загрузки сразу же появляется Интернет, доступны ресурсы по имени, там проблем нет, ещё раз хочу сказать большое спасибо.

При этом в общежитии №2 я пытался указать DNS сервера других филиалов, это 20.2, 20.3, 30.2, 30.3, картина та же самая.

В обоих случаях помогает вот что, если неопознанная сеть - я просто захожу по RDP по белому адресу, выключаю и включаю LAN адаптер. После этого и OpenVPN и LAN становятся доменными сетями. Дополнительно, в общежитии №2 при этом появляется Интернет и доступ к внутренним ресурсам по имени, то есть проблема уходит, но до перезагрузки. При этом после перезагрузки в общежитии №1 всё восстанавливается, а в общежитии №2 пропадает интернет и доступ к внутренним ресурсам других филиалов по доменному имени.

По общежитию №2 в интернете искал, говорят, что к такой проблеме может привести проблема со свитчом, а также некорректная работа кэша DNS. Да, оборудование у нас древнее.

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

Вот и хотелось бы спросить, не нашёл в интернете путной информации, как можно автоматизировать перезапуск адаптера на таких шлюзах при запуске? Команды то я знаю, ломаю голову, что применить - планировщик или вообще cmd файл.

Я знаю, что для того, чтобы полностью решить столь непонятную проблему с обнаружением сети, нужно установить, как минимум, по одному контроллеру домна в каждом из общежитий. Как вы думаете, коллеги, стоит ли мне это вообще сделать? Если что, из хлама я смогу собрать ещё по системному блоку. Но для 4-5 человек. Ну посчитайте - в обоих общежитиях вахта, то есть это камеры, сигнализация, в том числе пожарная, комендант, заведующий общежитием, по читальному залу. Плюс в общежитии №2 находится типография, в столовой касса.
Для кого то депрессия и тоска это не просто состояния, это стиль жизни...

Призрак

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

Я пришёл к выводу, что решение это не стандартное, а значит обычными методами не решаемое. То есть, получается, что сеть загружается раньше, чем шлюз может "поймать" контроллер домена, ну пока OpenVPN поднимется ещё. Поэтому мне пришлось сделать, ну, некий костыль, но который помогает, может кому - то понадобится.

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

netsh interface set interface name="LAN" admin=disabled
netsh interface set interface name="LAN" admin=enabled


Соответственно, у сетевого интерфейса должно быть такое название. Эти команды отключают и включают сетевой интерфейс локальной сети, LAN, 192.168.50.1, в результате сеть обнаруживает контроллер домена, сеть LAN и OpenVPN становятся доменными, соответственно, появляется интернет и доступ к внутренним ресурсам других филиалов по доменному имени.

Только я не знаю, сработает ли, если в этот момент будет недоступен OpenVPN сервер. Надо будет проверить.
Для кого то депрессия и тоска это не просто состояния, это стиль жизни...

Уваров А.С.

Ещё говорят, что сеть стартует раньше, чем обнаружит контроллер домена.
Ну так у вас OpenVPN, а он работает как пользовательская служба (в юзерспейсе), а сеть поднимается в пространстве ядра. Как вариант поставить критическим сетевым службам отложенный запуск, тогда они будут точно стартовать позже OpenVPN.

Либо думать об иных типах туннелей, скажем GRE, но, насколько я помню, он поддерживается начиная с Server 2016.

Вверх