Почему iptables отбрасывают / журнал, даже если соответствующий пакет должен быть принят?

У Стефана правильный ответ. В основном я комментирую стиль.

Чтобы уменьшить объем работы, вам придется читать переменные, вместо

while read ONELINE; do
    # variables..
    SERVER=`echo "$ONELINE" | awk 'BEGIN {FS="\t"} {print $1}'`
    RSATYPE=`echo "$ONELINE" | awk 'BEGIN {FS="\t"} {print $2}'`
    IP=`echo "$ONELINE" | awk 'BEGIN {FS="\t"} {print $3}'`
    USER=`echo "$ONELINE" | awk 'BEGIN {FS="\t"} {print $4}'`
    PWD=`echo "$ONELINE" | awk 'BEGIN {FS="\t"} {print $5}'`
    # ...

сделайте это

while IFS=$'\t' read SERVER RSATYPE IP USER PWD; do
    # ...

Вместо записи

some command 
if [[ $? -eq 0 ]]; then
    do_this
else
    do_that
fi

напишите

if some command; then
    do_this
else
    do_that
fi

Так как это специфический бэш-скрипт, вместо

echo "${IMMSSH}" | grep -q "tty name check failed"

do

grep -q "tty name check failed" <<<"${IMMSSH}"

Также, выйдите из привычки использовать ALL_CAPS_VARNAMES: однажды вы используете PATH, а затем удивитесь, почему ваш скрипт сломался, когда вы не можете найти никаких внешних команд.

1
03.03.2015, 15:33
2 ответа

Tracker соединения не только отслеживает, если пакеты из того же соединения, но также проверяют некоторые сроки (как поздний Ack или Seq слишком поздно).

Можно переключиться на подключенное трекер входа с:

echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid

Это показало мне, что все сбрасываемые и зарегистрированные пакеты имеют тип:

nf_ct_tcp: ACK is under the lower bound (possible overly delayed ACK) ...

есть дискуссия , где я нашел эти намеки Отказ

Я в настоящее время не знаю, почему это происходит, но это может быть еще один вопрос ...

0
27.01.2020, 23:51

, потому что у вас есть эти записи IPTables , и они не соответствовали вашему , связанные со связанными, установленными правилами, трекеру подключения сообщает, что вид их как начало новых сеансов, не связанных с чем-либо ранее. Как правило, (но не всегда) Это может произойти, когда сеанс потратил дольше, чем время ожидания трекера подключения. Другие устройства NAT между вашими конечными точками могут иметь время и сгенерированные новые номера портов, или ваша другая конечная точка, возможно, имела изменение своего IP-адреса (возможно, в некоторых сетях на основе DHCP-интернет-интернет-провайдеров), поэтому он не обязательно является трекером для соединения конечного точка, который на неисправности Отказ

Существует три варианта, которые пружины для разума

  1. включают Ping keepalive в конфигурации OpenVPN. Как минимум, попробуйте PING 10 . Если вы предпочитаете, и в зависимости от того, как настроен ваш клиент / сервер, вы можете предпочесть APPALIVE 10 60 . См. Мужское страницу для по-настоящему детали горы. (Это не решает проблему, если пара IP-адреса / порта для изменения конечной точки.)

  2. Отключить конфигурацию Fail2ban , которая соответствует трафику OpenVPN на 1194 / TCP.

  3. Убедитесь, что вы избегаете печати сообщения журнала из IPTables для трафика OpenVPN на 1194 / TCP, поэтому Fail2ban не имеет ничего, на который для срабатывания.

1
27.01.2020, 23:51

Теги

Похожие вопросы