Por que não consigo me conectar ao Microsoft SQL Server remoto através do túnel SSH?

1

Tenho em casa um roteador D-Link DIR-615 C1 com o DD-WRT . Eu configuro o servidor SSH no roteador e faço logon por meio de uma chave protegida por senha SSH2-RSA. Esse roteador é o gateway entre a rede local e a internet. Um dos computadores dessa rede tem o Microsoft SQL Server 2008 instalado, com o protocolo TCP / IP ativado através da porta 1433. Configurei o encaminhamento de porta no roteador, para que as conexões remotas sejam possíveis e estejam, de fato, funcionando (algumas os desenvolvedores fazem logon remotamente sem problemas).

Eu faço parte de outra rede, que tem acesso à internet através de um servidor proxy, que só tem as portas 80 e 443 abertas. Não consigo me conectar a esse servidor MSSQL nesse servidor remoto porque a porta 1433 está fechada nessa rede. Eu conectei (usando o Putty) pela porta 443 ao servidor SSH do meu roteador e configurei 2 túneis. Uma é para o RDP (3389) e está funcionando. O outro é para a porta 1433, para se conectar ao servidor.

Não consigo me conectar por meio do túnel SSH ao MS SQL Server, nem por meio de telnet ou por meio de clientes GUI.

Estou sentindo falta de algo?

Detalhes adicionais:
na conexão, recebo esse erro do SQL Server Management Studio:

TITLE: Connect to Server

Cannot connect to localhost:14330.


ADDITIONAL INFORMATION:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 3)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=3&LinkId=20476


BUTTONS:

OK

O túnel é configurado assim:
L14330 192.168.0.103:1433
192.168.0.103 é o endereço permanente do SQL Server na LAN. Também enviei com sucesso o tráfego TCP de 3389 port para esse IP, então o tunelamento está funcionando para esse endereço IP.

Ao se conectar sem encapsulamento, através do Microsoft SQL Server Management Studio, usando o mesmo método estabelecido pela conexão. Pena que meu proxy não permite 1433 tráfego de porta, eu não teria essa dor de cabeça.

    
por AlexanderMP 10.02.2011 / 13:37

3 respostas

1

Ao atualizar para um roteador Dlink mais recente, tive o problema de não conseguir mais conectar ao SQL SVR entre os computadores da minha rede (conectados ao roteador Dlink).

Eu encontrei a solução em este fórum .

Desativando "Advanced DNS Service". Habilitado é o padrão.

(Configuração > Internet > Configuração manual de conexão com a Internet > Serviço DNS avançado)

De acordo com o post que encontrei, ele também resolve as dificuldades de conexão do RDP. Houve alguma especulação de que as solicitações de conexão do SQL SVR estavam sendo enviadas para o OpenDNS, evitando assim a conexão desejada.

Para o SQL SVR 2008, existe alguma configuração adicional da área de superfície necessária para permitir conexões, incluindo conexões com instâncias nomeadas.

Observe que com o Open DNS ativado, você pode habilitar as conexões locais do SQL SVR usando as configurações de encaminhamento de porta do roteador Dlink. Se você desativar o Open DNS, as configurações de encaminhamento de porta não serão necessárias para conexões entre computadores na sua rede. Se você quiser permitir conexões SQL SVR da Internet para computadores em sua rede DLink, será necessário configurar isso nas configurações do Virtual Server (não no Port Forwarding). O encaminhamento de porta e o servidor virtual são encontrados na guia avançada.

Meu roteador tem menos de um ano (DIR 655)

    
por 18.05.2011 / 21:34
0

Pensamento aleatório:

Alguns roteadores têm uma configuração de "passagem de VPN" (ou similar).

Do seu link, eu encontrei isso em VPNs

    
por 10.02.2011 / 13:57
0

O servidor MSSQL é acessível a partir do endpoint do túnel / ssh?

Verifique se o IP e a porta de destino estão corretos no túnel ssh.

Verifique se você está conectando um cliente telnet ou gui a LOCALHOST: PORT.

    
por 10.02.2011 / 15:41