Изпечатай

[danielR]

Привет,
 имам следното питане - правя тук един router/firewall, трябва ли да му увеличава бройката на файловите дескриптори или този тип мрежови конекции (NAT) не заемат дескриптори ?

[bop_bop_mara]

Файлово дескриптори не заемат ли сокетите? 

[Acho]

Да не питаш за connlimit нещо ? Бройката на конекциите през интерфейсите на рутера.

[danielR]

всяка мрежова конекция от и към сървъра е ИП:ПОРТ - което е сокет.
Всеки сокет заема 1 FD, но когато връзката не достига до юзър спейса, а се препраща от кърнъла (iptables) - в случайя като NAТ - има ли значение FD или не ? и ако нямат значение - то какво е, къде се вижда ограничението за такива конекции ?

[dev_urandom]

root@thor:~# cat /proc/sys/fs/file-max
24834
root@thor:~# echo "65535" > /proc/sys/fs/file-max
root@thor:~# cat /proc/sys/fs/file-max
65535

[gat3way]

Няма значение, файловите дескриптори нямат нищо общо с connection tracking-а. Но ограничение има. Има procfs интерфейс за вдигане на лимита на бройката елементи в таблицата, не помня как се казваше точно файла там. По спомени максималния брой на entry-тата в conntrack таблицата не е някаква hardcode-ната стойност, а се смяташе на база обема физическа памет. Та там е проблема и с разни домашни рутери с линукски фърмуер.

[victim70]

Ако е до 200 потребителя с NAT-a + още 30-40 правила в таблиците без шейп на връзките не пипай нищо. Става въпрос за нормален компютър превърнат в рутер. Ако имаш сериозна шейп политика с бърстове и индивидуална настройка за всеки потребител и т.н.т ще се наложи да увеличиш споделената памет защото иначе тези с голямата лента ще се чувстват ощетени.
Според мене не се занимавай с пипане на параметри направи го пусни го и виж в движение какво става, ако има проблем ще изплаче или няма да достига забележимо скорост, тогава може да се даде конкретен съвет според случая.
@ gat3way
Броят елементи при мене е 256 по подразбиране, не знам какво става ако ги надвиша, не съм имал такъв случай, максималната таблица ми е от 70-80 правила, която съм правил.

[gat3way]

Ъх, това не е ли много малко. Стана ми малко интересно и проверих какво има (/proc/sys/net/netfilter/nf_conntrack_max се оказа). При мен е 65535. Но 256 ми се вижда наистина малко. Като гледам:

cat /proc/sys/net/netfilter/nf_conntrack_count
492

И нямам торънт клиент пуснат примерно. Имам уеб сървър за който DNAT-вам трафика към виртуална машина, но определено не е особено посещаван. Ммм проблемът е по-скоро че редовете в conntrack таблицата стоят прекалено дълго време в нея. То и това май можеше да се контролира през procfs, не знам.

[victim70]

Предполагам че danielR ще го ползва за домашна мрежа или малък офис, за което ако не пипа нищо по кернела и настройките ще си работи без проблеми.

@gat3way
това е без нет, без връзки, изгасени интерфейси при зареждането още, без нищо. Подобное на твойто е. В Линукса май и до тоалетна да идеш ти отваря сокети
dzver ~ # cat /proc/sys/net/netfilter/nf_conntrack_count
417
dzver ~ # cat /proc/sys/net/netfilter/nf_conntrack_expect_max
256
dzver ~ # cat /proc/sys/net/netfilter/nf_conntrack_max
65536

[danielR]

Супер,  благодаря за поясненията. казвате, че ip_conntrack_max е единственото ограничение ?
май вярно мрежовите конекции нямат общо с ФД. с lsof не се виждат нат'натите връзки.

[bop_bop_mara]

с lsof не се виждат нат'натите връзки.

За да затвърдим изводите ти, нека все пак да кажем, че NAT и отварянето на файл (бил той обикновен, сокет и т.н.) нямат връзка.

[danielR]

Супер, благодаря, обичам ясните обобщения.
Единственото неприятно, което виждам е, че контрака пази ненужни TIME_WAIT връзки, които не присъстват в netstat. Не зная това на какво се дължи, имате ли идея ?
ето
cat /proc/net/ip_conntrack | grep TIME_WAIT | wc -l
7057

netstat -anp | grep TIME_WAIT | wc -l
2483

[10101]

echo "число" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
така може да намалиш или увеличиш time out-a.