endereço de origem com o encaminhamento de porta iptables

Question

Eu configurei o encaminhamento de porta para a porta 80 com iptables:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 10080  

Além disso, tenho o encaminhamento de ip ativado para rotear conexões de uma sub-rede diferente.

Estou executando meu próprio servidor de soquete padrão na porta 10080 na mesma máquina e, quando recebo uma conexão de entrada na porta 80, ele é encaminhado para o servidor conforme o esperado.

Meu problema é que, quando imprimo as informações de soquete usando getsockname e getpeername, o endereço de origem é sempre o do servidor. Se eu me conectar ao servidor diretamente através de uma porta que não é afetada pela regra iptables, vejo o endereço do cliente conforme o esperado. Por que o encaminhamento de porta está afetando o endereço de origem?

    

Answer 1

Eu não acho que o alvo de redirecionamento é o correto para usar neste caso, o alvo NAT dinâmico seria mais apropriado.

Um trecho do link :

If you have a server on your internal network that you want make available externally, you can use the -j DNAT target of the PREROUTING chain in NAT to specify a destination IP address and port where incoming packets requesting a connection to your internal service can be forwarded. For example, if you wanted to forward incoming HTTP requests to your dedicated Apache HTTP Server server system at 172.31.0.23, run the following command:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \
  --to 172.31.0.23:80

    

Answer 2

My problem is that when I print out the socket information using getsockname and getpeername, the source address is always the server's. If I connect to the server directly through a port that is not affected by the iptables rule I see the client address as expected. Why is port forwarding affecting the source address?

Vou explicar, mas esteja avisado de que esta será uma longa explicação .

Vamos primeiro entender o que é uma Conexão TCP : É um intercâmbio de dados orientado à conexão entre uma 'tupla iniciadora' (IP,Port) e uma 'tueta terminadora' (IP,port) .

Em outras palavras, a conexão TCP é definida por um quatro-ple de (Client_IP,Client_Port,Server_IP,Server_Port) .

Isso significa que toda a transferência de informações para essa conexão TCP precisa atender a quatro definições.

Agora, vamos supor que seu servidor esteja localizado em 1.1.1.1 e o cliente em 2.2.2.2. O cliente abre a conexão com a porta 80 do seu servidor. Assumindo que a porta efêmera do cliente é 34567, temos o quatro-pto (2.2.2.2,34567,1.1.1.1,80).

No seu servidor, o pacote é redirecionado para 1.1.1.1:10080. Mas isso resulta em um diferente número de conexões! Por exemplo, (2.2.2.2,34567,1.1.1.1,18080).

O que o ouvinte real fará? Por que responderia diretamente ao 2.2.2.2:34567, resultando no pacote a ser descartado pelo cliente, pois o cliente possui o múltiplo de (2.2.2.2.34567,1.1.1.1,80) e não (2.2. 2.2.34567,1.1.1.1,18080).

Portanto, nesse caso, o REDIRECT alvo precisa criar um mapeamento temporário de quatro páginas:

(2.2.2.2,34567,1.1.1.1,80) --> (1.1.1.1,x,1.1.1.1,10080)

(x é uma porta temporária e efêmera para permitir que a conexão TCP seja construída).

Com esse mapeamento temporário, o servidor em 10080 responde a netfilter e ocorre um mapeamento reverso:

(1.1.1.1,x,1.1.1.1,10080) --> (2.2.2.2,34567,1.1.1.1,80)

netfilter envia o pacote que foi mapeado para o cliente, e está tudo bem.

Portanto, se você precisar saber o endereço IP do cliente, NÃO poderá usar o REDIRECT target. Em vez disso, coloque seu servidor real em uma sub-rede diferente e use DNAT target, com seu servidor Linux atuando como um roteador completo. Supondo que seu servidor real tenha um endereço de LAN local de 192.168.1.51, o mapeamento será:

(2.2.2.2,34567,1.1.1.1,80) --> (2.2.2.2,34567,192.168.1.51,80)

O servidor em 192.168.1.51 responderá ao 2.2.2.2, e o roteador irá inverter o mapa:

(2.2.2.2,34567,192.168.1.51,80) --> (2.2.2.2,34567,1.1.1.1,80)

E tudo bem.