[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [NETVAERK] NAT timeout (ip_conntrack)



Niels Chr. Sørensen wrote:
Hejsa,

Vi sidder og fedter rundt med nogle Linux NAT boxe (Debian 2.4.18) med MANGE og ret heftige brugere bag.

Netadgangen stagnerer i perioder - vi har lokaliseret en del af problemerne til mange-mange-mange entries pr. bruger i /proc/net/ip_conntrack (op til 7-8.000 for enkelte brugere). Der er typisk tale om fil-delere med små ækle programmer der i vildskab allokerer NAT entries.

Bortset fra det umiddelbare problem, hvad gør i så for at begrænse disse irriterende 'små-programmer'?
Har i filtrering både ind- og udad-gående?
Hvis ikke, ved jeg godt det vil pisse brugerne af at gøre det :P, og det er kanonsvært at arbejde mod filesharing programmer.
Hvordan tillader i ftp?
Hvis i ikke har tilstrækkelig udadgående filtrering, kan især filesharing nemt finde vej, og returvejen kan være gennem active ftp, fordi servicen på inettet så har lov til at lave en connection ind til filesharing programmet, der altså agerer ftpserver.
På den anden side er det ganske svært at forhindre filesharing udadgående, fordi disse ofte bruger http.
Det kan være nødvendigt at ty til at filtrere på indhold af pakker; kan ikke lige huske med hvilke moduler. Og det giver så en del overhead...



Det første der slår os er at ESTABLISHED har en timeout på 5 DAGE
(/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c):

static unsigned long tcp_timeouts[]
= { 30 MINS,    /*      TCP_CONNTRACK_NONE,     */
   5 DAYS,     /*      TCP_CONNTRACK_ESTABLISHED,      */
   2 MINS,     /*      TCP_CONNTRACK_SYN_SENT, */
   60 SECS,    /*      TCP_CONNTRACK_SYN_RECV, */
   2 MINS,     /*      TCP_CONNTRACK_FIN_WAIT, */
   2 MINS,     /*      TCP_CONNTRACK_TIME_WAIT,        */
   10 SECS,    /*      TCP_CONNTRACK_CLOSE,    */
   60 SECS,    /*      TCP_CONNTRACK_CLOSE_WAIT,       */
   30 SECS,    /*      TCP_CONNTRACK_LAST_ACK, */
   2 MINS,     /*      TCP_CONNTRACK_LISTEN,   */
};

Er der nogen speciel grund til dette? Det virker vildt overdrevet!

pe iptables.org ligger en patch "iplimit" der skulle kunne hjælpe med disse obskuriteter - er der nogen der har erfaring med denne?

Næe. Jeg sætter en del netværksting i /proc, men kender ikke denne; ikke så sært, den er SVJKS ikke tilgængelig i /proc .


5 dage lyder godt nok af /ret/ meget.
Hvorfor ikke bare lave en kopi af ip_conntrack_proto_tcp.c, ændre værdien, og compile kernen/iptables?
Jeg kan ikke se at fx '1 DAYS' skulle være et problem.


Hmm:

bash-2.05b# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
432000


Det er 12 timer; den kan vel også snildt sættes ned...

bash-2.05b# echo "21600" >/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

Det er 6 timer, og stadset virker stadig :-

Jeg skal arbejde videre med 2.6.11.2 imorgen (ahemm, idag), så kan jeg teste lidt. Desværre har jeg ikke pt. adgang til en situation som jeres.

I har sat /proc/sys/net/ipv4/tcp_syncookies til '1', ikk'?


Anyway, fra netfilter listen nov. 2003:


--------------------
>>>Is there any plan to be able to set thoses values throught /proc ?
>>>> > >
>>>> > > in some cases a 5 days timeout on tcp connexions may be too long...
>>
>>> >
>>> > These are the standard values according to the TCP RFCs.
>
>>
>> Which RFC talks about TCP_CONNTRACK_ESTABLISHED, again? I don't think
>> it's written yet



Agreed The above table is obviously an extended version of the timeouts used in a normal TCP/IP stack, with the addition of things only needed for a connection tracking system.


The timeouts are based, I believe, on RFC 793 (esp. the wonderful diagram on page 23).
--------------------


Jeg har ikke været igennem RFC 793 endnu...

--
Kind regards,
Mogens Valentin
Networking, Security
www.danbbs.dk/~monz
Phone +45 32 525 878


The Pessimist says " It doesn't get any worse than this." The Optimist says " Oh yes, it does.."




 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 22:42 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *