Зависает контрэк
/positive
А может отказаться от FTP в пользу чего-то менее глючного (современного/безопасного/т.д.)?
А собственно на что? Есть мысль перепилить это всё на торрентах. я даже тему создавал, где справшивал бибилиотеку для торрентов, чтоб крутить террабайтами данных. Но это всё не быстро. А проблема есть сейчас. Всреднем из 100 серверов где-то в неделю на одном фтп перестаёт нормально работать до рестарта iptables
positiveДа я вроде всё написал. На постоянно работающем фтп сервере (proftpd, если чё) переодически перестаёт нормально работать conntrack - не открывает порты для пассивного режима фтп.
не открывает портыэта фраза не имеет смысла без контекста
как и зачем он должен открывать? кто их закрыл вообще?
Да. наверно не внятно выразился.
Есть приблизительно такой набор правил:
# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp — 0.0.0.0/0 0.0.0.0/0 icmp type 255 /* 0000: ICMP Ping */
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 /* 0000: Loopback Interface */
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED /* 0001: Established connections */
ACCEPT-TRUSTED all — 0.0.0.0/0 0.0.0.0/0 /* 0002 Allow all from trusted hosts */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* 0100: SSH Access */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:10050 /* 0102: Zabbix Agent */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 /* 0103: FTP Access */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:9100 /* 3000 */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:50000 /* 3000 */
DROP udp — 0.0.0.0/0 224.0.0.0/4 udp /* 99990: Drop multicast */
DROP tcp — 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x11 /* 99990: Hard hack to drop closed sessions packets */
LOG all — 0.0.0.0/0 0.0.0.0/0 /* 99991: Log before drop */ LOG flags 0 level 4 prefix `IPTABLES: : '
DROP all — 0.0.0.0/0 0.0.0.0/0 /* 99992: Drop */
В конфиге фтп-сервера указан диапазон портов для пасивного режима:
# cat /etc/proftpd.conf | grep Port
PassivePorts 60000 65000
Эти порты штатно закрыты фаерволом. Соответственно, когда фтп-клиент хочет переключиться в пассивный режим, контрэк открывает соответствующий порт на фаерволе. так понятнее?
Так вот иногда он это перестаёт делать.
Есть приблизительно такой набор правил:
# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp — 0.0.0.0/0 0.0.0.0/0 icmp type 255 /* 0000: ICMP Ping */
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 /* 0000: Loopback Interface */
ACCEPT all — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED /* 0001: Established connections */
ACCEPT-TRUSTED all — 0.0.0.0/0 0.0.0.0/0 /* 0002 Allow all from trusted hosts */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* 0100: SSH Access */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:10050 /* 0102: Zabbix Agent */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 /* 0103: FTP Access */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:9100 /* 3000 */
ACCEPT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:50000 /* 3000 */
DROP udp — 0.0.0.0/0 224.0.0.0/4 udp /* 99990: Drop multicast */
DROP tcp — 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x11 /* 99990: Hard hack to drop closed sessions packets */
LOG all — 0.0.0.0/0 0.0.0.0/0 /* 99991: Log before drop */ LOG flags 0 level 4 prefix `IPTABLES: : '
DROP all — 0.0.0.0/0 0.0.0.0/0 /* 99992: Drop */
В конфиге фтп-сервера указан диапазон портов для пасивного режима:
# cat /etc/proftpd.conf | grep Port
PassivePorts 60000 65000
Эти порты штатно закрыты фаерволом. Соответственно, когда фтп-клиент хочет переключиться в пассивный режим, контрэк открывает соответствующий порт на фаерволе. так понятнее?
Так вот иногда он это перестаёт делать.
в dmesg есть чё?
Поймать момент в который перестало отвечать и изучить логи за этот период достаточно геморно. Когда уже зависло и пытаешься переключиться в пассивный режим - ничего не пишет.
у тебя в правилах стоит LOG - должно вроде писать, или дропается где-то раньше
Поймать момент в который перестало отвечать и изучить логи за этот период достаточно геморно.там ядро постоянно что-то спамит? это не очень правильно, надо лишнюю отладку отключить тогда
у тебя в правилах стоит LOG - должно вроде писать, или дропается где-то раньшену в лог оно пишет конечно. iptables просто пишется в отдельный лог. кстати наверно по нему имеет смысл попытаться отследить когда точyо всё упало
Mar 11 09:14:36 hostname kernel: IPTABLES: : IN=vlan483 OUT= MAC=00:25:90:65:bc:b0:64:ae:0c:40:25:c0:08:00 SRC=192.168.184.20 DST=192.168.198.11 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=39477 DF PROTO=TCP SPT=43691 DPT=64923 WINDOW=14600 RES=0x00 SYN URGP=0
Но что-то мне подсказывает, что ничего я не найду интересного.
Требования не совсем ясны.
Например могут подойти NFS, sftp.
Или просто ftp только в active режиме.
Например могут подойти NFS, sftp.
Или просто ftp только в active режиме.
sftp - на 2 гигабитах упрётся в проц, если не раньше.
nfs - наверное можно подумать. чё-то я как-то про него забыл.
ftp в активном режиме не катит - нат.
nfs - наверное можно подумать. чё-то я как-то про него забыл.
ftp в активном режиме не катит - нат.
sftp - на 2 гигабитах упрётся в проц, если не раньше.
Там вроде можно крутить алгоритм шифрования и степень сжатия. А по дефолту да - упирается в проц быстро: две машинки i7 3.6GHz с гигабитом, NFS выдаёт до 117-119Mbytes/s, а sftp даже 70Mbyte/s не выдерживает.
ftp в активном режиме не катит - нат.Как раз наоборот для пассива нужны отдельные танцы с бубном, а для active просто открытые (+проброшенные где надо) 20ый и 21ый порты.
И как в активе сервер достучится до клиента, если клиент за натом? Пробросить порт на нате? а если за натом несколько клиентов?
и что ты нагуглил?
ip_conntrack_ftp или как он нынче называется загружен в момент фейла?
ну можно просто разрешить эти порты явно и всё
ip_conntrack_ftp или как он нынче называется загружен в момент фейла?
ну можно просто разрешить эти порты явно и всё
пока не копал логи.
меня чё-то в последнее время начало волновать "правильность" решения, а не только "чтоб работало". вот волнует на сколько открыть порты менее "правильно", чем ковырять контрэк.
меня чё-то в последнее время начало волновать "правильность" решения, а не только "чтоб работало". вот волнует на сколько открыть порты менее "правильно", чем ковырять контрэк.
имхо правильно было бы проверить, что там слушает именно твой proftpd (не в курсе, работает ли это уже в iptables)
Да. не причём здесь фтп клиент?
есть установленная сессия.
попытка сделать например листининг в пассивном режиме обрывается по таймауту
заходим паралельно на фтп-сервер и делаем /etc/init.d/iptables restart
и в той же фтп сессии всё начинает работать, а iptables перестаёт срать в лог, что он зафильтровал входящий пакет.
есть установленная сессия.
попытка сделать например листининг в пассивном режиме обрывается по таймауту
заходим паралельно на фтп-сервер и делаем /etc/init.d/iptables restart
и в той же фтп сессии всё начинает работать, а iptables перестаёт срать в лог, что он зафильтровал входящий пакет.
Я наверно ткну пальцем в небо но у iptables есть ограничения на размер таблиц. Возможно, твоя таблица соединений переполняется, и все что дальше отбрасывается. Может под таблицу места надо больше в ядре выделять, может таймаут уменьшить
Она вообще типа чиститься должна, но попробовать можно.
. Возможно, твоя таблица соединений переполняется, и все что дальше отбрасывается.Тогда должны быть сообщения ядра, множество их.
какой ещё клиент, ты это мне отвечаешь?
И как в активе сервер достучится до клиента, если клиент за натом? Пробросить порт на нате? а если за натом несколько клиентов?Прекрасно работало много лет - клиент выставляет active и работает через nat с сервером.
Открыты 20ый и 21ый порты TCP.
И как это работает? Нат слушает траффик на 21-ый порт и пробрасывает соответствующий порт, когда видит переход в активный режим? А если нат управляется не тобой и он этого не делает? К тому же если нат на линухе, то этим тоже занимается контрэк.
Ничего нат не слушает в этом направлении.
Нат на роутере: FreeBSD+ipfw+natd.
Наружу порты 20, 21 просто открыты. Ещё открыто какое-то очень ограниченное количество других портов - остальное закрыто. Внутренний клиент в ftp выставляет режим active и подключается к внешнему серверу - всё работает. Изредка встречались сервера, которые в принципе не работали с active, а только с passive - в этом случае никакие танцы с бубном не помогали, кроме открытия всех портов и входа по ftp в passive.
Нат на роутере: FreeBSD+ipfw+natd.
Наружу порты 20, 21 просто открыты. Ещё открыто какое-то очень ограниченное количество других портов - остальное закрыто. Внутренний клиент в ftp выставляет режим active и подключается к внешнему серверу - всё работает. Изредка встречались сервера, которые в принципе не работали с active, а только с passive - в этом случае никакие танцы с бубном не помогали, кроме открытия всех портов и входа по ftp в passive.
Оставить комментарий
YUAL
Господа, у меня такая прроблема: есть сто ftp серверов на центоси 6.3. Точнее ftp это не их основное предназначение, но фтп там есть и через него ежедневно проходят многие гигабайты файлов.Так вот на серверах иногда раком встаёт conntrack в netfilter и перестаёт открывать порты для пасивного режима фтп. Собственно у меня вопрос: таки забить и просто открыть диапазон портов для фтп или искать в чём проблема с контрэком? Беглый гуглинг показал, что вообще.это переодически бывает, но чёткого лекарства нет.