Правила цепочки OUTPUT в iptables
netfilter , похоже, позволяет отклоненному трафику из моей цепочки INPUT проходить через мою цепочку OUTPUT . Вот правила из цепочки INPUT , которые применяются к рассматриваемым пакетам:
LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix "ICATCH:"
REJECT-PKT all -- * * 0.0.0.0/0 0.0.0.0/0
Пользовательская цепочка REJECT-PKT и ее соответствующее правило:
REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp reject-with tcp-reset
Вот зарегистрированный результат:
May 15 06:41:51 li51-144 kernel: ICATCH:IN=eth0 OUT= MAC=f2:3c:91:1f:61:44:84:78:ac:0d:97:c1:08:00 SRC=188.138.135.9 DST=<my IP> LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=46841 PROTO=TCP SPT=8838 DPT=23 WINDOW=22014 RES=0x00 SYN URGP=0
May 15 06:41:51 li51-144 kernel: OCATCH:IN= OUT=eth0 SRC=<my IP> DST=188.138.135.9 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=23 DPT=8838 WINDOW=0 RES=0x00 ACK RST URGP=0
Вторая строка создается следующим (предпоследним) правилом в таблице OUTPUT :
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix "OCATCH:"
У меня сложилось впечатление, что отклоненные пакеты каким-то образом были помеченный ядром, и этот TCP-трафик с флагом RST , возникший в результате правил iptables , не был обработан межсетевым экраном.
Что я неправильно понял?
Как сказал @Aaron, это нормально.
Когда входящий пакет достигает правила REJECT, он будет обработан netfilter и ответит отправителю пакетом RST и сообщением.
Однако, если вместо этого установить значение DROP, источник не получит сообщения.
Проверьте эту ссылку: Разница между DROP и REJECT
Стоит запустить tcpdump или wireshark, чтобы захватить выходные данные и посмотреть, что происходит в концентраторе.