☰

Почему я больше не могу подключиться к SQL Server с другого ПК в моей локальной сети?

tag-icon • tag-icon windows networking dns sql-server
Почему я больше не могу подключиться к SQL Server с другого ПК в моей локальной сети?

Почему клиент SQL Server перестал подключаться к SQL Server, работающему на другом узле в моей локальной сети?

Это работает правильно уже долгое время. Клиентский ПК (ПК A) подключался два дня назад. Ничего не изменилось ни на ПК A, ни на ПК, на котором размещен SQL Server (MYSERVER). При попытке подключения возникает ошибка «При установлении соединения с SQL Server произошла ошибка, связанная с сетью. Сервер не найден или недоступен». Я могу успешно подключиться к тому же экземпляру SQL Server с другого ПК, ПК B.

Оба ПК используют одну и ту же строку подключения в программе C#, но я подтвердил, что подключение из SQL Server Management Studio на ПК A также не удается. Также подключение в SQL Server Management Studio работает, если я меняю имя сервера на IP-адрес узла сервера, т. е. 192.168.178.20\SQLEXPRESS подключается, но MYSERVER\SQLEXPRESS не подключается. Похоже, что Windows или SQL Client не могут разрешить имя хоста (хотя это было сделано еще пару дней назад).

Два клиентских ПК и серверный ПК работают под управлением Windows 10. Локальная сеть представляет собой рабочую группу, а не домен. Два клиента используют проверку подлинности Windows для подключения к серверу.

На ПК А я проверил

  • файл HOSTS не содержит никаких адресов

  • Я могу выполнить ping MYSERVER, и он преобразуется в правильный адрес 192.168.178.20

  • псевдонимов SQL нет

  • ПК использует правильный DNS-сервер на маршрутизаторе

В качестве обходного пути я включил MYSERVER в файл hosts и изменил IP-адрес MYSERVER на статический адрес 192.168.178.20, но я не хочу, чтобы это сохранялось навсегда.

Есть ли какие-нибудь предположения, почему имя сервера не разрешается или что я могу сделать для дальнейшего расследования?

решение1

Ответ был прост. Я перезагрузил свой роутер.

Я исправил это с помощьюWireshark. Я сравнил пакеты между клиентским ПК и сервером, как когда адрес сервера был в клиентском файле HOSTS Windows (когда подключение к SQL Server всегда работало), так и когда файл HOSTS был пуст (когда клиентский ПК никогда не подключался). В обоих случаях я мог видеть обмен пакетами TCP, но с адресом сервера в файле hosts были также пакеты TLS для зашифрованного соединения. В другом случае клиент, казалось, отправлял запрос на соединение на сервер, но не было зашифрованных данных TLS.

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

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

Связанный контент