LINUX.ORG.RU
решено ФорумAdmin

iptables, прозрачный squid и один интерфейс.

 ,


1

1

Здравствуйте, господа!

Появилась задача, но увы с iptables я знаком поверхностно.

Имеется:

  • Шлюз 192.168.0.1 (DNS, DHCP, iptables)
  • Прокси 192.168.0.222 (прозрачный squid)
  • Сервера 192.168.0.2-10 (трафик проксировать не нужно)
  • Клиенты 192.168.0.100-110 (пул DHCP, пускаем через squid)

На машине прокси с одним интерфейсом развернут прозрачный squid. Хочется весь трафик от клиентов по 80 и 443 порту пускать через него, а все что осталось отправлять прямиком на шлюз.

Вижу 2 варианта реализации:

1) На серверах статикой указан основным шлюзом 192.168.0.1, а клиенты в свою очередь получают DHCP с шлюзом 192.168.0.222 (sqid). Тем самым сервера минуют squid, а клиенты ходят к основному шлюзу через него.

На прокси необходимо пробросить входящий трафик 80/443 через кальмара, все остальное пропускаем дальше на шлюз

net.ipv4.ip_forward в sysctl включил

В данный момент пробовал так, но не удалось:

# Чистим iptable
iptables -F
iptables -X
iptables --table nat -F
iptables --table nat -X
iptables --table mangle -F
iptables --table mangle -X

# Направляем 80 и 443 порт через squid
iptables -t nat -A PREROUTING -i ens192 -s 192.168.0.0/24 -d 192.168.0.0/24 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i ens192 -s 192.168.0.0/24 -d 192.168.0.0/24 -p tcp --dport 443 -j ACCEPT

iptables -t nat -A PREROUTING -i ens192 -s 192.168.0.0/24 -p tcp --dport 80 -j DNAT --to 192.168.0.222:3128
iptables -t nat -A PREROUTING -i ens192 -s 192.168.0.0/24 -p tcp --dport 443 -j DNAT --to 192.168.0.222:3129

# Пропускаем DNS c шлюза
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 192.168.0.1:53
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 192.168.0.1:53

iptables -t nat -I POSTROUTING -o ens192 -s 192.168.0.0/24 -d 192.168.0.222 -p tcp -j SNAT --to 192.168.0.1

iptables -I FORWARD -i ens192 -o ens192 -s 192.168.0.0/24 -d 192.168.0.222 -p tcp --dport 3128 -j ACCEPT
iptables -I FORWARD -i ens192 -o ens192 -s 192.168.0.0/24 -d 192.168.0.222 -p tcp --dport 3129 -j ACCEPT

2) Второй вариант, на шлюзе пишется правило, что необходимо для диапазана 192.168.0.100-110 входящий трафик по 80/443 завернуть на 192.168.0.222:3128

Набросал что-то такое.

iptables -t nat -A PREROUTING -s ! 192.168.0.100-110 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.222:3128
iptables -t nat -A PREROUTING -s ! 192.168.0.100-110 -p tcp --dport 443 -j DNAT --to-destination 192.168.0.222:3129

iptables -t nat -A POSTROUTING -s ! 192.168.0.222 -p tcp -d 192.168.0.222 -j SNAT --to-source 192.168.0.1
iptables -A FORWARD -s 192.168.0.100-110 -j ACCEPT
Гуру iptables пните плз в нужную сторону. Какой вариант более логичный. И как лучше всего быть в случае падения кальмара?

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

1. Речь идет про локальный комп на котором запущен сквид? Или вы еще кого-то другого из локалки отправить через него хотите?
2. Вы где все эти правила пишите? На роутере? На компе со сквидом?
Как обычно дайте больше золота, что бы только по правилам не догадываться что у вас там за схема.

anc ★★★★★ ()

Обычно делается ровно наоборот. Клиентам из 192.168.0.0/24 выставляется шлюз 192.168.0.1.

На 192.168.0.1 в свою очередь, всё что идёт «наружу» по 80/443 порту, заворачивается на 192.168.0.222 (т.е. прокси). Естественно, кроме адреса самого прокси, чтобы избежать петли. Способы могут быть разные: DNAT или что-то более продвинутое вроде WCCP.

anonymous ()
Ответ на: комментарий от anc

судя по ip-ам в правилах у него сейчас: хост 192.168.0.222 на котором висит сквид, за шлюзом 192.168.0.1. Короче он с локального компа все хочет перенаправить на прокси.

ving2 ()

-s ! 192.168.0.100-110

что то вы с -s намудрили

samson ★★ ()

В обоих случаях сам squid должен быть настроен в transparent-mode

1. вариант Для проверки сделайте INPUT и FORWARD -j ACCEPT.

# сам редирект
iptables -t nat -A PREROUTING -i ens192 -s 192.168.0.0/24 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i ens192 -s 192.168.0.0/24 -p tcp --dport 443 -j REDIRECT --to-port 3129

2. вариант

iptables -t nat -A PREROUTING -s 192.168.0.100-110 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.222:3128
iptables -t nat -A PREROUTING -s 192.168.0.100-110 -p tcp --dport 443 -j DNAT --to-destination 192.168.0.222:3129
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE 

samson ★★ ()
Ответ на: комментарий от anc

И как оно поможет в данном случае, если статистика нужна - вроде ничего ж не изменится. Так то конечно изврат еще тот...

ving2 ()
Ответ на: комментарий от ving2

И как оно поможет в данном случае, если статистика нужна - вроде ничего ж не изменится.

Почему? Если будет -o внешний-интерфейс, то локальные не попадут под это правило.

anc ★★★★★ ()

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

24/7/365 ?
Если да, то такие вещи в любом случае на стенде надо тестировать, а не полагаться на советы лора, тут советы дают куда копать и только в редких случаях(по настроению) за вас поднимают тестовые полигоны что бы прогнать и дать полностью готовое решение :)
Если нет, так и тестируйте в не рабочее время.

anc ★★★★★ ()
Ответ на: комментарий от anc

На лор пришел все же получить пару дельных, между строк таки можно приглядеть хороший совет.

Сейчас все работает, проблема была не тривиальной, dns_nameservers 8.8.8.8 стоял, сменил на адрес шлюза, все заработало. Остановился на первом варианте.

------

Вот еще задумал сделать на шлюзе проверку доступности кальмара, вдруг умрет, чтоб DHCP настройки обновились и новый шлюз клиентам выдало.

Решение достойно жизни?

WoozyMasta ()
Ответ на: комментарий от WoozyMasta

Сейчас все работает, проблема была не тривиальной, dns_nameservers 8.8.8.8 стоял, сменил на адрес шлюза, все заработало. Остановился на первом варианте.

Я бы второй взял, вроде проще по исполнению. Но тестировать надо.
Не понятно как помешал внешний dns, скорее еще какие-то правила в iptables толи на шлюзе толи на кальмаре. Вобщем много но.

Вот еще задумал сделать на шлюзе проверку доступности кальмара, вдруг умрет, чтоб DHCP настройки обновились и новый шлюз клиентам выдало.

1. В части именно этой формулировки. Опятьтаки в теории. Выдавать маленький leasetime, однако на практике может быть чревато большими глюками. Повторюсь я бы пользовал второй вариант, т.к. все сосредоточенно на сервере(шлюзе) и не трогаем клиентов.
2. «проверку доступности кальмара» - как именно вы планируете это делать? А то вариантов гораздо больше одного. Это же как и любой другой сервис, работать можем частично. С такой же долей вероятности у вас и шлюз может упасть.

anc ★★★★★ ()
Ответ на: комментарий от anc

Почему? Если будет -o внешний-интерфейс, то локальные не попадут под это правило.

Я то написал правило (-s) для hairpin nat (оно же и остальной nat в инет делает). Тут действительно есть минус в том, что src-addr клиента подменится адресом шлюза и стаистики не будет видно.

Как я понимаю, совет anc подразумевает следуещее:

# на шлюзе
iptables -t nat -A PREROUTING -s 192.168.0.100-110 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.222:3128
iptables -t nat -A PREROUTING -s 192.168.0.100-110 -p tcp --dport 443 -j DNAT --to-destination 192.168.0.222:3129
# snat наружу, пакеты перенаправленные на squid под это правило действительно не попадут:
iptables -t nat -A POSTROUTING -o OUT_IFACE -j MASQUERADE
# это правило комментируем (для hairpin) 
# iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE 
Вот тут возникают сомнения, какой ответ (с каким src-ip) получит клиент (как прозрачный squid ответит клиенту)... Но со статистикой будет все ок. Надо проверять.

ps: лишним не будет:

# на squid можно (не не обязательно) прописать следующее
iptables -t nat -A PREROUTING -i ens192 -s 192.168.0.0/24 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i ens192 -s 192.168.0.0/24 -p tcp --dport 443 -j REDIRECT --to-port 3129

pps: вот сам сижу и думаю, применим ли, кстати, в такой ситуации hairpin вообще или нет... но из расуждений тут: http://macrodmin.ru/2011/08/osobennosti-prozrachnogo-proksi следует, что хотя бы работает.

ppps: тут я имел ввиду вариант №2

samson ★★ ()
Последнее исправление: samson (всего исправлений: 1)
Ответ на: комментарий от anc

Я бы второй взял, вроде проще по исполнению.

если только работать будет. Если же нет - то теряем статистику.

И, кстати, тогда вариант №1 (когда клиентам раздаем squid в качестве gw) решает проблему со статистикой, запрос будет отправлен client-src-ip

samson ★★ ()
Ответ на: комментарий от ving2

да и вариант, предложенный ving2, тоже не плох. Вполне все логично.

Как оно по производительности - хз. Тут что быстрее -set-mark или MASQUERADE/SNAT

samson ★★ ()

2ТС:

вы бы лучше выложили итоговые правила iptables на шлюзе и на squid-host-е. А по первому сообщению вообще не понятно, чего вы хотели добиться от iptables

samson ★★ ()
Ответ на: комментарий от samson

Я бы вот так сделал.

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o OUT_IFACE -j MASQUERADE
т.е. сеть бы тоже оставил, а то мало чего у нас еще будет.

anc ★★★★★ ()
Ответ на: комментарий от anc

Да, все правильно для srcnat наружу.

Но это правило не сделает подмену адреса пакетам идущим на прокси. С одной стороны оно и не надо (что бы в статистике отображался адрес клиента), с другой стороны, какой src_ip будет в ответе прокси клиенту...

samson ★★ ()
Ответ на: комментарий от samson

pps: вот сам сижу и думаю, применим ли, кстати, в такой ситуации hairpin вообще или нет... но из расуждений тут: http://macrodmin.ru/2011/08/osobennosti-prozrachnogo-proksi следует, что хотя бы работает.

Ну честно говоря я и сам оттолкнулся от этой статьи, ведь вся проблема описанная в ней только в том что masq на все интерфейсы действовал, так что исправление в виде интерфейса сделает то же самое только проще. Но опять-таки надо тестировать, а то одно дело теория/написано другое самому попробовать :)

anc ★★★★★ ()
Ответ на: комментарий от samson

с другой стороны, какой src_ip будет в ответе прокси клиенту...

А разве есть какая-то разница между тем если бы кальмар работал например на том же шлюзе и этим вариантом? Клиент отправляет пакет на 8.8.8.8 получает ответ от 8.8.8.8. Мы же про прозрачный прокси говорим. Или я вас не понял?

anc ★★★★★ ()
Ответ на: комментарий от anc

Похоже что так и есть. Наверное сквид в прозрачном режиме и проделает все эти действия.

Действительно, он же работает, если просто на шлюзе...

PS: squid прозрачный очень давно настраивал. Помню, что ему в конфиге надо прописать этот режим и редирект на него сделать

Надо просто взять и проверить

samson ★★ ()
Последнее исправление: samson (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.