Брандмауэр, отклоняющий UDP-соединения?
У меня есть сервер, который агрегирует журналы с разных других серверов. В основном это работает отлично, однако время от времени (сразу после перезагрузки, но не все перезагрузки) он решает, что различные UDP-соединения находятся в каком-то странном состоянии, и отклоняет входящие пакеты.
Дело в том, что это не имеет смысла, потому что нет никаких "соединений" при работе с UDP!
Вот пример того, что отображается в моих журналах брандмауэра:
Shorewall:loc2fw:REJECT:IN=eth0 OUT= MAC=/*snip*/ SRC=10.x.x.4 DST=10.y.y.14 LEN=159 TOS=0x00 PREC=0x00 TTL=254 ID=37407 PROTO=UDP SPT=514 DPT=514 LEN=139
После запуска команды sudo conntrack -D -p udp чтобы очистить все UDP-соединения от conntrack, вот журнал, показывающий входящее сообщение с того же хоста:
Shorewall:loc_dnat:REDIRECT:IN=eth0 OUT= MAC=/*snip*/ SRC=10.x.x.4 DST=10.y.y.14 LEN=201 TOS=0x00 PREC=0x00 TTL=254 ID=50542 PROTO=UDP SPT=514 DPT=514 LEN=181
И вот что появляется в conntrack для этого хоста, прежде чем я запустил -D команда:
udp 17 29 src=10.x.x.4 dst=10.y.y.14 sport=514 dport=514 [UNREPLIED] src=10.y.y.14 dst=10.x.x.4 sport=514 dport=514 mark=0 use=1
Вот соответствующие биты из моей конфигурации Shorewall для этого порта:
#ACTION SOURCE DEST PROTO DPT
SECTION NEW
REDIRECT:info loc 5000 tcp,udp 514
ACCEPT:info loc $FW tcp,udp 5000
И для полноты, вот результирующая цепочка в iptables (это после conntrack -D -p udp команда была выполнена, и брандмауэр некоторое время правильно принимал пакеты):
Chain loc2fw (1 references)
pkts bytes target prot opt in out source destination
16328 1648K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
6428 386K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 /* Ping */
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* SSH */
18 1080 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 /* HTTP */
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000 ctorigdstport 514
12M 6677M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5000 ctorigdstport 514
0 0 ~log0 tcp -- * * 0.0.0.0/0 0.0.0.0/0 [goto] tcp dpt:5000
0 0 ~log0 udp -- * * 0.0.0.0/0 0.0.0.0/0 [goto] udp dpt:5000
52 3088 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9200
126M 32G Reject all -- * * 0.0.0.0/0 0.0.0.0/0
126M 32G LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix "Shorewall:loc2fw:REJECT:"
126M 32G reject all -- * * 0.0.0.0/0 0.0.0.0/0 [goto]
Как вы можете видеть, я использую правило REDIRECT, чтобы принимать соединения, поступающие на порт 514, и отправлять их вместо этого на порт 5000, где мой агрегатор журналов прослушивает (было проще выполнить это в брандмауэре, чем перепрыгивать через обручи, чтобы разрешить непривилегированный пользователь, чтобы открыть привилегированный порт).
Я не могу понять, почему UDP-соединения, кажется, попадают в это странное состояние, когда они отклоняются политикой по умолчанию; Я говорю это потому, что они довольно четко отображаются в conntrack, и удаление их оттуда, похоже, "сбрасывает" все и позволяет сообщениям снова попадать в мой агрегатор журналов. На данный момент единственной альтернативой, которую я вижу, является настройка cron для запуска моего conntrack Команда вскоре после перезагрузки, но я бы скорее понял, почему это происходит, и исправил причину, а не просто применил этот обходной путь.