У меня есть сервер, который собирает журналы с разных других серверов. В основном он работает отлично, однако время от времени (сразу после перезагрузки, но не во всех перезагрузках) он решает, что различные «соединения» 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 команда вскоре после перезагрузки, но я бы лучше понял Зачем это происходит, и устраните причину, а не просто реализуйте этот обходной путь.