SQL Server привязывается к адресу VPN, которого нет при загрузке

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

Начните с журнала запуска, а не с клиента

Откройте журнал ошибок экземпляра и прочитайте записи вокруг инициализации сети, а не только последнюю строку. Ядро сообщает, какие адреса оно пробовало и какие протоколы включило, и эта запись относится ко времени до подключения любого клиента. Теперь посмотрите, что существует на хосте прямо сейчас. Если интерфейс, владеющий настроенным адресом, появляется только после входа пользователя и запуска клиента, адрес отсутствовал при загрузке, и сбой привязки полностью объяснён.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

Подстройте путь экземпляра под свою установку и прочитайте список интерфейсов, прежде чем делать выводы. Адрес, который существует, но принадлежит не тому адаптеру, — это другая проблема, чем адрес, которого ещё нет.

Пройдите порядок привязки, которого ядро действительно придерживается

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

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

Читайте слушателя так, как его читает ядро

В SQL Server Configuration Manager откройте свойства TCP/IP экземпляра и обратите внимание на параметр Listen All, прежде чем редактировать отдельные адреса. Когда Listen All имеет значение Yes, значения Enabled для отдельных адресов игнорируются, поэтому их правка ничего не меняет из того, что использует слушатель. Запишите три вещи по порядку: адрес, который вы собираетесь обслуживать, порт и должен ли слушатель охватывать все адреса или только один. Затем примените изменение через поддерживаемую процедуру перезапуска и прочитайте следующий журнал запуска, чтобы убедиться, что ядро привязало то, что вы просили.

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

Дайте клиенту стабильное место назначения

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

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

Если клиент достигает 10.80.0.15, путь доказан, и базе данных остаётся только авторизовать этого клиента. Если нет, исправьте маршрутизацию и DNS, прежде чем снова трогать слушателя, потому что проблема привязки на сервере никогда не была причиной, по которой клиент не может его найти. Добавление фальшивого адреса из пула на сервер или второго шлюза по умолчанию, чтобы угодить слушателю, создаёт новую сетевую проблему поверх старой. Держите адресацию сервера статической и позвольте туннелю доставлять к нему клиентов.

Проверьте конечную точку, которую использовал клиент

Завершите проверкой на уровне приложения, а не тестом порта. Подключитесь с клиента учётной записью, которую использует приложение, и прочитайте сведения о подключении на стороне сервера, где виден локальный адрес, на который попал ваш сеанс.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

Сравните этот адрес с настроенным слушателем. Несовпадение означает второй слушатель или имя, разрешаемое в неожиданном месте, и то и другое стоит знать до того, как следующая перезагрузка проверит ваше исправление за вас. Затем перезагрузите хост без вошедшего пользователя и убедитесь, что привязка удаётся. Этот единственный тест — разница между починенным слушателем и обходным решением, которое откажет в следующую ночь обновлений.