Pregunta

Me he conectado por primera vez a una red existente a través de VPN.Puedo hacer ping a la dirección IP que utiliza SQL Server desde el cliente de VPN, pero SSMS no se conecta a SQL Server.Estoy usando el derecho a la id de inicio de sesión y la contraseña.

¿Por qué pudo suceder esto ?Alguna idea ?

Gracias

¿Fue útil?

Solución

En una instancia predeterminada, SQL Server escucha en TCP / 1433 de forma predeterminada. Esto se puede cambiar. En una instancia con nombre, a no ser configurado de forma diferente, SQL Server escucha en un puerto TCP dinámico. Lo que esto significa es SQL Server debe descubrir que el puerto está en uso, se elige otro puerto TCP. Cómo los clientes suelen encontrar el puerto correcto en el caso de una instancia con nombre es hablando con el / Navegador de servicios de escucha de SQL Server SQL. Que escucha en UDP / 1434 y no se puede cambiar. Si usted tiene una instancia con nombre, puede configurar un puerto estático y si usted tiene una necesidad para utilizar la autenticación Kerberos / delegación, debería hacerlo.

¿Qué se necesita para determinar lo que es el puerto de SQL Server está escuchando. A continuación, tendrá que obtener con tus amigos de redes / seguridad para determinar si permiten la comunicación a ese puerto a través de VPN. Si lo son, como se ha indicado, verifica la configuracion de firewall. Algunos sistemas tienen múltiples servidores de seguridad (mi portátil es un ejemplo). Si es así, tendrá que comprobar todos los servidores de seguridad en su sistema.

Si todos los que son correctas, verificar que el servidor no tiene una política IPSec que restringe el acceso al puerto de SQL Server a través de la dirección IP. Esto también podría dar lugar a que ser bloqueado.

Otros consejos

Cuando esto sucede a mí, es porque DNS no está funcionando correctamente. Trate de usar la dirección IP en lugar del nombre del servidor en el inicio de sesión de SQL Server.

Asegúrese de que SQL Server está habilitado para TCP / IP (alguien puede haber inhabilitado)?

Esto también le ayudará a comprobar / verificar el número de puerto de la instancia de SQL está utilizando (en caso de que alguien cambiado el valor predeterminado de puerto 1433).

Es evidente que el puerto 1433 (o lo que sea SQL puerto está escuchando en) necesita ser desbloqueado por servidores de seguridad entre el equipo y el cuadro de SQL se está ejecutando.

Para comprobar la configuración de red de SQL (requiere herramientas de cliente de SQL Server instalado): Inicio -> Programas -> SQL Server 200x -> Herramientas de configuración -> Administrador de configuración de SQL Server

Conectar a la máquina que necesita a continuación, expanda el elemento de árbol "Configuración de red de SQL Server" (LHS), a continuación, elegir instancia. Usted debe tener cuatro opciones - Memoria compartida, canalizaciones con nombre, TCP / IP y VIA. Puede comprobar que TCP / IP está habilitado en la ventana del lado derecho.

Si se hace doble clic en TCP / IP y pulse la pestaña "Avanzado", también se puede ver el número de puerto.

Otros pensamientos .. ¿Está utilizando la autenticación de SQL o la autenticación de Windows (dominio)?

  • Si SQL autenticación (que supongo que está utilizando dará usted ha dicho nombre de usuario y contraseña), ¿está seguro de la instancia de SQL que se está conectando ha mezclado la autenticación en modo activado? Si no es así, usted tiene que conectar como administrador y cambiar la configuración de seguridad predeterminada para permitir la autenticación de SQL.

  • Si la autenticación de Windows, podría estar utilizando su red de Kerberos potencialmente? Uno podría pensar que las credenciales de VPN se utilizarían para el apretón de manos. Me revisar su cuenta tiene derechos de acceso adecuados.

Compruebe que el puerto que SQL Server está utilizando no está siendo bloqueado por el servidor de seguridad o de la VPN.

También he tenido este problema al intentar conectarse de forma remota a través de la Hamachi VPN.Yo había intentado todo disponible en internet (incluyendo este post) y que todavía no funciona.Tenga en cuenta que todo funcionaba bien cuando la misma base de datos se instala en un equipo en mi red local.Finalmente fui capaz de alcanzar el éxito mediante la siguiente corrección:en la máquina remota, activar la dirección IP en el protocolo TCP/IP, así:

En el equipo remoto, inicie SQL Server Configuration Manager, expanda SQL Server Configuración de Red, seleccione "Protocolos de SQLEXPRESS" (o "MSSQLSERVER"), haga clic en TCP/IP, en el cuadro de diálogo ir a la pestaña Direcciones IP, y asegúrese de que el "IP1" es el elemento Active=Yes y Enabled=Yes.Tome nota de la dirección IP (para mí no era necesario modificar estos).A continuación, detener e iniciar los Servicios de SQL Server.Después de eso, asegúrese de que el firewall en la máquina remota está deshabilitado, o una excepción es permitido para el puerto 1433, que incluye tanto la subred local y la subred para la dirección que aparece en el cuadro de diálogo anterior.En el equipo local debe ser capaz de conectarse mediante la configuración del servidor de nombre a 192.168.1.22\SQLEXPRESS (o [ip address of remote machine]\[SQL server instance name]).

Espero que ayude.

Puede que no tenga el puerto UDP de apertura / VPN-remitida, es el número de puerto 1433.

A pesar de cliente nombre del protocolo de "TCP / IP", mssql utiliza UDP para bitbanging.

SQL Server utiliza el puerto TCP 1433. Esto probablemente está bloqueado, ya sea por el túnel VPN o por un cortafuegos en el servidor.

Cuando se conecta a VPN cada mensaje pasa a través del servidor VPN y no se pudo reenviar sus mensajes a ese servidor SQL puerto está trabajando.

Trate

desactivar VPN configuración-> Propiedades-> TCP / IP propiedades-> Avanzado-> Usar puerta de enlace predeterminada en la red remota.

De este modo, en primer lugar tratar de conectar IP local del servidor SQL y sólo entonces utilizar el servidor VPN para reenviar usted

Tengo este problema mucho con Citrix Access Gateway. Por lo general obtener un error de tiempo de espera. Si usted es capaz de conectarse a la base de datos de un cliente en la red, pero no desde un cliente remoto a través de VPN, se puede olvidar la mayoría de las sugerencias que se dan aquí, porque todos los problemas del lado del servidor de direcciones.

Soy capaz de conectarse cuando aumento el tiempo de espera predeterminado (15 segundos) a 60 segundos, y por una buena medida, la fuerza del protocolo TCP / IP. Estas cosas se pueden hacer en la pantalla del cuadro de diálogo Opciones de entrada:

`

Esto es lo que me arregló el problema de conexión de acceso a la base de datos de SQL Server 2012 a través de VPN

Con el Administrador de configuración de SQL Server 2012,

Fui a la configuración de red de SQL Server

A continuación, hace clic en la instancia del servidor de NUEVO y haga doble clic en el protocolo TCP / IP [También había permitido previamente esta opción y reiniciado el servidor, pero que todavía no se ha solucionado el problema]

Ahora que el protocolo TCP / IP se ha activado, he observado que todas las ranuras de puertos IP en la pestaña de TCP los 'dirección IP' / Propiedades Advanced IP de diálogo se establece en Enabled = n.

Tenía curiosidad por qué mi nueva instalación fija todas estas ranuras IP a NO en lugar de Sí, por lo que sólo les cambió a SÍ.

Ahora la conexión al cortar a través de VPN funciona muy bien, no realizó ningún cambio de números de puerto.

Nota: También tuve SQL Server predeterminada desde el Visual Studio 2010 desinstalado 2008, pero no creo que tenían un efecto directo de la situación de TCP / IP. Un compañero de trabajo me dijo que las instalaciones del 2008 y 2005 que vienen con Visual Studio pueden interferir con SQL 2012.

Como siempre y cuando tenga el servidor de seguridad configurado para permitir que el puerto de la instancia de SQL Server está utilizando, todo lo que tiene que hacer es cambiar de origen de datos de =Server name a =IP,Port

es decir, en la cadena de conexión usar algo como esto.

Data Source=190.190.1.100,1433;

Usted no debería tener que cambiar nada en el lado del cliente.

Yo estaba teniendo este problema también con SQL Server 2017.

Estoy en la misma red que el servidor a través de VPN y se puede hacer ping. Después de haber sido frustrados que ningún método de autenticación funcionaría - I fijó un servidor SSH en el servidor SQL - y yo era capaz de conectar con normalidad. Esto confirmó el puerto correcto no estaba siendo golpeado por alguna razón. Incluso he creado una nueva cuenta de usuario, cuentas de dominio, cheques de firewall en ambos extremos, etc ...

La solución para mí fue: 1. Conjunto de conexión para utilizar estrictamente TCP / IP en SSMS 2. Utilice una cadena personalizada para que apunte al puerto por defecto (por ejemplo: Data Source = 192.168.168.166,1433;)

Todos los demás comentarios anteriores no han funcionado hasta ahora. Parece que era obligatorio incluir el puerto (a pesar de que su valor por defecto).

si está utilizando SQL Server 2005, inicie el servicio Explorador de SQL Server primero

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top