A cadeia PREROUTING não é percorrida por pacotes originados do host ( este diagrama é útil para descobrir quais cadeias um pacote irá percorrer). Você deseja colocar essas regras na cadeia OUTPUT da tabela nat .
host = 172.16.1.155 é um IP público (alterou usando sed para ser consistente). guest = 192.168.122.10 é o IP de uma máquina virtual em execução na máquina física cujo IP é 172.16.1.155. Eu tenho as seguintes regras (descartadas com iptables-save e filtradas) para os dois hosts em questão (além de todas as informações necessárias para entender o contexto):
*filter
-A INPUT -d 172.16.1.155/32 -p tcp -m multiport --dports 25,465 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j DROP
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i _+ -o _+ -j ACCEPT
-A FORWARD -i _+ -o eth0 -j ACCEPT
-A FORWARD -d 192.168.122.10/32 -p tcp -m multiport --dports 25,465 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j LOG
-A FORWARD -j DROP
COMMIT
*nat
-A PREROUTING -d 172.16.1.155/32 -p tcp -m multiport --dports 25,465 -j DNAT --to-destination 192.168.122.10
COMMIT
As regras garantem que qualquer solicitação do mundo externo para o IP público de host acabe em guest . Tudo isso funciona bem e como pretendido. Existem muito mais regras, mas elas afetam apenas os outros convidados ou têm objetivos não relacionados. Todas as interfaces para os convidados começam com um sublinhado, portanto, posso usar convenientemente _+ para corresponder aos nomes das interfaces nas regras acima.
As máquinas virtuais são todos convidados do KVM. O nome da interface da ponte é virbr0 . Cada máquina virtual com um endereço IP externo possui uma interface com o mesmo nome, mas é precedida por um sublinhado (portanto, guest foo teria a interface _foo ).
Além disso, o KVM cria uma interface vnetX ( X sendo um número) por convidado.
As seguintes rotas são definidas w.r.t. o host e guest em questão:
172.16.1.155 * 255.255.255.255 UH 0 0 0 eth0
192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0
default 172.16.1.155 0.0.0.0 UG 100 0 0 eth0
Se eu criar um proxy SOCKS pelo SSH-ing em host ( ssh -D ), não consigo me conectar a guest por meio desse proxy. Primeiro, achei que o motivo era que o proxy SOCKS provavelmente usaria a interface lo ( tcpdump -i lo confirma isso) no lado host , então adicionei a seguinte regra iptables -I FORWARD -i lo -p tcp -m multiport --dports 25,465 -j ACCEPT (lembre-se de que -A INPUT -i lo -j ACCEPT aceita a entrada já), mas isso já deve ser coberto por -A FORWARD -d 192.168.122.10/32 -p tcp -m multiport --dports 25,465 -j ACCEPT . Então eu removi a regra novamente e tentei a seguinte regra de NAT: iptables -t nat -I PREROUTING -d 127.0.0.1/24 -p tcp -m multiport --dports 25,465 -j DNAT --to-destination 192.168.122.10 e subseqüentemente seu equivalente (para todos os propósitos práticos) iptables -t nat -I PREROUTING -i lo -p tcp -m multiport --dports 25,465 -j DNAT --to-destination 192.168.122.10 . Nem me deu o resultado que eu queria.
Como posso preencher a lacuna nesse cenário? Além disso, minha suposição é válida para testar se o proxy SOCKS funciona usando telnet 127.0.0.1 25 ?
Então eu adicionei a regra iptables -t nat -D OUTPUT -d 127.0.0.1/24 -p tcp -m multiport --dports 25,465 -j DNAT --to-destination 192.168.122.10 como sugerido por mgorven. Há claramente uma mudança de comportamento aqui, mas ainda não é totalmente o que estou procurando.
Sem essa regra, obtenho:
$ telnet localhost 25
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
com essa regra eu recebo:
$ telnet localhost 25
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection timed out
A cadeia PREROUTING não é percorrida por pacotes originados do host ( este diagrama é útil para descobrir quais cadeias um pacote irá percorrer). Você deseja colocar essas regras na cadeia OUTPUT da tabela nat .
