Windows Filtering Platform eliminando conexões do SQL Server

Question

Eu tenho investigado problemas de conexão entre meu servidor web (Web01) e um servidor de banco de dados (Database01). Minha configuração atual:

Web01 - duas NICs, uma externa (com firewall), uma interna (não com firewall).
Database01 - Mesma configuração como acima.

Os dois servidores se comunicam usando a NIC privada, portanto, o perfil do firewall é desativado. O que estou descobrindo é que recebo dois erros no Web01:

WEB01: A transport-level error has occurred when receiving results from the server. (provider: Session Provider, error: 19 - Physical connection is not usable)

ou

WEB01: The wait operation timed out

Isso não é consistente, embora seja mais provável que ocorra quando estou executando um rastreamento (via Xenu) no Web01 para rastrear um novo site.

No Database01, identifiquei uma série de mensagens da Plataforma de Filtragem do Windows:

DATABASE01: The Windows Filtering Platform has blocked a packet.

Pesquisando isso, é o silencioso Filtro de Prevenção de Varredura de Portas embutido no Firewall do Windows. Esse recurso é executado independentemente do fato de o perfil Privado (para a NIC privada) estar desativado.

A intenção desse recurso é interceptar solicitações de portas nas quais nenhum ouvinte está conectado e rejeitar o pacote.

O problema é que a porta em questão é a porta padrão do sql server, 1433 e o sql server está escutando.

Então, minha pergunta seria, sob quais outras circunstâncias, o firewall descartaria os pacotes dessa maneira.

Outros comentários / possíveis problemas / notas:

• Estou usando o Entity Framework, com o Autofac, e meu contexto usa um escopo de vida útil por solicitação . Isso deve garantir que as conexões sejam fechadas e descartadas no final de cada solicitação, mas internamente isso implementa um modelo de Unidade de Trabalho, pelo qual eu espero que as conexões sejam abertas e fechadas para cada operação em lote, portanto, não deve aguardar o término de qualquer solicitação potencialmente longa em execução.
• A configuração do pool de banco de dados para o ASP.NET não foi alterada, portanto, o tempo de vida da conexão e o tamanho do conjunto de conexões estão todos definidos como padrão.
• A cadeia de conexão originalmente apenas especificou o nome do servidor, portanto, a instância padrão: server=database01 , mas para eliminar possíveis problemas com o serviço Sql Server Browser, modifiquei a cadeia de conexão para server=tcp:database01,1433 para impor o TCP a conexão é usada (por isso, não se incomoda em tentar a memória compartilhada ou pipes nomeados), e especificou a porta exatamente (portanto, não é necessário consultar primeiro o serviço do navegador para identificar a porta correta).
• O Database01 atua como um Principal para espelhamento de banco de dados (como parte de uma solução de espelhamento de 2 servidores com failover automático, Database02 como parceiro e Web01 executando o SQL Server Express como testemunha). Eu desabilitei o espelhamento dos bancos de dados de destino e o problema ainda ocorre.
• Confirmei que sqlserver.exe está escutando na porta 1433 usando o comando netstat -anob -p tcp e pode vê-lo vinculado da seguinte forma:

netstat -anob -p tcp

TCP    0.0.0.0:1433        0.0.0.0:0            LISTENING      1896
TCP    192.168.3.2:1433    192.168.3.2:49274    ESTABLISHED    1896

Nos resultados acima, 192.168.3.2 é o IP privado para Database01 e 192.168.3.1 é o IP privado para Web01, com a porta externa 49274 sendo dinamicamente atribuída pelo pool de conexão ASP.NET.

Eu tentei eliminar o máximo possível, mas ainda não consegui determinar o problema raiz:

Por que o Firewall do Windows está descartando pacotes para uma porta que está sendo ouvida?

Web01: Windows Server 2012 R2 Standard 64 bits

Banco de dados01: Windows Server 2012 64 bits Padrão do SQL Server 2012 SP1

    

Answer 1

A solução para esse problema foi um recurso chamado TCP Offloading. Não tenho certeza se isso é porque eu estou executando em um ambiente virtualizado ou não, mas o descarregamento de TCP estava causando o pacote cai. Quando esse recurso é desativado , os pacotes drop parecem desaparecer.

O TCP Offloading elimina a carga de processamento de E / S da rede na CPU, transferindo-o para a NIC.

Pergunto-me se eu estava executando um ambiente de hardware se esse problema ainda ocorresse.

link