iptables rejeitar tcp-reset no loopback

Question

Estou tentando verificar como um software se comportaria se houvesse uma falha na rede. Esse software está usando tcp send() e recv() para se comunicar.

Anteriormente, eu estava fazendo o software se comunicar, colocando-os em duas máquinas diferentes em uma rede lan. Então, para simular uma falha de rede eu estava usando a regra abaixo.

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

Suponhamos que 10.100.52.234 seja o IP de um dos sistemas. Isso estava levando a uma falha em um instante. Tudo bem e bem.

Agora, estou tentando simular isso em uma máquina usando o endereço de loopback 127.0.0.1 . Tudo está funcionando da mesma forma que a configuração anterior, mas o comando acima não está funcionando. Não está falhando a conexão de rede e o software simplesmente trava. Não há comunicação acontecendo, mas também não falha.

Eu usei o comando

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

e

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

ambos não estão funcionando. O software leva muito tempo para falhar.

Existe uma maneira diferente de falhar a conexão para o endereço de loopback imediatamente?

    

Answer 1

Eu reproduzi seu resultado (com a tentativa de conexão SSH para 127.0.0.1 enquanto meu sshd estava ouvindo). É verdade que o software apenas trava.

Acho que o software aguarda uma resposta ou uma mensagem de erro, mas a mensagem de erro se enquadra na mesma regra e é rejeitada. Eu não sei se há alguma reação em cadeia de mensagens de erro ou não - eu não investiguei até agora. Eu posso errar em primeiro lugar, então se alguém tiver uma explicação melhor, eu ficarei feliz em lê-lo.

Aqui está a solução que funciona no meu Debian:

Você deve se conectar à 127.0.0.2 ( explicação aqui ) e fazer sua regra da seguinte forma:

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

Observe o fragmento -I INPUT 1 que garante que a regra a ser inserida na primeira posição tenha precedência sobre qualquer regra de ACCEPT que você já tenha na sua interface de loopback (como eu fiz no meu Debian).

Eu repeti o teste (com tentativa de conexão SSH, desta vez para 127.0.0.2 ). Falhou imediatamente com

Connection refused

Eu acho que funciona como você deseja, porque agora a mensagem de erro é destinada a 127.0.0.1 , portanto, não sendo pego pela regra de rejeição e capaz de passar.