SQL Server bineket in VPN-adres dat by it opstarten der net is

Lês in rigel yn it SQL Server-loch oer in mislearre bining wylst de tsjinst noch rint, en do hast in ôfhinklikens fan de opstartfolchoarder fûn, gjin crash. Krekt dy kombinaasje is de oanwizing: de motor starte foardat it adres dêr’t er op harkje moast, op de masine bestie. In VPN-adapter dy’t pas nei it oanmelden opkomt is in minne betingst foar in databankstsjinst sûnder tafersjoch, folgje de flater dan yn ’e folchoarder sa’t de motor him sjocht.

Begjin by it opstartloch, net by de klient

Iepenje it flaterloch fan ’e eksimplaar en lês de ynstjoerings om ’e netwurkinitialisaasje hinne, net allinnich de lêste rigel. De motor rapportearret hokker adressen er besocht hat en hokker protokollen er ynskeakele hat, en dy registraasje is fan foardat der in klient ferbûn. Sjoch no nei wat der op ’e host op dit stuit bestiet. As de interface dy’t it konfigurere adres hat pas ferskynt neidat in brûker oanmeldt en in klient start, wie it adres by it opstarten ôfwêzich en is de biningflater folslein ferklearre.

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

Pas it paad fan ’e eksimplaar oan dyn ynstallaasje oan, en lês de interfacelist foardat do konklúzjes lûkst. In adres dat bestiet mar fan ’e ferkearde adapter is, is in oar probleem as in adres dat noch net bestiet.

Folgje de biningfolchoarder dy’t de motor echt folget

De motor lêst syn listenerkonfiguraasje en freget dan it bestjoeringssysteem om te binden. As it adres op dat stuit net lokaal is, mislearret de bining foar dat adres wylst de rest fan ’e eksimplaar normaal trochgean kin. Dêrom kinne oare protokollen of oare adressen noch wurkje, en dêrom is „SQL Server is del“ de ferkearde gearfetting. Bewarje it krekte einpunt út it loch: adres, poarte en protokol, want de oplossing hinget derfan ôf hokker fan ’e trije ferkeard is.

It opnij starten fan ’e tsjinst neidat de adapter ferskynt sil de listener meastentiids slagje litte, en dat is krekt de fal. It bewiist de ôfhinklikens ynstee fan dy fuort te heljen, en it ferbrekt elke ferbûne brûker elke kear as de tunnel wer ferbynt.

Lês de listener sa’t de motor him lêst

Yn SQL Server Configuration Manager iepenje de TCP/IP-eigenskippen fan ’e eksimplaar en notearje de Listen All-ynstelling foardat do yndividuele adressen bewurkest. As Listen All op Yes stiet, wurde de Enabled-wearden per adres negearre, dus se bewurkje feroaret neat fan wat de listener brûkt. Notearje trije dingen yn folchoarder: it adres dat do betsjinje wolst, de poarte, en oft de listener alle adressen of mar ien dekke moat. Pas dêrnei de feroaring ta fia de stipe werstartproseduere en lês it folgjende opstartloch om te befêstigjen dat de motor bûn hat wat do frege hast.

Op elk adres harkje is gjin tagongskontrôle. As in brede listener echt nedich is, hat elke berikbere interface syn eigen firewall- en databankautorisisaasjebeslút nedich, ynklusyf elke interface dy’t nei it ynternet sjocht.

Jou de klient in stabyle bestimming

De klient hat net nedich dat de databankhost in pooladres draacht. In rûtearre ûntwerp wurket wylst de server op syn stabile privee-adres harket en de VPN-gateway it ferkear fan ’e klient dêrhinne stjoert en it antwurd werombringt.

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

As de klient 10.80.0.15 berikt, is it paad bewiisd en hoecht de databank allinnich dy klient te autorisearjen. As dat net sa is, reparearje rûtelegging en DNS foardat do de listener wer oanrekest, want in biningprobleem op ’e server wie nea de reden dat in klient him net fine kin. It tafoegjen fan in falsk pooladres oan ’e server, of in twadde standertgateway om de listener tefreden te stellen, makket in nij netwurkprobleem boppe-op it âlde. Hâld de adressearring fan ’e server statysk en lit de tunnel kliïnten derhinne bringe.

Ferifiearje it einpunt dat de klient brûkte

Einigje mei in kontrôle op applikaasjenivo ynstee fan in poartetest. Ferbyn fan ’e klient mei it akkount dat de applikaasje brûkt en lês de ferbiningsdetails oan ’e serverkant, dy’t it lokale adres sjen litte dêr’t dyn sesje op telâne kaam.

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"

Fergelykje dat adres mei de listener dy’t do konfigurearre hast. In mismatch betsjut in twadde listener of in namme dy’t earne ûnferwachts oplost, en beide binne it wurdich om te witten foardat de folgjende reboot dyn oplossing foar dy testet. Start dan de host opnij sûnder oanmelde brûker en befêstigje dat de bining slagget. Dy iene test is it ferskil tusken in reparearre listener en in omwei dy’t op ’e folgjende patchnacht mislearret.