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"

Сравнете този адрес със слушателя, който сте конфигурирали. Несъответствието означава втори слушател или име, което се резолвва на неочаквано място, и двете си струва да се знаят, преди следващото рестартиране да тества поправката ви вместо вас. След това рестартирайте хоста без влязъл потребител и потвърдете, че свързването е успешно. Този единствен тест е разликата между поправен слушател и заобиколно решение, което се проваля в следващата нощ на пачове.