RST TCP casuale su alcuni siti Web, cosa sta succedendo?

Versione breve: un computer Windows Server 2012 sulla mia rete sta diventando RST TCP persistenti ma intermittenti durante la connessione a determinati siti Web. Non so da dove vengano. Controlla il registro di WireShark per le mie analisi e domande.

Versione lunga:

Eseguiamo un web-proxy di cache su uno dei nostri server per servire il nostro piccolo ufficio. Un collega ha riferito di aver ricevuto molti errori di "Ripristino connessione" o "Impossibile visualizzare la pagina" durante la connessione a determinati siti, ma in genere l'aggiornamento viene risolto.

Ho verificato il comportamento del browser e quindi più direttamente provando un browser non proxy sul server stesso. Ma ping e traceroute su siti problematici non mostrano alcun problema, i problemi sembrano limitarsi alle connessioni TCPC.

Ho quindi creato uno script per testare i siti interessati inviando loro richieste HTTP HEAD direttamente tramite cURL e verificando la frequenza con cui hanno successo. Un test tipico è simile al seguente: (non è proxy, in esecuzione direttamente sul server danneggiato)

C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0     Response Code: NULL (0%)
20:22:02: Length: 0     Response Code: NULL (0%)
20:22:22: Length: 0     Response Code: NULL (0%)
20:22:42: Length: 0     Response Code: NULL (0%)
20:23:02: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174  Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0     Response Code: NULL (28.57%)
20:24:03: Length: 3171  Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172  Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0     Response Code: NULL (45.45%)

A lungo termine, solo il 60% circa delle richieste ha esito positivo, il resto non restituisce nulla, con un codice di errore di arricciatura di: "errore cURL (56): errore durante la ricezione di dati dal peer" Il cattivo comportamento è coerente per i siti Web I test (nessun sito è mai "migliorato") ed è abbastanza persistente, sto risolvendo il problema da una settimana ormai, e i colleghi segnalano che il problema è stato lì per mesi apparentemente.

Ho testato lo script di richiesta HEAD su altri computer della nostra rete: nessun problema, tutte le connessioni passano attraverso tutti i siti del mio elenco di test. Quindi ho impostato un proxy sul mio desktop personale e quando eseguo le richieste HEAD dal server problematico, tutte le connessioni passano. Quindi, qualunque sia il problema, è molto specifico per questo server.

Successivamente ho cercato di isolare quali siti Web presentano il comportamento di reimpostazione della connessione:

• Nessuno dei nostri siti intranet (192.168.xx) interrompe le connessioni.
• Nessun sito ipv6 che ho testato rilascia connessioni. (Siamo a doppio stack)
• Solo una piccola minoranza di siti Internet IPV4 interrompe le connessioni.
• Ogni sito che utilizza cloudflare come CDN (che ho testato) interrompe le connessioni. (ma il problema non sembra essere esclusivo dei siti cloudflare)

Questo angolo non si stava sviluppando in qualcosa di veramente utile, quindi ho installato WireShark per vedere cosa stava succedendo quando una richiesta falliva. Le richieste HEAD non riuscite si presentano così: (schermata più grande qui: http://imgur.com/TNfRUtX )

127 48.709776000    192.168.1.142   192.33.31.56    TCP 66  52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000    192.33.31.56    192.168.1.142   TCP 66  http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000    192.168.1.142   192.33.31.56    TCP 54  52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000    192.168.1.142   192.33.31.56    HTTP    234 HEAD / HTTP/1.1 
131 48.740917000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000    192.33.31.56    192.168.1.142   TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897

Il modo in cui sto leggendo questo (correggimi se sbaglio, questa non è davvero la mia area) è che:

• Apriamo una connessione tcp al server web
• server web ACK
• La richiesta HTTP HEAD è stata inviata
• Esiste un pacchetto RST, contrassegnato come dall'IP del server web, che interrompe la connessione.
• Il server web invia ACK
• Webserver (tenta) di rispondere alla richiesta HEAD con dati HTTP validi (La risposta a 951 byte contiene l'intestazione HTTP corretta)
• Il server web ritrasmette (più volte nell'arco di alcuni secondi) la risposta HTTP valida, ma non può avere successo poiché la connessione è stata RST

Quindi se il server web ha inviato un RST valido, perché continua a provare a riempire la richiesta? E se il server web non ha generato l'RST, che diamine ha fatto?

Le cose che ho provato che non hanno avuto alcun effetto:

• Disabilitazione del team NIC
• Sostituzione della scheda di rete (si sapeva che la scheda di rete sostitutiva funzionava)
• Assegnare un ip statico.
• Disabilitazione di ipv6.
• Disabilitazione dei jumbo frame.
• Collegando il server direttamente al nostro modem una notte, bypassando i nostri switch e router.
• Disattivazione del firewall di Windows.
• Ripristino delle impostazioni TCP tramite netsh
• Disabilitando praticamente ogni altro servizio sul server. (Lo usiamo principalmente come fileserver, ma ci sono apache e un paio di DB)
• Sbattere la testa sulla scrivania (ripetutamente)

Sospetto che qualcosa sul server stia generando i pacchetti RST, ma per la vita di me non riesco a trovarlo. Mi sento come se lo sapessi: perché è solo questo server? O perché solo alcuni siti Web? sarebbe di grande aiuto. Mentre sono ancora curioso, sono sempre più propenso a lanciarmi in un'orbita e ricominciare da capo.

Idee / Suggerimenti?

-Grazie

La tua acquisizione di pacchetti ha avuto qualcosa di insolito: i bit ECN sono stati impostati nel pacchetto SYN in uscita.

La notifica esplicita della congestione è un'estensione del protocollo IP che consente agli host di reagire più rapidamente alla congestione della rete. È stato introdotto per la prima volta in Internet 15 anni fa, ma sono stati rilevati gravi problemi quando è stato distribuito per la prima volta. Il più grave di questi era che molti firewall rilasciavano pacchetti o restituivano un RST quando ricevevano un pacchetto SYN con i bit ECN impostati.

Di conseguenza, la maggior parte dei sistemi operativi disabilita l'ECN per impostazione predefinita, almeno per le connessioni in uscita. Di conseguenza, sospetto che molti siti (e fornitori di firewall!) Semplicemente non abbiano mai risolto i loro firewall .

Fino al rilascio di Windows Server 2012. Microsoft ha abilitato ECN per impostazione predefinita a partire da questa versione del sistema operativo.

Purtroppo nella memoria recente nessuno ha effettuato test significativi delle risposte dei siti Internet all'ECN, quindi è difficile valutare se i problemi riscontrati nei primi anni 2000 sono ancora esistenti, ma sospetto fortemente che lo siano e che il tuo traffico sia, almeno qualche volta, passando attraverso tale attrezzatura.

Dopo aver abilitato ECN sul mio desktop e aver quindi avviato Wireshark, sono passati solo pochi secondi prima che prendessi un esempio di host da cui ho ottenuto un RST in un pacchetto con SYN ed ECN impostati, sebbene la maggior parte degli host sembra funzionare bene. Forse andrò a scansionare Internet da solo ...

Puoi provare a disabilitare ECN sul tuo server per vedere se il problema si risolve. Questo ti renderà anche incapace di usare DCTCP, ma in un piccolo ufficio è altamente improbabile che tu lo stia facendo o che tu abbia bisogno di farlo.

netsh int tcp set global ecncapability=disabled