Namngiven SQL Server-instans över VPN: upptäckt, inte port 1433

De flesta behandlar ett SQL Server-värdnamn som en fullständig adress och en VPN som antingen tillåten eller inte. I praktiken får en namngiven instans klienten att göra en andra sökning efter DNS, och det är den sökningen en tunnel oftast bryter. En explicit slutpunkt kringgår den, därför kan tcp:host,port fungera medan host\INSTANCE löper ut. Skillnaden är mellan att hitta tjänsten och att få tillstånd att använda den.

Myten: ett värdnamn betyder en port

Värdnamnet löses upp till en adress, och där slutar dess arbete. En namngiven instans lägger till ett instansnamn som servern måste översätta till en TCP-port, och klienten kan inte gissa det. Port 1433 är standard för en standardinstans, inte en egenskap hos varje instans på maskinen. Behandlar man de två som samma sak uppstår det klassiska symptomet: ping fungerar, DNS fungerar, skanningen av 1433 visar ingenting, och slutsatsen är att nätverket blockerar SQL.

En andra förutsättning faller på samma sätt: att det räcker att öppna TCP 1433. Om instansen lyssnar någon annanstans bevisar en öppen 1433 bara att något annat finns där. Porten måste matcha lyssnaren, och att lyssnaren är en konfigurationsdetalj på serversidan det bör man fråga om i stället för att gissa.

Vad klienten faktiskt gör med en namngiven instans

Efter att ha löst upp värden skickar klienten en upptäcktsbegäran till SQL Server Browser över UDP 1434 och frågar vilken port den namngivna instansen använder. Webbläsartjänsten svarar från serverns eget register, och sedan öppnar klienten en TCP-anslutning till den porten. Två protokoll och två portar är inblandade innan en inloggning ens försöks.

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

Därför ger en blockering av bara UDP en tidsgräns som ser ut som en död värd. Om webbläsartjänsten är stoppad eller inaktiverad förblir upptäcktsbegäran obesvarad även om databasmotorn kör och dess TCP-port är öppen. Om instansen är konfigurerad med en statisk port frågar klienten ändå, om den inte fick slutpunkten direkt. Vart och ett av dessa fel ser likadant ut i programmets felmeddelande, och de behöver olika rättelser.

Webbläsartjänsten är en bekvämlighet för upptäckt, inte databasen. Att stoppa den stoppar inte motorn, och att starta den öppnar inte instansens TCP-port.

Varför den explicita slutpunkten fungerar när namnet inte gör det

En explicit slutpunkt tar bort sökningen från sekvensen: klienten ansluter direkt till adressen och porten du angav. Det är först en diagnos, inte automatiskt en varaktig lösning, eftersom porten kan ändras om instansen senare konfigureras om till en dynamisk. Jämför de två formerna med samma klient och samma konto innan du drar slutsatser.

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

Om den explicita formen lyckas och den namngivna misslyckas är upptäckten gapet, och du kan välja hur du stänger det: tillåt UDP 1434 genom tunneln, eller be administratören fästa en statisk port och dokumentera slutpunkten. Båda är medvetna beslut med olika underhållskostnader. Att öppna varje port i intervallet är ingen av dem, och det är alternativet som brukar föreslås i slutet av en lång dag. Skriv ned valet där anslutningssträngarna bor.

Om ingen av formerna fungerar sitter problemet uppströms om upptäckten. Kontrollera lyssnaren, vägen och åtkomstregeln för den port instansen faktiskt använder innan du skyller på webbläsartjänsten.

Efter upptäckten: autentisering och identitet är åtskilda

Ett inloggningsfel är en annan händelse än en tidsgräns, och VPN-identiteten blir inte en SQL-inloggning i kraft av tunneln. När klienten når rätt port tillämpar databasmotorn sin egen autentisering och sina behörigheter. Att blanda de två faserna i ett ärende är hur ett upptäcktsproblem hamnar hos fel team. Läs felnumret innan du ändrar något.

Behåll det dokumenterade värdnamnet om drivrutinen validerar serverns certifikat, eftersom anslutning via numerisk adress kan ändra den kontrollen i stället för att lösa det ursprungliga problemet. Nyare Microsoft-drivrutiner krypterar som standard, så en namnavvikelse dyker upp som ett certifikatfel efter en lyckad TCP-anslutning. Det är framsteg, inte ett nytt fel.

Myten som bör lämnas är att ett SQL Server-värdnamn är en fullständig adress. Det är en värd plus, för en namngiven instans, en sökning som tunneln kanske inte bär. Namnge porten, namnge upptäcktsvägen, och nästa fel talar om vilket lager som ska repareras.