Por que o DNAT para 127.0.0.1 exige cuidado especial
Entenda o route_localnet ao redirecionar tráfego externo para um componente proxy vinculado ao loopback.
Um serviço escuta em 127.0.0.1:1080. Uma regra DNAT encaminha o tráfego de entrada para esse endereço, mas a conexão falha. O serviço pode estar saudável e a regra NAT pode corresponder: endereços de loopback IPv4 recebem tratamento especial de roteamento.
O route_localnet do Linux controla se os endereços 127/8 são tratados como endereços marcianos durante o roteamento. Seu valor padrão preserva o limite usual do loopback. Uma exceção específica de interface pode ser relevante para um projeto deliberado de redirecionamento local.
Isso explica por que uma regra que funciona em outra máquina pode depender de um sysctl que você não copiou. Mas não justifica habilitar a opção em toda parte.
A suposição de segurança muda com a rota
A vinculação ao loopback é usada com frequência porque um auxiliar não tem autenticação de cliente independente. Se o tráfego vindo de outra interface puder ser roteado para lá, o endereço de vinculação sozinho já não descreve o público alcançável. Restrinja as fontes de entrada, o destino e a porta no conjunto de regras real, incluindo tráfego que reivindica endereços de origem ou destino de loopback quando for relevante.
Revise o namespace de rede que contém o serviço. O loopback de um contêiner não é o do host, e alterar uma configuração de interface do host não cria automaticamente um ouvinte no contêiner.
rp_filter responde a uma pergunta diferente sobre validação do caminho de origem. Desativá-lo globalmente não é um substituto geral para entender o roteamento de loopback. Da mesma forma, ip_nonlocal_bind trata da vinculação de sockets a endereços não locais, não de tornar este caminho DNAT correto.
Por fim, o protocolo redirecionado precisa combinar com o ouvinte. Enviar tráfego HTTP ou TLS bruto para uma porta SOCKS ainda exige um tradutor; uma exceção de roteamento não pode fornecer a negociação ausente.