Domanda

Stiamo eseguendo un Debian con un kernel 2.6.16, con iptables abilitato. Il sistema esegue un proxy HTTP personalizzato, soggetto a un carico moderato (funziona bene con lo stesso carico su altri siti). Il sistema comprende 4 server preceduti da un bilanciamento del carico con IP virtuale, preceduto da un array di 4 macchine ISA 2004, pertanto la topologia di base è:

Client - > ISA [1-4] - > Load Balancer - > Il nostro proxy [1-4] - > Internet

Occasionalmente, l'ISA ci invierà un pacchetto SYN, al quale non viene inviato alcun SYN-ACK. Tenterà di nuovo dopo 3 secondi e una terza volta dopo altri 6 secondi, dopodiché segnalerà il proxy inattivo e passerà alla connessione diretta. Durante questo periodo, ovvero prima, tra e dopo quei 3 SYN, arrivano altri SYN dello stesso ISA a cui viene data risposta con successo.

Un problema molto simile è stato segnalato da altri (senza soluzione, tuttavia):

Tutto proveniente da un sapore di Linux chiamato CentOS. La particolarità è di avere iptables abilitato di default.

http://www.linuxhelpforum.com/showthread.php?t = 931.912 & amp; mode = lineare http://www.centos.org/modules/newbb/viewtopic. php? topic_id = 16147

Quasi lo stesso: ma un po 'diverso: http: //www.linuxquestions.org/questions/linux-networking-3/tcp-handshake-fails-synack-ignored-by-system.-637171/

Sembra anche essere rilevante: http://groups.google.com/group/ comp.os.linux.networking / browse_thread / filetto / b1c000e2d65e0034

Sospetto che iptables sia un colpevole, ma qualsiasi feedback aggiuntivo sarà il benvenuto.

È stato utile?

Soluzione

Guarda il secondo parametro per la chiamata di ascolto, come menzionato nel primo link che hai pubblicato. È il numero massimo di connessioni in sospeso (non ancora accettate). Secondo la pagina di ascolto (2), se il protocollo supporta la ritrasmissione (TCP lo fa), la richiesta di connessione verrà eliminata quando la coda è piena (aspettandosi una ritrasmissione successiva che creerà la connessione se c'è ancora spazio sufficiente nella coda ).

Altri suggerimenti

In effetti, iptables si è rivelato essere il culrpit, con la regola che ha eliminato i pacchetti INVALID. Non sappiamo ancora con certezza cosa abbia reso iptables pensare che quei SYN non fossero validi (nessun TIME_WAIT di sicuro, dato che non avevamo traffico con le stesse porte di origine per almeno 30 minuti prima dei drop).

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top