Назад | Перейти на главную страницу

Хост не отправляет пакеты ACK-SYN для прозрачного прокси

Я настраиваю прозрачный прокси с помощью haproxy, настройка работает без строки «source 0.0.0.0 usesrc client». Когда я добавляю эту строку, конечная точка вызывается с исходного IP-адреса клиента, и tcpdump показывает, что пакеты прибывают на целевой хост, но, похоже, они не обрабатываются или не отвечают, в конечном итоге запрос истекает.

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

Есть идеи, почему целевая система не видит эти пакеты? Я остановил iptables на целевом хосте.

ОБНОВИТЬ:

если я устанавливаю шлюз внутреннего сервера на haproxy, тогда сервер отвечает на SYN (очевидно, поскольку теперь он знает, куда отправить ответ.), но теперь хост haproxy возвращается с сообщением «хост 10.3.0.92 недоступен - администратор запрещен, длина 68 "следует ли настроить шлюз внутреннего хоста на хост 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
...

Я считаю, что я нашел решение, будучи разработчиком, а не системным администратором, это заняло немного времени, чтобы понять, но в конечном итоге я считаю, что проблема заключалась в том, что для работы прозрачного проксирования прокси также должен быть шлюз по умолчанию целевого хоста.

Туда:

Прокси-сервер выполняет ложный вызов, выдавая себя за исходного клиента.
Целевой хост отвечает на поддельный вызов, но поскольку целевой хост не входит в диапазон IP-адресов вызывающего абонента, его ответ идет на шлюз по умолчанию.
Машина, настроенная в качестве сетевого шлюза по умолчанию, должна действовать как шлюз (очевидно), то есть принимать весь входящий трафик независимо от того, где он предназначен, и пересылать его по назначению.

Итак, в моем случае, похоже, мне просто нужно реализовать шаг 3, поскольку прокси-хост теперь жалуется на то, что не знает, что делать с SYN-ACK, которым ответил целевой хост.

Я выложу обновление, когда у меня будет время все это проверить.