O host não envia pacotes ACK-SYN para proxy transparente

Question

Estou configurando um proxy transparente usando haproxy, a configuração funciona sem a linha 'source 0.0.0.0 usesrc client'. Quando eu adiciono essa linha, o nó de extremidade é chamado a partir do endereço IP do cliente original e o tcpdump mostra que os pacotes chegam ao host de destino, mas eles não parecem ser processados ou respondidos, eventualmente, o tempo limite da solicitação.

Broken Tcp Dump Log (Taken from target backend server):
13:36:33.782686 IP 10.3.0.92.56177 > 192.168.0.5.80: Flags [S], seq 2733860398, win 14600, options [mss 1460,sackOK,TS val 2090146 ecr 0,nop,wscale 5], length 0
13:36:34.808390 IP 10.3.0.92.56177 > 192.168.0.5.80: Flags [S], seq 2733860398, win 14600, options [mss 1460,sackOK,TS val 2091146 ecr 0,nop,wscale 5], length 0
13:36:35.600765 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1518413688, win 14600, options [mss 1460,sackOK,TS val 2091930 ecr 0,nop,wscale 5], length 0
13:36:36.623120 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1518413688, win 14600, options [mss 1460,sackOK,TS val 2092930 ecr 0,nop,wscale 5], length 0
13:36:36.840211 IP 10.3.0.92.56177 > 192.168.0.5.80: Flags [S], seq 2733860398, win 14600, options [mss 1460,sackOK,TS val 2093146 ecr 0,nop,wscale 5], length 0
13:36:38.665777 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1518413688, win 14600, options [mss 1460,sackOK,TS val 2094930 ecr 0,nop,wscale 5], length 0
13:36:39.603892 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1580967374, win 14600, options [mss 1460,sackOK,TS val 2095842 ecr 0,nop,wscale 5], length 0
13:36:40.653243 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1580967374, win 14600, options [mss 1460,sackOK,TS val 2096842 ecr 0,nop,wscale 5], length 0
13:36:42.742138 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1580967374, win 14600, options [mss 1460,sackOK,TS val 2098842 ecr 0,nop,wscale 5], length 0
13:36:43.606977 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1643514971, win 14600, options [mss 1460,sackOK,TS val 2099693 ecr 0,nop,wscale 5], length 0
13:36:44.624129 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1643514971, win 14600, options [mss 1460,sackOK,TS val 2100693 ecr 0,nop,wscale 5], length 0
13:36:46.653801 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1643514971, win 14600, options [mss 1460,sackOK,TS val 2102693 ecr 0,nop,wscale 5], length 0
13:36:47.610193 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1706062128, win 14600, options [mss 1460,sackOK,TS val 2103607 ecr 0,nop,wscale 5], length 0
13:36:48.630226 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1706062128, win 14600, options [mss 1460,sackOK,TS val 2104607 ecr 0,nop,wscale 5], length 0
13:36:50.665869 IP 10.3.0.92.56185 > 192.168.0.5.80: Flags [S], seq 1706062128, win 14600, options [mss 1460,sackOK,TS val 2106607 ecr 0,nop,wscale 5], length 0



Working Tcp Dump log (Taken from target backend server):
13:37:34.519616 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [S], seq 926283285, win 14600, options [mss 1460,sackOK,TS val 2149599 ecr 0,nop,wscale 5], length 0
13:37:34.520083 IP 192.168.0.5.80 > 192.168.0.1.55694: Flags [S.], seq 3779931433, ack 926283286, win 14480, options [mss 1460,sackOK,TS val 2354335 ecr 2149599,nop,wscale 6], length 0
13:37:34.520931 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [.], ack 1, win 457, options [nop,nop,TS val 2149600 ecr 2354335], length 0
13:37:34.520973 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [P.], seq 1:365, ack 1, win 457, options [nop,nop,TS val 2149600 ecr 2354335], length 364
13:37:34.520985 IP 192.168.0.5.80 > 192.168.0.1.55694: Flags [.], ack 365, win 243, options [nop,nop,TS val 2354336 ecr 2149600], length 0
13:37:34.521188 IP 192.168.0.5.80 > 192.168.0.1.55694: Flags [P.], seq 1:238, ack 365, win 243, options [nop,nop,TS val 2354336 ecr 2149600], length 237
13:37:34.521718 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [.], ack 238, win 490, options [nop,nop,TS val 2149601 ecr 2354336], length 0
13:37:34.521735 IP 192.168.0.5.80 > 192.168.0.1.55694: Flags [P.], seq 238:850, ack 365, win 243, options [nop,nop,TS val 2354336 ecr 2149601], length 612
13:37:34.522295 IP 192.168.0.1.55694 > 192.168.0.5.80: Flags [.], ack 850, win 528, options [nop,nop,TS val 2149601 ecr 2354336], length 0

Alguma idéia de por que o sistema de destino não parece estar vendo esses pacotes? Eu parei o iptables no host de destino.

ATUALIZAÇÃO:

se eu definir o gateway do servidor backend para o haproxy, o servidor responderá ao SYN (claramente, já que agora sabe para onde enviar a resposta), mas agora o host haproxy retorna com "host 10.3.0.92 inacessível - admin proibido , comprimento 68 "o gateway do host de backend deve ser configurado para o host haproxy?

15:31:13.862481 IP 10.3.0.92.63460 > 192.168.0.5.80: Flags [S], seq 2693662872, win 14600, options [mss 1460,sackOK,TS val 6178395 ecr 0,nop,wscale 5], length 0
15:31:13.862548 IP 192.168.0.5.80 > 10.3.0.92.63460: Flags [S.], seq 2196759473, ack 2693662873, win 14480, options [mss 1460,sackOK,TS val 9094716 ecr 6178395,nop,wscale 6], length 0
15:31:13.863366 IP 192.168.0.1 > 192.168.0.5: ICMP host 10.3.0.92 unreachable - admin prohibited, length 68
15:31:14.882199 IP 10.3.0.92.63460 > 192.168.0.5.80: Flags [S], seq 2693662872, win 14600, options [mss 1460,sackOK,TS val 6179395 ecr 0,nop,wscale 5], length 0
15:31:14.882238 IP 192.168.0.5.80 > 10.3.0.92.63460: Flags [S.], seq 2212692439, ack 2693662873, win 14480, options [mss 1460,sackOK,TS val 9095715 ecr 6179395,nop,wscale 6], length 0
15:31:14.882479 IP 192.168.0.1 > 192.168.0.5: ICMP host 10.3.0.92 unreachable - admin prohibited, length 68
...

    

Answer 1

Acredito que encontrei a solução, sendo um desenvolvedor e não um administrador de sistemas. Isso demorou um pouco para ser concluído, mas, em última análise, acredito que a questão era que, para a proxying transparente funcionar, o proxy precisa também será o gateway padrão do host de destino.

Dessa forma:

1. O proxy faz uma chamada falsificada, representando o cliente original
2. O host de destino responde à chamada falsificada, mas como o host de destino não está no intervalo de IP do chamador, sua resposta vai para o gateway padrão
3. A configuração da máquina como o gateway padrão da rede precisa atuar como um gateway (obviamente), ou seja, aceitar todo o tráfego de entrada, independentemente de onde ele está destinado, e encaminhá-lo para seu destino.

Portanto, no meu caso, parece que preciso apenas implementar a etapa 3, já que agora o host proxy está reclamando de não saber o que fazer com o SYN-ACK ao qual o host de destino respondeu.

Vou postar uma atualização quando tiver tempo para verificar tudo isso.