Benoemde SQL Server-instantie via VPN: ontdekking, niet poort 1433

De meeste mensen behandelen een SQL Server-hostnaam als een volledig adres en een VPN als iets dat wel of niet is toegestaan. In de praktijk laat een benoemde instantie de client na DNS een tweede opzoeking doen, en juist die opzoeking breekt een tunnel het vaakst. Een expliciet eindpunt omzeilt dat, daarom kan tcp:host,port werken terwijl host\INSTANCE afloopt. Het verschil zit tussen de dienst vinden en toestemming krijgen hem te gebruiken.

De mythe: één hostnaam betekent één poort

De hostnaam wordt opgelost naar een adres, en daar eindigt zijn taak. Een benoemde instantie voegt een instantienaam toe die de server naar een TCP-poort moet vertalen, en de client kan die niet raden. Poort 1433 is de standaard voor een standaardinstantie, geen eigenschap van elke instantie op de machine. Beide als hetzelfde behandelen levert het klassieke symptoom op: ping werkt, DNS werkt, de scan van 1433 toont niets, en de conclusie is dat het netwerk SQL blokkeert.

Een tweede aanname faalt op dezelfde manier: dat het openen van TCP 1433 genoeg is. Als de instantie elders luistert, bewijst een open 1433 alleen dat daar iets anders staat. De poort moet bij de listener passen, en dat de listener een configuratiedetail aan serverzijde is dat moet je vragen in plaats van gokken.

Wat de client werkelijk doet met een benoemde instantie

Na het oplossen van de host stuurt de client een ontdekkingsverzoek naar SQL Browser over UDP 1434 en vraagt welke poort de benoemde instantie gebruikt. De browserservice antwoordt uit het register van de server zelf, en daarna opent de client een TCP-verbinding naar die poort. Twee protocollen en twee poorten zijn betrokken voordat er überhaupt een login wordt geprobeerd.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

Daarom levert een blokkade van alleen UDP een time-out op die op een dode host lijkt. Als de browserservice is gestopt of uitgeschakeld, blijft het ontdekkingsverzoek onbeantwoord, ook al draait de databasemotor en staat de TCP-poort open. Als de instantie met een statische poort is geconfigureerd, vraagt de client nog steeds, tenzij het eindpunt direct is gegeven. Elk van die fouten ziet er in de foutmelding van de toepassing hetzelfde uit, en ze vragen verschillende oplossingen.

De browserservice is een gemak voor ontdekking, niet de database. Hem stoppen stopt de motor niet, en hem starten opent de TCP-poort van de instantie niet.

Waarom het expliciete eindpunt werkt als de naam dat niet doet

Een expliciet eindpunt haalt de opzoeking uit de reeks: de client verbindt rechtstreeks met het adres en de poort die je noemde. Dat is eerst een diagnose, niet automatisch een blijvende oplossing, omdat de poort kan veranderen als de instantie later naar een dynamische wordt omgezet. Vergelijk de twee vormen met dezelfde client en hetzelfde account voordat je conclusies trekt.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Als de expliciete vorm slaagt en de benoemde vorm faalt, is ontdekking het gat, en kun je kiezen hoe je het sluit: UDP 1434 door de tunnel toestaan, of de beheerder vragen een statische poort vast te zetten en het eindpunt te documenteren. Beide zijn bewuste beslissingen met verschillende onderhoudskosten. Elke poort in het bereik openzetten is geen van beide, en het is de optie die aan het eind van een lange dag wordt voorgesteld. Leg de keuze vast waar de verbindingsreeksen leven.

Als geen van beide vormen werkt, zit het probleem bovenstrooms van de ontdekking. Controleer de listener, de route en de toegangsregel voor de poort die de instantie werkelijk gebruikt voordat je de browserservice de schuld geeft.

Na de ontdekking: authenticatie en identiteit zijn gescheiden

Een login-fout is een andere gebeurtenis dan een time-out, en de VPN-identiteit wordt door de tunnel geen SQL-login. Zodra de client de juiste poort bereikt, past de databasemotor zijn eigen authenticatie en rechten toe. De twee fasen in één ticket mengen is de manier waarop een ontdekkingsprobleem bij het verkeerde team belandt. Lees het foutnummer voordat je iets verandert.

Houd de gedocumenteerde hostnaam aan als het stuurprogramma het servercertificaat valideert, want verbinden via een numeriek adres kan die controle veranderen in plaats van het oorspronkelijke probleem op te lossen. Recente Microsoft-stuurprogramma's versleutelen standaard, dus een naamafwijking verschijnt als een certificaatfout na een geslaagde TCP-verbinding. Dat is vooruitgang, geen nieuwe fout.

De mythe die je moet laten varen, is dat een SQL Server-hostnaam een volledig adres is. Het is een host plus, voor een benoemde instantie, een opzoeking die de tunnel misschien niet draagt. Noem de poort, noem het ontdekkingspad, en de volgende fout vertelt je welke laag je moet repareren.