SQL Server ligas VPN-adreson, kiu ne ekzistas ĉe starto

Legu linion en la SQL Server-protokolo pri malsukcesa ligo dum la servo ankoraŭ funkcias, kaj vi trovis dependecon de la starta ordo, ne paneon. Tiu kombinaĵo estas la indico: la motoro startis antaŭ ol la adreso, sur kiu ĝi devis aŭskulti, ekzistis sur la maŝino. VPN-adaptilo, kiu aperas nur post ensaluto, estas malbona antaŭkondiĉo por datumbaza servo sen prizorgo, do sekvu la malsukceson laŭ la ordo, en kiu la motoro vidas ĝin.

Komencu ĉe la starta protokolo, ne ĉe la kliento

Malfermu la erarprotokolon de la instanco kaj legu la enskribojn ĉirkaŭ la reta pravalorigo, ne nur la lastan linion. La motoro raportas, kiujn adresojn ĝi provis kaj kiujn protokolojn ĝi ebligis, kaj tiu registro estas de antaŭ ol iu kliento konektiĝis. Nun rigardu, kio ekzistas sur la gastiganto nun. Se la interfaco, kiu posedas la agorditan adreson, aperas nur post kiam uzanto ensalutas kaj lanĉas klienton, la adreso forestis ĉe starto kaj la liga fiasko estas plene klarigita.

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

Adaptu la vojon de la instanco al via instalado, kaj legu la interfacan liston antaŭ ol fari konkludojn. Adreso, kiu ekzistas sed apartenas al la malĝusta adaptilo, estas alia problemo ol adreso, kiu ankoraŭ ne ekzistas.

Sekvu la ligan ordon, kiun la motoro efektive sekvas

La motoro legas sian aŭskultantan agordon, poste petas la operaciumon ligi. Se la adreso tiutempe ne estas loka, la ligo malsukcesas por tiu adreso, dum la resto de la instanco povas daŭrigi normale. Tial aliaj protokoloj aŭ aliaj adresoj ankoraŭ povas funkcii, kaj tial „SQL Server estas malaktiva“ estas la malĝusta resumo. Konservu la ĝustan finpunkton el la protokolo: adreso, pordo kaj protokolo, ĉar la riparo dependas de tio, kiu el la tri estas malĝusta.

Restartigi la servon post kiam la adaptilo aperas kutime igos la aŭskultanton sukcesi, kaj ĝuste tio estas la kaptilo. Ĝi pruvas la dependecon anstataŭ forigi ĝin, kaj ĝi interrompas ĉiun konektitan uzanton ĉiufoje, kiam la tunelo rekonektiĝas.

Legu la aŭskultanton tiel, kiel legas ĝin la motoro

En SQL Server Configuration Manager malfermu la TCP/IP-ecojn de la instanco kaj notu la agordon Listen All antaŭ ol redakti unuopajn adresojn. Kiam Listen All estas Yes, la valoroj Enabled por ĉiu adreso estas ignorataj, do redakti ilin ŝanĝas nenion, kion uzas la aŭskultanto. Notu tri aferojn laŭ ordo: la adreson, kiun vi intencas servi, la pordon, kaj ĉu la aŭskultanto celas kovri ĉiujn adresojn aŭ nur unu. Poste apliku la ŝanĝon per la subtenata restartproceduro kaj legu la sekvan startan protokolon por konfirmi, ke la motoro ligis tion, kion vi petis.

Aŭskulti sur ĉiu adreso ne estas alirkontrolo. Se larĝa aŭskultanto vere necesas, ĉiu atingebla interfaco bezonas sian propran fajroŝirman kaj datumbazan rajtigdecidon, inkluzive de iu ajn interfaco turnita al la interreto.

Donu al la kliento stabilan celon

La kliento ne bezonas, ke la datumbaza gastiganto portu basenan adreson. Enkursigita dezajno funkcias kun la servilo aŭskultanta sur sia stabila privata adreso, dum la VPN-enirejo plusendas la trafikon de la kliento al ĝi kaj reportas la respondon.

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

Se la kliento atingas 10.80.0.15, la vojo estas pruvita kaj la datumbazo nur devas rajtigi tiun klienton. Se ne, riparu enkursigadon kaj DNS antaŭ ol tuŝi la aŭskultanton denove, ĉar liga problemo sur la servilo neniam estis la kialo, ke kliento ne povas trovi ĝin. Aldoni falsan basenan adreson al la servilo, aŭ duan implican enirejon por kontentigi la aŭskultanton, kreas novan retan problemon sur la malnova. Tenu la adresadon de la servilo statika kaj lasu la tunnelon konduki klientojn al ĝi.

Kontrolu la finpunkton, kiun uzis la kliento

Finu per aplikaĵnivela kontrolo anstataŭ pordotesto. Konektiĝu el la kliento per la konto, kiun uzas la aplikaĵo, kaj legu la konektajn detalojn ĉe la servila flanko, kiuj montras la lokan adreson, sur kiun surteriĝis via sesio.

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"

Komparu tiun adreson kun la aŭskultanto, kiun vi agordis. Miskongruo signifas duan aŭskultanton aŭ nomon solvatan ie neattendite, kaj ambaŭ indas scii antaŭ ol la sekva restarto testos vian riparon por vi. Poste restartigu la gastiganton sen ensalutinta uzanto kaj konfirmu, ke la ligo sukcesas. Tiu sola testo estas la diferenco inter riparita aŭskultanto kaj provizora solvo, kiu fiaskas en la sekva flika nokto.