SQL Server bënnt eng VPN-Adress, déi beim Start net do ass

Liest eng Zeil am SQL Server-Log iwwer eng feelgeschloe Bindung, während den Service nach leeft, an dir hutt eng Ofhängegkeet vun der Startuerdnung fonnt, keen Abstuerz. Genee déi Kombinatioun ass den Hiweis: den Motor ass gestart, ier d’Adress, op déi hie sollte lauschteren, um Rechner existéiert huet. En VPN-Adapter, deen eréischt no der Umeldung opkënnt, ass eng schlecht Viraussetzung fir en oniwwerwaachte Datebank-Service, also verfollegt de Feeler an der Uerdnung, wéi den Motor en gesäit.

Fänkt beim Startlog un, net beim Client

Maacht de Feelerlog vun der Instanz op a liest d’Anträg ronderëm d’Netzwierkinitialiséierung, net nëmmen déi lescht Zeil. Den Motor mellt, wéi eng Adressen en probéiert huet a wéi eng Protokoller en aktivéiert huet, an déi Opzeechnung ass vun ier sech en Client verbonnen huet. Kuckt elo, wat um Host just elo existéiert. Wann d’Interface, déi déi konfiguréiert Adress besëtzt, eréischt erschéngt, nodeems sech en Benotzer umellt an e Client start, war d’Adress beim Start net do an de Bindungfeeler ass komplett erkläert.

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

Passt de Pad vun der Instanz un Är Installatioun un a liest d’Interface-Lëscht, ier dir Schlussfolgerunge zitt. Eng Adress, déi existéiert, awer dem falschen Adapter gehéiert, ass en anere Problem wéi eng Adress, déi nach net existéiert.

Gitt d’Bindungsuerdnung duerch, déi den Motor tatsächlech verfollegt

Den Motor liest seng Listener-Konfiguratioun an freet dann d’Betribssystem, ze bannen. Wann d’Adress an deem Moment net lokal ass, schléit d’Bindung fir déi Adress fehl, während de Rescht vun der Instanz normal ka weiderlafen. Dofir kënnen aner Protokoller oder aner Adressen nach fonctionéieren, an dofir ass „SQL Server ass erof“ déi falsch Zesummefaassung. Bewaart den exakten Endpunkt aus dem Log: Adress, Port a Protokoll, well d’Korrektur dovun ofhängt, wéi eng vun den dräi falsch ass.

D’Neistarte vum Service, nodeems den Adapter erschéngt, léisst de Listener meeschtens geléngen, an dat ass genee d’Falle. Et beweist d’Ofhängegkeet, amplaz se ewechzehuelen, an et ënnerbrécht all verbonnene Benotzer all Kéier, wann den Tunnel sech nei verbënnt.

Liest de Listener esou, wéi den Motor en liest

Am SQL Server Configuration Manager maacht d’TCP/IP-Eegenschafte vun der Instanz op a bemerkt d’Astellung Listen All, ier dir eenzel Adressen ännert. Wann Listen All op Yes steet, ginn d’Enabled-Wäerter pro Adress ignoréiert, also ännert hir Ännerung näischt, wat de Listener benotzt. Schreift dräi Saachen an der Uerdnung op: d’Adress, déi dir wëllt zerwéieren, de Port, an ob de Listener all Adressen oder nëmmen eng soll decken. Dann applizéiert d’Ännerung iwwer déi ënnerstëtzt Neistartprozedur a liest den nächsten Startlog, fir ze bestätegen, datt den Motor gebonnen huet, wat dir gefrot hutt.

Op all Adress lauschteren ass keng Zougangskontroll. Wann e breede Listener wierklech néideg ass, brauch all erreechbar Interface seng eege Firewall- an Datebank-Autorisatiounsentscheedung, inklusiv all Interface, dat op d’Internet kuckt.

Gitt dem Client en stabilt Zil

De Client brauch net, datt den Datebank-Host eng Pooladress dréit. En gerouteten Design fonctionéiert, während de Server op senger stabiler privater Adress lauschtert an de VPN-Gateway den Trafik vum Client dohi weiderleet an d’Äntwert zréckbréngt.

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

Wann de Client 10.80.0.15 erreecht, ass de Wee bewisen an d’Datebank muss nëmmen dee Client autoriséieren. Wann net, korrigéiert Routing an DNS, ier dir de Listener erëm ufässt, well e Bindungsproblem um Server ni de Grond war, firwat e Client en net ka fannen. Eng falsch Pooladress um Server dobäizesetzen, oder en zweeten Standard-Gateway, fir de Listener zefridden ze stellen, schaaft en neit Netzwierkproblem iwwer dem ale. Halt d’Adresséierung vum Server statesch a loosst den Tunnel d’Clienten dohi bréngen.

Verifizéiert den Endpunkt, deen de Client benotzt huet

Schliesst mat enger Kontroll um Applikatiounsniveau of, net mat engem Porttest. Verbënnt Iech vum Client mam Kont, deen d’Applikatioun benotzt, a liest d’Verbindungsdetailer op der Serversäit, déi déi lokal Adress weisen, op déi Är Sitzung gelant ass.

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"

Vergläicht déi Adress mam Listener, deen dir konfiguréiert hutt. En Ënnerscheed bedeit en zweeten Listener oder en Numm, deen irgendwou onerwaart opgeléist gëtt, an béides ass et wäert ze wëssen, ier den nächsten Neistart Är Korrektur fir Iech testt. Start dann den Host ouni agemellte Benotzer nei a bestätegt, datt d’Bindung geléngt. Dee eenzegen Test ass den Ënnerscheed tëscht engem reparéierten Listener an engem Workaround, deen an der nächster Patch-Nuecht feelgeet.