Оказалось, что проблема связана с моей конфигурацией. Я запускаю Suricata в режиме inline IPS с использованием nfqueue и использую его режим 'repeat' для повторной вставки пакетов в начало цепочки, если они получили разрешение от IPS. Затем у меня были правила, которые искали метку Suricata, добавленную к пакету, и не пересылали его Suricata. Однако повторное включение в цепочку из Suricata, казалось, заставляло ядро забыть о том, как направить пакет. Простое удаление правила nfqueue устранило проблему, но не задействовало IPS. В итоге я заменил все правила iptables -j ACCEPT на правила iptables -j NFQUEUE. В таком виде Suricata не видит ВСЕГО трафика, в частности, она не видит пакеты, которые блокируются брандмауэром. Это досадно, но это работает.
Операторы [[
и ]]
предназначены для явных сравнительных тестов. Если вы хотите проверить два результата команды , просто используйте оболочку:
$ if /usr/bin/pgrep -fq "/home/tiger/bin/pymp" || /usr/bin/pgrep -fq "/usr/bin/mpv2" ; then do_stuff; fi
Не все версии pgrep
поддерживают аргумент -q
для подавления вывода. Если это ваш случай, вы можете подавить каждое pgrep
по отдельности или комбинировать перенаправление:
$ if { /usr/bin/pgrep -f "/home/tiger/bin/pymp" || /usr/bin/pgrep -f "/usr/bin/mpv2";} > /dev/null 2>&1 then do_stuff; fi
или
$ if /usr/bin/pgrep -f "/home/tiger/bin/pymp" > /dev/null 2>&1 || /usr/bin/pgrep -f "/usr/bin/mpv2" > /dev/null 2>&1 ; then do_stuff; fi