IPtables Puzzler NAT: Por que o tráfego do host do firewall está sendo NAT, mesmo que não seja proveniente de um dos endereços de origem prescritos?

Question

Eu corro uma pequena rede onde um servidor web linux / mail também fornece NAT para uma coleção de caixas de janelas. Uma dessas máquinas Windows aparentemente está se comportando mal (botnet ZeroAccess, embora eu não consiga encontrar nenhum problema usando o Norton PowerEraser e só tenha conseguido encontrar 3 pacotes 16465 de porta de saída em / var / syslog em semanas de registro). Por alguma razão, a configuração de uma regra de firewall para descartar todos os 16465 pacotes de saída também não resolve o problema, mas esse é um problema não relacionado.

Esse problema está fazendo com que o servidor de e-mail fique na lista negra, por exemplo, spamhaus.org. Como não consigo encontrar o host infectado do Windows, tive a ideia de usar o aliasing de IP para enviar o tráfego NAT por meio de um endereço IP diferente.

Interface externa:

eth0:   216.82.212.230
eth0:1  72.48.103.182

Interface interna:

eth1:   172.18.90.1

Nas minhas regras de firewall, mudei

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 216.82.212.230

para

iptables -t nat -A POSTROUTING -s 172.18.90.0/24 -o eth0 -j SNAT --to 72.48.103.182

O problema agora é que tudo parece estar saindo como 72.48.103.182, incluindo o tráfego do servidor de email. Se eu ssh do host do firewall para outra máquina externa, a conexão é identificada como proveniente de 72.48.103.182.

Isso não faz sentido para mim, pois especifico especificamente os IPs de origem que devem ser NAT. Originalmente tentei a linha acima sem "-s 172.18.90.0/24" e obtive exatamente o mesmo resultado.

Alguma opinião sobre o que está acontecendo? Eu não sou um especialista do iptables por extensão da imaginação, mas tenho feito um esforço para tentar pesquisar isso antes de postar no serverfault.

=======================

root@www:etc# ip ro
216.82.212.0/24 dev eth0  proto kernel  scope link  src 216.82.212.230
72.48.103.0/24 dev eth0  proto kernel  scope link  src 72.48.103.182
172.18.90.0/24 dev eth1  proto kernel  scope link  src 172.18.90.1
default via 216.82.212.254 dev eth0  src 72.48.103.182  metric 100
default via 216.82.212.254 dev eth0  metric 100

    

Answer 1

A parte "mágica" não é a regra SNAT ou a tabela NAT, é a entrada da tabela de roteamento:

default via 216.82.212.254 dev eth0  src 72.48.103.182  metric 100

ele está dizendo ao seu kernel para usar 72.48.103.182 para conexões iniciadas localmente de saída (desde que o socket não esteja explicitamente ligado a um endereço específico na criação) se o destino puder ser acessado através desta rota - o que seria o caso para todos os destinos "externos", pois esta é a sua rota padrão. Você deve redefini-lo como

default via 216.82.212.254 dev eth0  src 216.82.212.230  metric 100

para obter o comportamento esperado.

    

Answer 2

Ok, então, como eu pensei - o seu servidor apenas usa este IP como um outogoing. Na verdade, você não precisa de 2 rotas padrão e é até enganoso. Você tem que usar apenas um:

ip ro add default via 216.82.212.254

O alias que você está usando não precisa ter uma entrada de rota padrão especial, já que é mais do que provável que ele seja roteado de volta pelo seu provedor usando o link principal (endereço) de sua interface.