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"

Параўнайце гэты адрас са слухачом, які вы наладзілі. Нясупадзенне азначае другі слухач або імя, якое развязваецца нечакана, і абодва варта ведаць, перш чым наступная перазагрузка праверыць ваша выпраўленне за вас. Затым перазагрузіце хост без увайшоўшага карыстальніка і пацвердзіце, што прывязванне паспяховае. Гэты адзіны тэст — розніца паміж адрамантаваным слухачом і абыходным рашэннем, якое падае ў наступную ноч абнаўлення.