ERRO SQL - PRE LOGIN - HANDSHAKE 14998
Olá a todos!
Feliz ano novo galera, ótimo 2017 pra todos vocês.
Então, estou com um problema de conexão com o SQL Server lá na empresa. Na verdade, eu já desconfio o que seja, mas queria a opinião de vocês.
Estou anexando a imagem do erro pra vocês verem.
Isso não acontece todo dia, as vezes sim, as vezes não. Isso é o mais estranho.
Fiz várias pesquisas e todos recomendam a verificar firewall, verificar as portas, etc. Mas se fosse esse o problema, ele não deixaria conectar em momento algum.
Tanto pela minha aplicação, quanto pelo management studio. Dá esse erro de pré-login.
Aà fui olhar o log do SQL Server e reparei algo curioso: Estão tentando descobrir a senha da instância do servidor. Milhares de tentativas durante o dia...
Já consigo imaginar quem seja, algumas pessoas foram demitidas, eles até trocaram a senha lá na época. Enfim...
Já cansei de falar com meu chefe pra usar webservice ou webapi pra poder fazer conexão com o SQL Server, mas ele insiste em fazer conexão remota direta. Deixando tudo muito exposto.
Mas enfim, existe alguma possibilidade dessas tentativas estarem fazendo gerar esse erro?
Foi a única anormalidade que encontrei nos logs.
As outras sugestões na internet eram habilitar ipv6, etc... Mas nada disso dava certo.
Feliz ano novo galera, ótimo 2017 pra todos vocês.
Então, estou com um problema de conexão com o SQL Server lá na empresa. Na verdade, eu já desconfio o que seja, mas queria a opinião de vocês.
Estou anexando a imagem do erro pra vocês verem.
Isso não acontece todo dia, as vezes sim, as vezes não. Isso é o mais estranho.
Fiz várias pesquisas e todos recomendam a verificar firewall, verificar as portas, etc. Mas se fosse esse o problema, ele não deixaria conectar em momento algum.
Tanto pela minha aplicação, quanto pelo management studio. Dá esse erro de pré-login.
Aà fui olhar o log do SQL Server e reparei algo curioso: Estão tentando descobrir a senha da instância do servidor. Milhares de tentativas durante o dia...
Já consigo imaginar quem seja, algumas pessoas foram demitidas, eles até trocaram a senha lá na época. Enfim...
Já cansei de falar com meu chefe pra usar webservice ou webapi pra poder fazer conexão com o SQL Server, mas ele insiste em fazer conexão remota direta. Deixando tudo muito exposto.
Mas enfim, existe alguma possibilidade dessas tentativas estarem fazendo gerar esse erro?
Foi a única anormalidade que encontrei nos logs.
As outras sugestões na internet eram habilitar ipv6, etc... Mas nada disso dava certo.
Em primeiro lugar: Feliz ano novo!
Para [Ô]tirar a prova dos nove[Ô], faça um login local, na mesma máquina onde o server está. Primeiro usando o mesmo método de login que está usando, com senha. Depois, também localmente, conecte usando Trusted Connection. Se o erro ocorrer, é certeza que não é firewall/portas ou qualquer outro problema de rede.
Como você está possivelmente vendo uma tentativa de brute-force, isso significa que o erro deve persistir. Para evitar isso, você poderia usar algumas traquitanas nada recomendáveis:
- VPN
- SSL/TSL
- Modificar a sua rede para bloquear ip[ô]s.
Nada disso vai resolver de vez o problema, como você mesmo mencionou, a maneira mais segura é mesmo com WebAPI.
Para [Ô]tirar a prova dos nove[Ô], faça um login local, na mesma máquina onde o server está. Primeiro usando o mesmo método de login que está usando, com senha. Depois, também localmente, conecte usando Trusted Connection. Se o erro ocorrer, é certeza que não é firewall/portas ou qualquer outro problema de rede.
Como você está possivelmente vendo uma tentativa de brute-force, isso significa que o erro deve persistir. Para evitar isso, você poderia usar algumas traquitanas nada recomendáveis:
- VPN
- SSL/TSL
- Modificar a sua rede para bloquear ip[ô]s.
Nada disso vai resolver de vez o problema, como você mesmo mencionou, a maneira mais segura é mesmo com WebAPI.
Feliz Ano Novo! 
Aqui tem algo parecido e a solução funcionou.
stackoverflow.com/questions/15488922/connection-to-sql-server-works-sometimes
Aqui tem algo parecido e a solução funcionou.
stackoverflow.com/questions/15488922/connection-to-sql-server-works-sometimes
Olá Kerplunk! Tudo bem contigo? Feliz ano novo!
Então, esses erros acontecem de vez em quando. Tem dia que a cada 10 logins, chega a dar problema em 5. Tem dia que o erro nem acontece. Vou criar uma aplicação pra fazer um loop e ficar tentando acessar o banco de dados, dessas duas formas que você falou. Verei se conseguirei os Exceptions. Amanhã eu dou o retorno.
Também ficarei atento aos dias de maior incidência do problema e irei refazer os testes.
Beleza Jaba? Feliz ano novo cara!
Então, esse foi o post que pensei que seria minha salvação quando comecei a pesquisar sobre o erro. Porque é quase idêntico ao meu problema: as vezes ocorre, as vezes não.
Habilitei o IPv6 que estava desabilitado. E no configuration manager, a única diferença foi que usei o IPAll - porque sempre usei assim e nunca tive problema. (Segundo documentação da microsoft, se você seta uma porta para o IPAll, ele desconsidera todos os ips anteriores. Um próprio comentário desse post fala sobre isso:
[Ô] I[ô]m not sure that the individual entries being disabled is a problem as the Protocol tab has an override [ô]listen all[ô] which tells SQL to listen on all IP[ô]s. See the following link for documentation. msdn.microsoft.com/en-us/library/dd981060.aspx[Ô]
Outro teste que irei fazer amanhã, será desconfigurar todas as configurações TCP/IP e vê se com o SQL Browser a coisa fica melhor.
Obrigado a todos!
Ótimo primeiro dia do ano!
Então, esses erros acontecem de vez em quando. Tem dia que a cada 10 logins, chega a dar problema em 5. Tem dia que o erro nem acontece. Vou criar uma aplicação pra fazer um loop e ficar tentando acessar o banco de dados, dessas duas formas que você falou. Verei se conseguirei os Exceptions. Amanhã eu dou o retorno.
Também ficarei atento aos dias de maior incidência do problema e irei refazer os testes.
Beleza Jaba? Feliz ano novo cara!
Então, esse foi o post que pensei que seria minha salvação quando comecei a pesquisar sobre o erro. Porque é quase idêntico ao meu problema: as vezes ocorre, as vezes não.
Habilitei o IPv6 que estava desabilitado. E no configuration manager, a única diferença foi que usei o IPAll - porque sempre usei assim e nunca tive problema. (Segundo documentação da microsoft, se você seta uma porta para o IPAll, ele desconsidera todos os ips anteriores. Um próprio comentário desse post fala sobre isso:
[Ô] I[ô]m not sure that the individual entries being disabled is a problem as the Protocol tab has an override [ô]listen all[ô] which tells SQL to listen on all IP[ô]s. See the following link for documentation. msdn.microsoft.com/en-us/library/dd981060.aspx[Ô]
Outro teste que irei fazer amanhã, será desconfigurar todas as configurações TCP/IP e vê se com o SQL Browser a coisa fica melhor.
Obrigado a todos!
Ótimo primeiro dia do ano!
Bom dia pessoal!
Conforme havia falado, realizei os testes. E hoje foi um ótimo dia pra isso, porque a conexão está um lixo.
Fiz alguns testes com o Windows Authentication e o SQL Server Authentication, como você havia sugerido. Ambos localmente.
Tanto a autenticação do Windows quanto a do SQL Server apresentaram problema quando tentei me conectar pelo IP local. A cada 10 conexões, 4 erros, na média.
Mas quando usei o nome do computador no modo Windows Authentication todas as conexões rodaram bem. Então acho que o problema está realmente no protocolo TCP/IP.
Estou anexando as imagens da configuração do meu SQL Server.
Nas configurações de IP, usei o IPALL, como havia falado anteriormente. Todas as anteriores estão desabilitadas.
Hoje não houveram tentativas de logins indesejadas, então, infelizmente, esse problema não está sendo causado pela tentativa de acesso por força bruta.
Me recomendaram usar um programa Wireshark para monitorar as conexões TCP/IP do computador. Eu nunca fiz algo assim, então terei que dar uma estudada. Acham que posso acabar descobrindo? Recomendam algum outro método para poder descobrir isso?
Muito obrigado!
Tenham uma ótima semana!
Conforme havia falado, realizei os testes. E hoje foi um ótimo dia pra isso, porque a conexão está um lixo.
Fiz alguns testes com o Windows Authentication e o SQL Server Authentication, como você havia sugerido. Ambos localmente.
Tanto a autenticação do Windows quanto a do SQL Server apresentaram problema quando tentei me conectar pelo IP local. A cada 10 conexões, 4 erros, na média.
Mas quando usei o nome do computador no modo Windows Authentication todas as conexões rodaram bem. Então acho que o problema está realmente no protocolo TCP/IP.
Estou anexando as imagens da configuração do meu SQL Server.
Nas configurações de IP, usei o IPALL, como havia falado anteriormente. Todas as anteriores estão desabilitadas.
Hoje não houveram tentativas de logins indesejadas, então, infelizmente, esse problema não está sendo causado pela tentativa de acesso por força bruta.
Me recomendaram usar um programa Wireshark para monitorar as conexões TCP/IP do computador. Eu nunca fiz algo assim, então terei que dar uma estudada. Acham que posso acabar descobrindo? Recomendam algum outro método para poder descobrir isso?
Muito obrigado!
Tenham uma ótima semana!
Acabei de ver o log do usuário Windows Authentication aqui quando tentei entrar pelo IP:
2017-01-02 10:10:38.46 spid15s Server TCP provider failed to listen on [ [ô]any[ô] <ipv6> 1433]. Tcp port is already in use.
2017-01-02 10:10:38.46 spid15s Error: 17182, Severity: 16, State: 1.
2017-01-02 10:10:38.46 spid15s TDSSNIClient initialization failed with error 0x2740, status code 0xa. Reason: Unable to initialize the TCP/IP listener. Only one usage of each socket address (protocol/network address/port) is normally permitted.
2017-01-02 10:10:38.46 spid15s Error: 17182, Severity: 16, State: 1.
2017-01-02 10:10:38.46 spid15s TDSSNIClient initialization failed with error 0x2740, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. Only one usage of each socket address (protocol/network address/port) is normally permitted.
2017-01-02 10:10:38.46 spid15s Error: 17826, Severity: 18, State: 3.
2017-01-02 10:10:38.46 spid15s Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
2017-01-02 10:10:38.46 spid15s Error: 17120, Severity: 16, State: 1.
2017-01-02 10:10:38.46 spid15s SQL Server could not spawn FRunCommunicationsManager thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.
Pelo menos me deu mais informação para continuar a pesquisa.
Irei pesquisar mais e os manterei informados.
Obrigado!
2017-01-02 10:10:38.46 spid15s Server TCP provider failed to listen on [ [ô]any[ô] <ipv6> 1433]. Tcp port is already in use.
2017-01-02 10:10:38.46 spid15s Error: 17182, Severity: 16, State: 1.
2017-01-02 10:10:38.46 spid15s TDSSNIClient initialization failed with error 0x2740, status code 0xa. Reason: Unable to initialize the TCP/IP listener. Only one usage of each socket address (protocol/network address/port) is normally permitted.
2017-01-02 10:10:38.46 spid15s Error: 17182, Severity: 16, State: 1.
2017-01-02 10:10:38.46 spid15s TDSSNIClient initialization failed with error 0x2740, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. Only one usage of each socket address (protocol/network address/port) is normally permitted.
2017-01-02 10:10:38.46 spid15s Error: 17826, Severity: 18, State: 3.
2017-01-02 10:10:38.46 spid15s Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
2017-01-02 10:10:38.46 spid15s Error: 17120, Severity: 16, State: 1.
2017-01-02 10:10:38.46 spid15s SQL Server could not spawn FRunCommunicationsManager thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.
Pelo menos me deu mais informação para continuar a pesquisa.
Irei pesquisar mais e os manterei informados.
Obrigado!
Bom dia!
Então, pelo que pesquisei, o erro deveria estar no fato de ter duas instâncias rodando na mesma porta ou ter algum outro software usando a porta 1433.
Mas isso não acontece.
Pelo menos agora sei que é a porta.
Dei uma olhada e encontrei a lista de conexões na porta. Coloquei anexo (compactei, mas é um arquivo Excel). é muita coisa, realmente. Nem sei se teria como ter esse tanto de conexão, baseado no número de cliente que temos (e nem todos acessam o banco direto). Eu estou passando dando uma limpa nos projetos que fazem conexão remota e vendo se as conexões estão sendo fechadas direitinho.
Para pegar a lista de conexões, usei este software: http://www.nirsoft.net/utils/cports.html
E depois conferi com o comando netstat -na | find [Ô]1433[Ô]
Repare que existem dois IPs locais. Isso é porque o servidor tem duas placas de rede. Não sei se isso afetaria também...
Também tem esse IP local [Ô]0.0.0.0[Ô] que não entendi qual é a dele.
Queria saber a opinião de vocês. Alguma sugestão?
Obrigado!
Então, pelo que pesquisei, o erro deveria estar no fato de ter duas instâncias rodando na mesma porta ou ter algum outro software usando a porta 1433.
Mas isso não acontece.
Pelo menos agora sei que é a porta.
Dei uma olhada e encontrei a lista de conexões na porta. Coloquei anexo (compactei, mas é um arquivo Excel). é muita coisa, realmente. Nem sei se teria como ter esse tanto de conexão, baseado no número de cliente que temos (e nem todos acessam o banco direto). Eu estou passando dando uma limpa nos projetos que fazem conexão remota e vendo se as conexões estão sendo fechadas direitinho.
Para pegar a lista de conexões, usei este software: http://www.nirsoft.net/utils/cports.html
E depois conferi com o comando netstat -na | find [Ô]1433[Ô]
Repare que existem dois IPs locais. Isso é porque o servidor tem duas placas de rede. Não sei se isso afetaria também...
Também tem esse IP local [Ô]0.0.0.0[Ô] que não entendi qual é a dele.
Queria saber a opinião de vocês. Alguma sugestão?
Obrigado!
Estou fechando meus tópicos antigos, e acho legal dar uma satisfação sobre o fim da coisa.
Estava havendo muitas conexões na instância, com muito tráfego de dados. O Buffer pool de memória do SQL Server tava terrÃvel.
Limitei então a quantidade de memória usada pelo SQL Server e usei o Profile para saber as operações mais custosas.
Como temos dois servidores, deixamos um dedicado para essas operações mais custosas.
Também verificamos que existiam aplicações antigas que não estavam fechando a conexão após usar... Deixando conexões abertas, e como consequência, conexões TCP IP.
Sobre as conexões que estavam tentando conectar a cada momento, inicialmente bloqueamos via Firewall mesmo.
O problema é tão chato que precisei fazer um utilitário para verificar as tentativas de conexão no SQL Server, e dependendo da frequência, bloquear no firewall. é uma solução ruim, eu sei. Mas tendo em vista que a empresa está com pouca mão de obra no desenvolvimento e existem muitos serviços para mudar, é o que dá pra fazer.
Irei deixar o tópico aberto caso alguém queira fazer um comentário e estarei fechando.
Abraços!
Estava havendo muitas conexões na instância, com muito tráfego de dados. O Buffer pool de memória do SQL Server tava terrÃvel.
Limitei então a quantidade de memória usada pelo SQL Server e usei o Profile para saber as operações mais custosas.
Como temos dois servidores, deixamos um dedicado para essas operações mais custosas.
Também verificamos que existiam aplicações antigas que não estavam fechando a conexão após usar... Deixando conexões abertas, e como consequência, conexões TCP IP.
Sobre as conexões que estavam tentando conectar a cada momento, inicialmente bloqueamos via Firewall mesmo.
O problema é tão chato que precisei fazer um utilitário para verificar as tentativas de conexão no SQL Server, e dependendo da frequência, bloquear no firewall. é uma solução ruim, eu sei. Mas tendo em vista que a empresa está com pouca mão de obra no desenvolvimento e existem muitos serviços para mudar, é o que dá pra fazer.
Irei deixar o tópico aberto caso alguém queira fazer um comentário e estarei fechando.
Abraços!
Tópico encerrado , respostas não são mais permitidas