SQL Server bindt aan een VPN-adres dat er bij het opstarten niet is

Lees een regel in het SQL Server-log over een mislukte binding terwijl de service nog draait, en je hebt een afhankelijkheid van de opstartvolgorde gevonden, geen crash. Die combinatie is de aanwijzing: de engine startte voordat het adres waarop hij moest luisteren op de machine bestond. Een VPN-adapter die pas na het aanmelden opkomt is een slechte voorwaarde voor een onbeheerde databaseservice, dus volg de fout in de volgorde waarin de engine die ziet.

Begin bij het opstartlog, niet bij de client

Open het foutenlog van de instantie en lees de vermeldingen rond de netwerkinitialisatie, niet alleen de laatste regel. De engine meldt welke adressen hij heeft geprobeerd en welke protocollen hij heeft ingeschakeld, en die registratie is van voordat er een client verbond. Kijk nu wat er op dit moment op de host bestaat. Als de interface die het geconfigureerde adres bezit pas verschijnt nadat een gebruiker zich aanmeldt en een client start, ontbrak het adres bij het opstarten en is de bindingsfout volledig verklaard.

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 het pad van de instantie aan op je installatie en lees de interfacelijst voordat je conclusies trekt. Een adres dat bestaat maar bij de verkeerde adapter hoort, is een ander probleem dan een adres dat nog niet bestaat.

Volg de bindingsvolgorde die de engine werkelijk aanhoudt

De engine leest zijn listenerconfiguratie en vraagt dan het besturingssysteem om te binden. Als het adres op dat moment niet lokaal is, mislukt de binding voor dat adres terwijl de rest van de instantie normaal kan doorgaan. Daarom kunnen andere protocollen of andere adressen nog steeds werken, en daarom is „SQL Server ligt eruit“ de verkeerde samenvatting. Bewaar het exacte eindpunt uit het log: adres, poort en protocol, want de oplossing hangt ervan af welke van de drie onjuist is.

De service herstarten nadat de adapter verschijnt, laat de listener meestal slagen, en dat is precies de valkuil. Het bewijst de afhankelijkheid in plaats van die weg te nemen, en het verbreekt elke verbonden gebruiker telkens wanneer de tunnel opnieuw verbindt.

Lees de listener zoals de engine die leest

Open in SQL Server Configuration Manager de TCP/IP-eigenschappen van de instantie en let op de instelling Listen All voordat je afzonderlijke adressen bewerkt. Staat Listen All op Yes, dan worden de Enabled-waarden per adres genegeerd, dus die bewerken verandert niets van wat de listener gebruikt. Noteer drie dingen op volgorde: het adres dat je wilt bedienen, de poort, en of de listener alle adressen of slechts één moet dekken. Pas de wijziging daarna toe via de ondersteunde herstartprocedure en lees het volgende opstartlog om te bevestigen dat de engine heeft gebonden wat je vroeg.

Op elk adres luisteren is geen toegangsbeheer. Als een brede listener echt nodig is, heeft elke bereikbare interface zijn eigen firewall- en databaseautorisatiebeslissing nodig, inclusief elke interface die naar het internet wijst.

Geef de client een stabiele bestemming

De client heeft niet nodig dat de databasehost een pooladres draagt. Een gerouteerd ontwerp werkt met de server die op zijn stabiele privéadres luistert, terwijl de VPN-gateway het verkeer van de client ernaartoe doorstuurt en het antwoord terugbrengt.

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

Als de client 10.80.0.15 bereikt, is het pad bewezen en hoeft de database alleen die client te autoriseren. Zo niet, herstel dan routing en DNS voordat je de listener weer aanraakt, want een bindingsprobleem op de server was nooit de reden dat een client hem niet kan vinden. Een nep-pooladres aan de server toevoegen, of een tweede standaardgateway om de listener tevreden te stellen, creëert een nieuw netwerkprobleem bovenop het oude. Houd de adressering van de server statisch en laat de tunnel clients naar hem toe brengen.

Verifieer het eindpunt dat de client gebruikte

Sluit af met een controle op applicatieniveau in plaats van een poorttest. Verbind vanaf de client met het account dat de applicatie gebruikt en lees de verbindingsdetails aan de serverkant, die het lokale adres tonen waar je sessie terechtkwam.

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"

Vergelijk dat adres met de listener die je hebt geconfigureerd. Een afwijking betekent een tweede listener of een naam die ergens onverwacht wordt opgelost, en beide zijn het waard om te weten voordat de volgende herstart jouw oplossing voor je test. Herstart daarna de host zonder aangemelde gebruiker en bevestig dat de binding slaagt. Die ene test is het verschil tussen een gerepareerde listener en een workaround die de volgende patchnacht faalt.