Рвётся сессия на FreeBSD 7.2

[skeletor]

Есть шлюз на FreeBSD (ipfw+ipnat, поддержка всего в ядре). Если сессия (например, ssh. Пробую через putty) неактивна минут 15 она рвётся. Хотя в sysctl стоит значение устаревание tcp-сессии в 7 дней. Как можно вылечить это? Подозреваю, что это связано именно с ipnat. Поскольку, если с самого шлюза открыть сессию и при большом простое, то она не рвётся. Рвётся только сессия, которая натится через шлюз.
Добавлю ещё, что я включил поддержку LARGE_NAT в ipnat и немного изменил некоторые дефолтные значения (первая строка, это то, что по дефолту предлагается с LARGE_NAT, вторая - на которую изменил):

Код: Выделить всё

// #  define    NAT_SIZE        2047
#  define    NAT_SIZE        4093
// #  define    RDR_SIZE        2047
#  define    RDR_SIZE        4093
// #  define    HOSTMAP_SIZE    8191
#  define    HOSTMAP_SIZE    16383
// #  define    NAT_TABLE_MAX   180000
#  define    NAT_TABLE_MAX   300000
// #  define    NAT_TABLE_SZ    16383
#  define       NAT_TABLE_SZ    32765

Привожу параметры sysctl касающиеся ipnat'a и переменные ipnat'a:

Код: Выделить всё

[root@server /var]# sysctl -a net.inet.ipf
net.inet.ipf.fr_minttl: 4
net.inet.ipf.fr_chksrc: 0
net.inet.ipf.fr_defaultauthage: 600
net.inet.ipf.fr_authused: 0
net.inet.ipf.fr_authsize: 32
net.inet.ipf.ipf_hostmap_sz: 16383
net.inet.ipf.ipf_rdrrules_sz: 4093
net.inet.ipf.ipf_natrules_sz: 4093
net.inet.ipf.ipf_nattable_sz: 32765
net.inet.ipf.fr_statemax: 4013
net.inet.ipf.fr_statesize: 5737
net.inet.ipf.fr_running: 1
net.inet.ipf.fr_ipfrttl: 120
net.inet.ipf.fr_defnatage: 1200
net.inet.ipf.fr_icmptimeout: 120
net.inet.ipf.fr_udpacktimeout: 24
net.inet.ipf.fr_udptimeout: 240
net.inet.ipf.fr_tcpclosed: 60
net.inet.ipf.fr_tcptimeout: 480
net.inet.ipf.fr_tcplastack: 60
net.inet.ipf.fr_tcpclosewait: 480
net.inet.ipf.fr_tcphalfclosed: 14400
net.inet.ipf.fr_tcpidletimeout: 864000
net.inet.ipf.fr_active: 0
net.inet.ipf.fr_pass: 134217730
net.inet.ipf.fr_flags: 0
[root@server /var]#

[root@server /var]# ipf -T list
fr_flags        min 0   max 0xffffffff  current 0
fr_active       min 0   max 0   current 0
fr_control_forwarding   min 0   max 0x1 current 0
fr_update_ipid  min 0   max 0x1 current 0
fr_chksrc       min 0   max 0x1 current 0
fr_minttl       min 0   max 0x1 current 4
fr_icmpminfragmtu       min 0   max 0x1 current 68
fr_pass min 0   max 0xffffffff  current 134217730
fr_tcpidletimeout       min 0x1 max 0x7fffffff  current 864000
fr_tcpclosewait min 0x1 max 0x7fffffff  current 480
fr_tcplastack   min 0x1 max 0x7fffffff  current 60
fr_tcptimeout   min 0x1 max 0x7fffffff  current 480
fr_tcpclosed    min 0x1 max 0x7fffffff  current 60
fr_tcphalfclosed        min 0x1 max 0x7fffffff  current 14400
fr_udptimeout   min 0x1 max 0x7fffffff  current 240
fr_udpacktimeout        min 0x1 max 0x7fffffff  current 24
fr_icmptimeout  min 0x1 max 0x7fffffff  current 120
fr_icmpacktimeout       min 0x1 max 0x7fffffff  current 12
fr_iptimeout    min 0x1 max 0x7fffffff  current 120
fr_statemax     min 0x1 max 0x7fffffff  current 4013
fr_statesize    min 0x1 max 0x7fffffff  current 5737
fr_state_lock   min 0   max 0x1 current 0
fr_state_maxbucket      min 0x1 max 0x7fffffff  current 26
fr_state_maxbucket_reset        min 0   max 0x1 current 1
ipstate_logging min 0   max 0x1 current 1
fr_nat_lock     min 0   max 0x1 current 0
ipf_nattable_sz min 0x1 max 0x7fffffff  current 32765
ipf_nattable_max        min 0x1 max 0x7fffffff  current 300000
ipf_natrules_sz min 0x1 max 0x7fffffff  current 4093
ipf_rdrrules_sz min 0x1 max 0x7fffffff  current 4093
ipf_hostmap_sz  min 0x1 max 0x7fffffff  current 16383
fr_nat_maxbucket        min 0x1 max 0x7fffffff  current 30
fr_nat_maxbucket_reset  min 0   max 0x1 current 1
nat_logging     min 0   max 0x1 current 1
fr_defnatage    min 0x1 max 0x7fffffff  current 1200
fr_defnatipage  min 0x1 max 0x7fffffff  current 120
fr_defnaticmpage        min 0x1 max 0x7fffffff  current 6
fr_nat_doflush  min 0   max 0x1 current 0
ipf_proxy_debug min 0   max 0xa current 0
ipfr_size       min 0x1 max 0x7fffffff  current 257
fr_ipfrttl      min 0x1 max 0x7fffffff  current 120
ipl_suppress    min 0   max 0x1 current 1
ipl_logmax      min 0   max 0x7fffffff  current 7
ipl_logall      min 0   max 0x1 current 0
ipl_logsize     min 0   max 0x80000     current 8192
ippr_ftp_debug  min 0   max 0xa current 0
[root@server /var]#

Как заставить держать сессию согласно net.inet.ipf.fr_tcpidletimeout, то есть 7 дней? Такое впечатление, что оно игнорит этот параметр

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[manefesto]

а вы уверены что это ограничение сессий, а не sshd ?

[skeletor]

Да, на одном форуме подсказали, что это проблема именно LARGE_NAT (не я один такой). Сейчас делаю кое-какое тестирование. После завершения - отпишусь. Если интересно, то вот ссылки, где эта проблема обсуждается: http://osdir.com/ml/security.firewalls. ... 00023.html, http://marc.info/?l=ipfilter&m=104489840310127&w=2

[skeletor]

И так, отписываюсь после тестов. Внимательно изучив ссылки (которые привёл в посте выше), пришёл к выводу: либо не юзать LARGE_NAT(ибо как писал чел из рассылки ipnat "эта константа используется для тысяч подсетей", а у меня не больше 30-ти) либо пропатчить ip_nat.c. Я выбрал первый вариант, поскольку в исходниках с 2003-го года поменялся код, точнее переменные, которые используются. Я не супер ас в С, и попытка отследить какие переменные на какие заменены - успехом не увенчалась. Поэтому, я закоментил LARGE_NAT и просто увеличил значение констант на те, которые мне нужно (NAT_SIZE, RDR_SIZE, HOSTMAP_SIZE, NAT_TABLE_MAX, NAT_TABLE_SZ). Так сделал один чел из рассылки про ipnat.
Пока полёт нормальный, соединения не рвутся (проверял для idle=15 min). Если что-то буду ненормальное наблюдать в работе - буду отписываться.