Iptables: tabela de pós-escrita NAT totalmente ignorada

0

Enquanto brincava com o keeplived, me deparei com esse comportamento estranho (ou é?).

O cenário é o seguinte:

Uma rede interna que possui um gateway (chame-o de gw) e um monte de hosts (um deles chamado ih1). Outro host (chame ha) que tem 2 interfaces: uma na rede pública e uma segunda na interna. Um host externo (eh1)

[ha] é uma instância de keepalived para rotear o tráfego para hosts internos que oferecem um serviço, diz smtp. [ih1] é um servidor smpt, seu gateway padrão é [gw]

de [eh1] nc [ha] 25 não funciona, e se falhar de uma maneira eu não esperava nada.

Quando o pacote inicial acerta [ih1] ele responde através de seu gateway padrão, [eh1] recebe a resposta, mas o estranho é em vez do ip público de [gw] (como seria de se esperar porque [gw] deveria masquerading) obtém uma resposta com o endereço IP real de [ih1]. isto é: [gw] está encaminhando os pacotes, não os mascarando. É claro que [eh] não tem ideia de como alcançar diretamente [ih1], por isso não consegue estabelecer uma conexão.

Cavar rende que todos os pacotes originados de [ih1] em resposta à solicitação [eh] não estão passando pela cadeia POSTROUTING da tabela nat do iptable.

Mas se [ih1] iniciar a conexão (digamos, ping [eh1] ou ssh [eh1]), ela funcionará como deveria.

Comparando ambas as situações, a única coisa que vem à mente é que no primeiro [gw] nunca se diz o pacote SYN inicial, tudo o que viu foi a resposta SYN / ACK.

EDITAR: onde I_LAN é lan interno: 172.16.0.0/24 e E_LAN é lan externo: 192.168.0.0/24

    [eh1]-- E_LAN --
                               ---------
       ---E_LAN--[ha]--I_LAN--| switch  |--I_LAN--[gw]--ELAN--
                               ---------
                                   |
                                 [ih1]
    
por Raouf M. Bencheraiet 31.03.2017 / 19:19

0 respostas

Tags