Instancia con nome de SQL Server por VPN: descubrimento, non o porto 1433

A maioría da xente trata un nome de host de SQL Server como un enderezo completo, e unha VPN como algo permitido ou non. Na práctica, unha instancia con nome obriga o cliente a facer unha segunda busca despois do DNS, e esa busca é a parte que un túnel rompe con máis frecuencia. Un extremo explícito evítaa, por iso tcp:host,port pode funcionar mentres host\INSTANCE esgota o tempo. A diferenza está entre atopar o servizo e ter permiso para usalo.

O mito: un nome de host significa un porto

O nome de host resólvese nun enderezo, e aí remata o seu traballo. Unha instancia con nome engade un nome de instancia que o servidor debe traducir a un porto TCP, e o cliente non pode adiviñalo. O porto 1433 é o predeterminado dunha instancia predeterminada, non unha propiedade de cada instancia da máquina. Tratar as dúas cousas como a mesma produce o síntoma clásico: o ping funciona, o DNS funciona, o escaneo do 1433 non mostra nada, e a conclusión é que a rede bloquea SQL.

Unha segunda suposición falla do mesmo xeito: que abrir TCP 1433 abonda. Se a instancia escoita noutro sitio, un 1433 aberto só demostra que hai outra cousa alí. O porto ten que coincidir co escoitante, e o escoitante é un detalle de configuración do lado do servidor, iso convén preguntalo en lugar de supoñelo.

Que fai realmente o cliente cunha instancia con nome

Tras resolver o host, o cliente envía unha solicitude de descubrimento a SQL Server Browser por UDP 1434 e pregunta que porto usa a instancia con nome. O servizo de navegador responde desde o rexistro do propio servidor, e despois o cliente abre unha conexión TCP a ese porto. Interveñen dous protocolos e dous portos antes de que se intente sequera un inicio de sesión.

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

Por iso un bloqueo só de UDP produce un tempo de espera que parece un host morto. Se o servizo de navegador está detido ou desactivado, a solicitude de descubrimento queda sen resposta aínda que o motor de base de datos estea a funcionar e o seu porto TCP estea aberto. Se a instancia está configurada cun porto estático, o cliente segue preguntando a menos que se lle dese o extremo directamente. Cada unha desas fallas parece idéntica na mensaxe de erro da aplicación, e necesitan correccións distintas.

O servizo de navegador é unha comodidade para o descubrimento, non a base de datos. Detelo non detén o motor, e arrancalo non abre o porto TCP da instancia.

Por que o extremo explícito funciona cando o nome non

Un extremo explícito elimina a busca da secuencia: o cliente conéctase directamente ao enderezo e ao porto que nomeou. Iso é primeiro un diagnóstico, non automaticamente unha solución permanente, porque o porto pode cambiar se máis adiante a instancia se reconfigura a un dinámico. Compare as dúas formas co mesmo cliente e a mesma conta antes de sacar conclusións.

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

Se a forma explícita funciona e a forma con nome falla, o descubrimento é o oco, e podes elixir como pechalo: permitir UDP 1434 a través do túnel, ou pedir ao administrador que fixe un porto estático e documente o extremo. Ambas son decisións deliberadas con custos de mantemento distintos. Abrir todos os portos do rango non é ningunha das dúas, e é a opción que adoita propoñerse ao final dun día longo. Anota a elección onde viven as cadeas de conexión.

Se non funciona ningunha das dúas formas, o problema está máis arriba do descubrimento. Comproba o escoitante, a ruta e a regra de acceso para o porto que a instancia usa realmente antes de culpar o servizo de navegador.

Despois do descubrimento: autenticación e identidade son cousas separadas

Unha falla de inicio de sesión é un evento distinto dun tempo de espera, e a identidade VPN non se converte nun inicio de sesión SQL por ter o túnel. Cando o cliente chega ao porto correcto, o motor de base de datos aplica a súa propia autenticación e os seus permisos. Mesturar as dúas etapas nun só ticket é como un problema de descubrimento acaba asignado ao equipo equivocado. Le o número de erro antes de cambiar nada.

Mantén o nome de host documentado se o controlador valida o certificado do servidor, porque conectarse por enderezo numérico pode cambiar esa comprobación en lugar de resolver o problema orixinal. Os controladores recentes de Microsoft cifran por defecto, así que unha discrepancia de nome aparece como un erro de certificado tras unha conexión TCP correcta. Iso é avance, non unha falla nova.

O mito que hai que retirar é que un nome de host de SQL Server sexa un enderezo completo. É un host máis, para unha instancia con nome, unha busca que o túnel pode non transportar. Nomea o porto, nomea a ruta de descubrimento, e a seguinte falla diráche que capa hai que arranxar.