iptables отклоняет tcp-reset при обратной связи

Question

Я пытаюсь проверить, как программное обеспечение будет вести себя в случае сбоя в сети. Это программное обеспечение использует tcp send() и recv() для связи.

Ранее я заставлял программное обеспечение взаимодействовать, помещая их в две разные машины в локальной сети. Итак, для симуляции сбоя сети я использовал приведенное ниже правило.

sudo iptables -A INPUT -p tcp -s 10.100.52.234 -j REJECT --reject-with tcp-reset

Предположим, что 10.100.52.234 - это IP одной из систем. Это привело к провалу в одно мгновение. Все хорошо.

---

Теперь я пытаюсь смоделировать это на одной машине, используя адрес обратной связи 127.0.0.1 . Все работает так же, как и в предыдущей настройке, но вышеприведенная команда не работает. Это не сбой сетевого подключения, и программное обеспечение просто зависает. Не происходит никакого общения, но оно также не подведет.

Я использовал команду

sudo iptables -A INPUT -p tcp -s 127.0.0.1 -j REJECT --reject-with tcp-reset

а также

sudo iptables -A INPUT -p tcp -i lo -j REJECT --reject-with tcp-reset

оба не работают. Программное обеспечение очень долго терпит неудачу.

Есть ли другой способ немедленно разорвать соединение по адресу обратной связи?

Answer 1

Я воспроизвел ваш результат (при попытке подключения SSH к 127.0.0.1 пока мой sshd слушал). Это правда, что программное обеспечение просто зависает.

Я думаю, что программное обеспечение ожидает ответа или сообщения об ошибке, но сообщение об ошибке попадает в то же правило и отклоняется. Я не знаю, есть ли какая-то цепная реакция сообщений об ошибках или нет - я не исследовал это далеко. Во-первых, я могу ошибаться, поэтому, если у кого-то есть объяснение получше, я буду рад его прочитать.

---

Вот решение, которое работает в моем Debian:

Вы должны подключиться к 127.0.0.2 (объяснение здесь) и сделать ваше правило следующим образом:

sudo iptables -I INPUT 1 -p tcp -d 127.0.0.2 -j REJECT --reject-with tcp-reset

Обратите внимание на фрагмент -I INPUT 1 который гарантирует, что правило будет вставлено в первую позицию, чтобы иметь приоритет над любым правилом ACCEPT вас уже может быть в вашем интерфейсе обратной связи (как я сделал в моем Debian).

Я повторил тест (с попыткой соединения SSH, на этот раз до 127.0.0.2). Сбой сразу

Connection refused

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