Piattaforma di filtraggio di Windows che abbandona le connessioni di SQL Server

Ho indagato i problemi di connessione tra il mio server web (Web01) e un server di database (Database01). La mia configuration corrente:

Web01 – due NIC, uno esterno (firewalled), uno interno (non firewall).
Database01 – Stessa configuration come sopra.

  • SQL2005 vs SQL2008
  • Visualizzazione del risultato di nmap gradualmente in quanto i risultati vengono trovati
  • Dati da una tabella in 1 DB necessari per il filter in DB diversi
  • MySQL smise di funzionare - Errore 2002 - Istanza sconosciuta
  • Problema di authorization con il backup di SQL Server tramite il piano di manutenzione
  • Posso impostare una connessione di collegamento SQL Server tra i server in reti diverse?
  • I due server comunicano sull'utilizzo della NIC privata, quindi il profilo del firewall è distriggersto. Quello che sto trovando, è che ho due errori a Web01:

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

    o

    WEB01: The wait operation timed out

    Questo non è coerente, anche se è più probabile che si verifichi quando eseguo una scansione (via Xenu) su Web01 per eseguire la scansione attraverso un nuovo sito web.

    Su Database01, ho identificato una serie di messaggi dalla piattaforma di filtraggio di Windows:

    DATABASE01: The Windows Filtering Platform has blocked a packet.

    Ricercando questo, è il filter silenzioso di prevenzione della scansione di porte integrato nel firewall di Windows. Questa funzionalità viene eseguita indipendentemente dal fatto che il profilo privato (per la networking privata) sia distriggersto.

    L'intenzione di questa caratteristica è quella di intercettare le richieste di porte in cui non è associato nessun listener e rifiutare il pacchetto.

    Il problema con questo, è la port in questione è la port predefinita del server sql, 1433 e il server sql sta ascoltando.

    Quindi la mia domanda sarebbe, sotto quali altre circostanze il firewall potrebbe cadere i pacchetti in questo modo.

    Altri commenti / possibili problemi / note:

    • Sto usando Entity Framework, con Autofac e il mio context utilizza un ambito di vita per each richiesta . Ciò dovrebbe garantire che i collegamenti siano chiusi e smaltiti al termine di each richiesta, ma internamente questo implementa un model di unità di lavoro, per cui spero che le connessioni siano aperte e chiuse per each operazione di batch, quindi non aspettare la fine di qualsiasi richiesta di esecuzione potenzialmente lunga.
    • La configuration del pool di database per ASP.NET non è stata modificata, pertanto i tempi di connessione e la dimensione del pool di connessione sono tutti impostati su default.
    • La string di connessione ha originariamente specificato il nome del server, quindi l'istanza predefinita: server=database01 , ma per eliminare eventuali problemi con il servizio Browser Sql Server, ho modificato la string di connessione a server=tcp:database01,1433 per eseguire la Si utilizza la connessione TCP (quindi non si preoccupa di provare la memory condivisa oi tubi denominati) e ha specificato la port esattamente (quindi non è necessario interrogare prima il servizio browser per identificare la port corretta).
    • Database01 funge da Principal per il mirroring del database (come parte di una soluzione mirror con 2 server con failover automatico, Database02 come partner e Web01 con SQL Server Express come testimone). Ho distriggersto la mirroring dei database di destinazione e il problema persiste ancora.
    • Ho confermato che sqlserver.exe sta ascoltando sulla port 1433 usando il command netstat -anob -p tcp e può vederlo legato come segue:

    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 

    Nei suddetti risultati, 192.168.3.2 è IP privato per Database01 e 192.168.3.1 è IP privato per Web01, con la port esterna 49274 assegnata dynamicmente dal pool di connessione ASP.NET.

    Ho cercato di eliminare il più ansible, ma non riesco ancora a determinare il problema della radice:

    Perché il pacchetto di Windows Firewall abbandona i pacchetti per una port in ascolto?

    Web01: Windows Server 2012 R2 Standard 64bit

    Database01: Windows Server 2012 64 bit SQL Server 2012 SP1 Standard

  • Visualizzazione del risultato di nmap gradualmente in quanto i risultati vengono trovati
  • Vulnerabilità di networking e servizi di scansione delle porte
  • C'è un modo per vedere cosa effettivamente filtra la comunicazione di port TCP?
  • One Solution collect form web for “Piattaforma di filtraggio di Windows che abbandona le connessioni di SQL Server”

    La soluzione a questo problema è stata una funzionalità denominata TCP Offloading. Non sono sicuro se questo è perché sono in esecuzione in un ambiente virtuale o no, ma TCP Offloading stava causando le pause di pacchetti. Quando questa funzionalità è distriggersta, i pacchetti di goccia sembrano scomparire.

    TCP Offloading rimuove l'onere dell'elaborazione di I / O di networking sulla CPU sparendo sulla NIC.

    Mi chiedo se fossi in esecuzione un ambiente hardware se questo problema si verificherebbe ancora.

    http://www.rackspace.com/knowledge_center/article/disabling-tcp-offloading-in-windows-server-2012

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.