Instància amb nom de SQL Server per VPN: descobriment, no el port 1433

La majoria de la gent tracta un nom d'amfitrió de SQL Server com una adreça completa, i una VPN com si fos permesa o no. A la pràctica, una instància amb nom fa que el client faci una segona consulta després del DNS, i aquesta consulta és la part que un túnel trenca més sovint. Un punt final explícit l'evita, i per això tcp:host,port pot funcionar mentre que host\INSTANCE es queda sense temps. La diferència és entre trobar el servei i tenir permís per utilitzar-lo.

El mite: un nom d'amfitrió significa un port

El nom d'amfitrió es resol en una adreça, i aquí s'acaba la seva feina. Una instància amb nom afegeix un nom d'instància que el servidor ha de traduir a un port TCP, i el client no el pot endevinar. El port 1433 és el predeterminat d'una instància predeterminada, no una propietat de cada instància de la màquina. Tractar les dues coses com la mateixa produeix el símptoma clàssic: el ping funciona, el DNS funciona, l'escaneig del 1433 no mostra res, i la conclusió és que la xarxa bloqueja SQL.

Una segona suposició falla de la mateixa manera: que obrir el TCP 1433 és suficient. Si la instància escolta en un altre lloc, un 1433 obert només demostra que hi ha una altra cosa allà. El port ha de coincidir amb l'oient, i l'oient és un detall de configuració del costat del servidor cal preguntar-ho en lloc de suposar-ho.

Què fa realment el client amb una instància amb nom

Després de resoldre l'amfitrió, el client envia una sol·licitud de descobriment a SQL Server Browser per UDP 1434 i pregunta quin port utilitza la instància amb nom. El servei de navegador respon des del registre del propi servidor, i després el client obre una connexió TCP a aquest port. Hi intervenen dos protocols i dos ports abans que es faci cap intent d'inici de sessió.

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

Per això un bloqueig només d'UDP produeix un temps d'espera que sembla un amfitrió mort. Si el servei de navegador està aturat o desactivat, la sol·licitud de descobriment queda sense resposta encara que el motor de base de dades estigui funcionant i el seu port TCP estigui obert. Si la instància està configurada amb un port estàtic, el client encara pregunta tret que se li hagi donat el punt final directament. Cadascuna d'aquestes falles sembla idèntica al missatge d'error de l'aplicació, i necessiten correccions diferents.

El servei de navegador és una comoditat per al descobriment, no la base de dades. Aturar-lo no atura el motor, i engegar-lo no obre el port TCP de la instància.

Per què el punt final explícit funciona quan el nom no ho fa

Un punt final explícit treu la consulta de la seqüència: el client es connecta directament a l'adreça i al port que has indicat. Això és primer un diagnòstic, no automàticament una correcció permanent, perquè el port pot canviar si més endavant la instància es reconfigure a un de dinàmic. Compara les dues formes amb el mateix client i el mateix compte abans de treure conclusions.

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

Si la forma explícita funciona i la forma amb nom falla, el descobriment és el forat, i pots triar com tancar-lo: permetre l'UDP 1434 a través del túnel, o demanar a l'administrador que fixi un port estàtic i documenti el punt final. Totes dues són decisions deliberades amb costos de manteniment diferents. Obrir tots els ports del rang no és cap de les dues, i és l'opció que sol proposar-se al final d'un dia llarg. Anota l'elecció allà on viuen les cadenes de connexió.

Si no funciona cap de les dues formes, el problema és més amunt del descobriment. Comprova l'oient, la ruta i la regla d'accés per al port que la instància utilitza realment abans de culpar el servei de navegador.

Després del descobriment: autenticació i identitat són coses separades

Una fallada d'inici de sessió és un esdeveniment diferent d'un temps d'espera, i la identitat VPN no es converteix en un inici de sessió SQL pel fet de tenir el túnel. Un cop el client arriba al port correcte, el motor de base de dades aplica la seva pròpia autenticació i permisos. Barrejar les dues etapes en un sol tiquet és com un problema de descobriment s'assigna a l'equip equivocat. Llegeix el número d'error abans de canviar res.

Mantén el nom d'amfitrió documentat si el controlador valida el certificat del servidor, perquè connectar-se per adreça numèrica pot canviar aquesta comprovació en lloc de resoldre el problema original. Els controladors recents de Microsoft xifren per defecte, així que una discrepància de nom apareix com un error de certificat després d'una connexió TCP correcta. Això és un avenç, no una fallada nova.

El mite que cal retirar és que un nom d'amfitrió de SQL Server sigui una adreça completa. És un amfitrió més, per a una instància amb nom, una consulta que el túnel potser no transporta. Anomena el port, anomena el camí de descobriment, i la propera fallada et dirà quina capa cal arreglar.