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"

Упоредите ту адресу са слушаоцем који сте конфигурисали. Неслагање значи други слушалац или име које се разрешава негде неочекивано, а обоје је вредно знати пре него што следеће поновно покретање тестира вашу поправку уместо вас. Затим поново покрените хост без пријављеног корисника и потврдите да повезивање успева. Тај једини тест разлика је између поправљеног слушаоца и заобилазног решења које пада следеће ноћи закрпа.