Именованный экземпляр SQL Server через VPN: обнаружение, а не порт 1433

Большинство людей считают имя узла SQL Server полным адресом, а VPN — чем-то либо разрешённым, либо нет. На практике именованный экземпляр заставляет клиента выполнить второй поиск после DNS, и именно этот поиск туннель ломает чаще всего. Явная конечная точка обходит его, поэтому tcp:host,port может работать, а host\INSTANCE истекает по таймауту. Разница между тем, чтобы найти службу, и тем, чтобы получить разрешение ею пользоваться.

Миф: одно имя узла означает один порт

Имя узла разрешается в адрес, и на этом его работа заканчивается. Именованный экземпляр добавляет имя экземпляра, которое сервер должен перевести в порт TCP, а клиент не может его угадать. Порт 1433 — это значение по умолчанию для экземпляра по умолчанию, а не свойство каждого экземпляра на машине. Если считать эти две вещи одним и тем же, возникает классический симптом: ping работает, DNS работает, сканирование 1433 ничего не показывает, и вывод — сеть блокирует SQL.

Второе предположение терпит неудачу так же: что открыть TCP 1433 достаточно. Если экземпляр слушает в другом месте, открытый 1433 доказывает лишь то, что там есть что-то ещё. Порт должен совпадать со слушателем, и что слушатель — это деталь конфигурации на стороне сервера об этом нужно спрашивать, а не догадываться.

Что клиент на самом деле делает с именованным экземпляром

После разрешения узла клиент отправляет запрос обнаружения в SQL Server Browser по UDP 1434 и спрашивает, какой порт использует именованный экземпляр. Служба браузера отвечает из собственного реестра сервера, после чего клиент открывает TCP-соединение к этому порту. Два протокола и два порта участвуют ещё до попытки входа.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

Поэтому блокировка только UDP даёт таймаут, который выглядит как мёртвый узел. Если служба браузера остановлена или отключена, запрос обнаружения остаётся без ответа, хотя ядро базы данных работает и его TCP-порт открыт. Если экземпляр настроен со статическим портом, клиент всё равно спрашивает, если только ему не дали конечную точку напрямую. Каждая из этих ошибок одинаково выглядит в сообщении об ошибке приложения, и им нужны разные исправления.

Служба браузера — это удобство обнаружения, а не база данных. Её остановка не останавливает ядро, а её запуск не открывает TCP-порт экземпляра.

Почему явная конечная точка работает, когда имя не работает

Явная конечная точка убирает поиск из последовательности: клиент подключается прямо к адресу и порту, которые вы указали. Это в первую очередь диагностика, а не автоматически постоянное решение, потому что порт может измениться, если экземпляр позже перенастроят на динамический. Сравните обе формы с одним и тем же клиентом и одной и той же учётной записью, прежде чем делать выводы.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Если явная форма работает, а именованная нет, то пробел в обнаружении, и вы можете выбрать, как его закрыть: разрешить UDP 1434 через туннель или попросить администратора закрепить статический порт и задокументировать конечную точку. Оба варианта — осознанные решения с разными затратами на поддержку. Открывать каждый порт диапазона — ни то, ни другое, и именно этот вариант обычно предлагают в конце долгого дня. Запишите выбор там, где живут строки подключения.

Если не работает ни одна форма, проблема выше обнаружения. Проверьте слушатель, маршрут и правило доступа для порта, который экземпляр действительно использует, прежде чем винить службу браузера.

После обнаружения: аутентификация и идентичность — разные вещи

Ошибка входа — это другое событие, чем таймаут, и идентичность VPN не становится учётной записью SQL из-за наличия туннеля. Когда клиент достигает нужного порта, ядро базы данных применяет собственную аутентификацию и разрешения. Смешивание двух этапов в одной заявке — это путь, которым проблема обнаружения попадает не к той команде. Прочитайте номер ошибки, прежде чем что-либо менять.

Сохраняйте задокументированное имя узла, если драйвер проверяет сертификат сервера, потому что подключение по числовому адресу может изменить эту проверку вместо решения исходной проблемы. Новые драйверы Microsoft шифруют по умолчанию, поэтому несовпадение имени проявляется как ошибка сертификата после успешного TCP-соединения. Это прогресс, а не новый сбой.

Миф, от которого стоит отказаться: имя узла SQL Server — это полный адрес. Это узел плюс для именованного экземпляра поиск, который туннель может не передать. Назовите порт, назовите путь обнаружения, и следующий сбой скажет, какой уровень исправлять.