SQL Server prisiriša prie VPN adreso, kurio įkrovimo metu nėra

Perskaitykite SQL Server žurnalo eilutę apie nepavykusį prisirišimą, kol paslauga dar veikia, ir radote priklausomybę nuo įkrovos tvarkos, o ne strigtį. Būtent šis derinys yra užuomina: variklis startavo prieš tai, kai mašinoje atsirado adresas, kuriuo jam buvo liepta klausytis. VPN adapteris, pasirodantis po prisijungimo, yra prasta prielaida neprižiūrimai duomenų bazės paslaugai, todėl sekite gedimą ta tvarka, kuria jį mato variklis.

Pradėkite nuo paleidimo žurnalo, o ne nuo kliento

Atidarykite egzemplioriaus klaidų žurnalą ir skaitykite įrašus apie tinklo inicializavimą, o ne vien paskutinę eilutę. Variklis praneša, kuriuos adresus bandė ir kuriuos protokolus įjungė, o tas įrašas yra iš laiko prieš bet kuriam klientui prisijungus. Dabar pažiūrėkite, kas šiuo metu egzistuoja pagrindiniame kompiuteryje. Jei sąsaja, kuriai priklauso sukonfigūruotas adresas, pasirodo tik po to, kai vartotojas prisijungia ir paleidžia klientą, adreso įkrovos metu nebuvo ir prisirišimo gedimas yra visiškai paaiškintas.

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

Pritaikykite egzemplioriaus kelią savo diegimui ir perskaitykite sąsajų sąrašą prieš darydami išvadas. Adresas, kuris egzistuoja, bet priklauso netinkamam adapteriui, yra kita problema nei adresas, kurio dar nėra.

Pereikite prisirišimo tvarką, kurios variklis iš tikrųjų laikosi

Variklis perskaito klausytojo konfigūraciją ir tada paprašo operacinės sistemos prisirišti. Jei adresas tuo metu nėra vietinis, to adreso prisirišimas nepavyksta, o likusi egzemplioriaus dalis gali tęsti normaliai. Todėl kiti protokolai ar kiti adresai vis dar gali veikti, ir todėl „SQL Server neveikia“ yra neteisinga santrauka. Išsaugokite tikslų žurnalo galinį tašką: adresą, prievadą ir protokolą, nes taisymas priklauso nuo to, kuris iš trijų yra neteisingas.

Paslaugos paleidimas iš naujo po to, kai pasirodo adapteris, paprastai lems klausytojo sėkmę, ir tai yra būtent ta spąstai. Tai įrodo priklausomybę, o ne ją pašalina, ir nutraukia kiekvieną prisijungusį vartotoją kiekvieną kartą, kai tunelis vėl prisijungia.

Skaitykite klausytoją taip, kaip jį skaito variklis

SQL Server Configuration Manager atidarykite egzemplioriaus TCP/IP ypatybes ir prieš redaguodami atskirus adresus atkreipkite dėmesį į Listen All nuostatą. Kai Listen All yra Yes, kiekvieno adreso Enabled reikšmės ignoruojamos, todėl jų redagavimas nekeičia nieko, ką naudoja klausytojas. Užrašykite tris dalykus iš eilės: adresą, kurį ketinate aptarnauti, prievadą ir ar klausytojas turi apimti visus adresus, ar tik vieną. Tada pritaikykite pakeitimą palaikoma paleidimo iš naujo procedūra ir perskaitykite kitą paleidimo žurnalą, kad patvirtintumėte, jog variklis prisirišo tai, ko prašėte.

Klausymasis visuose adresuose nėra prieigos kontrolė. Jei plataus klausytojo tikrai reikia, kiekvienai pasiekiamai sąsajai reikia savo ugniasienės ir duomenų bazės autorizacijos sprendimo, įskaitant bet kurią sąsają, nukreiptą į internetą.

Suteikite klientui stabilią paskirties vietą

Klientui nereikia, kad duomenų bazės pagrindinis kompiuteris vilkėtų telkinio adresą. Maršrutizuotas sprendimas veikia, kai serveris klausosi savo stabilaus privataus adreso, o VPN tarpinė perduoda kliento srautą jam ir grąžina atsakymą.

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

Jei klientas pasiekia 10.80.0.15, kelias įrodytas ir duomenų bazei tereikia autorizuoti tą klientą. Jei nepasiekia, pataisykite maršrutizavimą ir DNS prieš vėl liesdami klausytoją, nes prisirišimo problema serveryje niekada nebuvo priežastis, kodėl klientas jo neranda. Netikro telkinio adreso pridėjimas prie serverio ar antroji numatytoji tarpinė, kad klausytojas būtų patenkintas, sukuria naują tinklo problemą ant senosios. Laikykite serverio adresavimą statinį ir leiskite tuneliui atvesti klientus pas jį.

Patikrinkite galinį tašką, kurį naudojo klientas

Baigkite programos lygio patikra, o ne prievado testu. Prisijunkite iš kliento su paskyra, kurią naudoja programa, ir perskaitykite serverio pusės ryšio duomenis, kurie rodo vietinį adresą, kuriame nusileido jūsų sesija.

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"

Palyginkite tą adresą su sukonfigūruotu klausytoju. Nesutapimas reiškia antrą klausytoją arba vardą, sprendžiamą netikėtoje vietoje, ir abu verta žinoti prieš kitam paleidimui iš naujo tikrinant jūsų taisymą už jus. Tada paleiskite pagrindinį kompiuterį iš naujo be prisijungusio vartotojo ir patvirtinkite, kad prisirišimas pavyksta. Tas vienas testas yra skirtumas tarp sutaisyto klausytojo ir apėjimo sprendimo, kuris žlunga kitą pataisų naktį.