|
|
|
![]() |
|
Strumenti |
![]() |
#1 |
Junior Member
Iscritto dal: Feb 2004
Messaggi: 9
|
Timeout su tcp
Ho un problema sul firewall aziendale che mi tedia da qualche giorno:
Amministro una tipica rete aziendale con composta da una LAN (192.168.x.y), una DMZ (con ip pubblici) e un router che instrada la connessione con internet. Al centro di tutto c'è una linuxbox rh9 con 3 eth (0 x router, 1 x LAN, 2 x DMZ). Durante la normale giornata lavorativa capita che una macchina della LAN venga letteralmente bannata dal firewall per circa 5 minuti, che impedisce l'instadamento dei pacchetti TCP alla DMZ e a Internet. La stranezza è che UDP e ICMP invece passano senza problemi. Ho l'impressione che il problema sia legato al numero di richieste/secondo che arrivano dalla LAN alla eth1. Ho controllato infatti il modulo ip_conntrack e stranamente durante il periodo di BAN la macchina della LAN non riceve risposte ai pacchetti SYN, mandando tutti i servizi TCP in timeout. Facendo un cat /proc/net/ip_conntrack non riesco a vedere nessuna connessione della macchina bannata, usando tcpdump sulla interfaccia/gateway della LAN vedo le richieste del client in ingresso, ma non vedo i pacchetti uscire da nessun'altra interfaccia. Durante il periodo di BAN, se faccio un flush delle regole (riavviando lo script iptables) il problema persiste. Ho inoltre provato ad aumentare il numero di connessioni massime di ip_conntrack, ma senza esito. Ho provato a disabilitare tcp_syncookies > 0, ma nada anche lì. Idem anche per ECN (Explicit Congestion Notification), senza risultati. Sospetto che il problema a questo punto stia nel numero massimo di connessioni che può gestire la scheda di rete collegata alla LAN. Consigli e test sono ben accetti! Vi ringrazio in anticipo per l'aiuto. |
![]() |
![]() |
![]() |
#2 |
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Problemi simili li ho osservati con cavi di rete difettosi. I pacchetti udp e icmp sono meno soggetti al problema, in quanto hanno un protocollo molto più semplice di comunicazione.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
![]() |
![]() |
![]() |
#3 |
Junior Member
Iscritto dal: Feb 2004
Messaggi: 9
|
Ho già fatto il test cambiando il cavo, ma non è quello il prob.
Come si spiega il "BAN" per 5 minuti? Il BAN riesco a simularlo puntando su un sito e metterndo il refresh della pagina a 3 sec... Sembra che il numero di connessioni attive cresca fino a raggiungere la soglia massima, poi l'ip che letteralmente "fa traboccare il vaso" viene bloccato. Sai se in /proc posso manipolare il nr max di connessioni della eth1? O magari devo caricare il modulo della scheda con un'opzione particolare... Fatto sta che il problema è nato da quando è aumentato il traffico di rete. |
![]() |
![]() |
![]() |
#4 |
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Il numero massimo di connessioni tracciabili è in /proc/sys/net/ipv4/ip_conntrack_max, ma di default dovrebbe avere un valore alto.
Ci sono anche diversi parametri per il tuning tcp, ma non so bene se ti possono aiutare. In particolare, prova a ridurre tcp_keepalive_intvl.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
![]() |
![]() |
![]() |
#5 |
Junior Member
Iscritto dal: Feb 2004
Messaggi: 9
|
Sto facendo la prova proprio ora.
Sai dove posso guardare per ottenere il nr di connessioni in conntrack attualmente attive? |
![]() |
![]() |
![]() |
#6 |
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
/proc/net/ip_conntrack
Nota che vengono tracciate anche le connessioni locali.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
![]() |
![]() |
![]() |
#7 |
Junior Member
Iscritto dal: Feb 2004
Messaggi: 9
|
Dopo altri test ecco la situazione attuale:
sembra che la causa di tutto sia un applicativo web (residente in dmz) che letteralmente flooddi di pacchetti syn il firewall sulla chain FORWARD. Devo riuscire ad aumentare la tolleranza del firewall. Ho provato con i tweak nel kernel, ma non ho ottenuto quasi nessun risultato. Guardando /proc/net/ip_conntrack ho notato che prima di bannare l'ip che floodda, si riempie di circa 1800 entry di connessioni di tipo SYN_SENT e [UNREPLIED]. Il problema è che non riesco a diminuire il tempo di ban, che dura circa 15 minuti (cronometrato), e neanche alzare la soglia. echo "220000" > /proc/sys/net/ipv4/ip_conntrack_max echo "4096" > /proc/sys/net/ipv4/tcp_max_syn_backlog Non danno molti cambiamenti (il firewall non ha limiti hardware xchè è un dual PIII xeon con 1,5gb ram e schede da 1 GB) PS: ho trovato in giro alcuni docs che parlano di un possibile baco del kernel 2.4.20 con netfilter, ma ho su la versione ufficiale patchata da RH. ::::::AGGIORNAMENTO::::::: ho risolto il problema dei SYN_SENT, ma ora sono pieno di TIME_WAIT, che per fortuna sono 1/10... Il problema però persiste... ![]() Qualcuno mi dica qualcosa pls! Ultima modifica di ry0 : 24-02-2004 alle 16:58. |
![]() |
![]() |
![]() |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 07:45.