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

1165
Haris

Я пытаюсь проверить, как программное обеспечение будет вести себя в случае сбоя в сети. Это программное обеспечение использует 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

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

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

3
как насчет `--reject-with icmp-host-unreachable` или` --reject-with icmp-port-unreachable`? guest-vm 7 лет назад 0
@guest Опробовал каждый из этих вариантов. Такое же поведение сохраняется. Haris 7 лет назад 0
просто дикая догадка, поправьте меня, если я ошибаюсь: поскольку и клиент, и сервер имеют одинаковый IP-адрес обратной связи, любое сообщение об отказе в ответ на запрос клиента будет в равной степени заблокировано правилом iptables. Вы можете различить два с номером порта в правиле? guest-vm 7 лет назад 0
Странно, вы пытаетесь смоделировать отказ интерфейса обратной связи? Разве интерфейс петли не предназначен для того, чтобы вы все еще имели доступ к службе, работающей на локальном компьютере, когда сеть действительно выходит из строя? (вероятно, вы получите доступ к этому сервису через консоль в центре обработки данных, если сеть когда-нибудь выйдет из строя, и вы будете единственным ...) NotAdmin Dave 7 лет назад 0

1 ответ на вопрос

3
Kamil Maciorowski

Я воспроизвел ваш результат (с попыткой соединения 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, таким образом, не будет поймано правилом отклонения и не сможет пройти.

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