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"

Споредете ја таа адреса со слушателот што сте го конфигурирале. Несовпаѓањето значи втор слушател или име што се разрешува некаде неочекувано, и двете вреди да се знаат пред следното рестартирање да ја тестира вашата поправка наместо вас. Потоа рестартирајте го домаќинот без најавен корисник и потврдете дека врзувањето успева. Тој единствен тест е разликата помеѓу поправен слушател и заобиколно решение што паѓа следната ноќ на закрпи.