Прозрачный прокси + белый список для внутренней сети

Помогите постичь Дао iptables

К сожалению, чтения документации, тебе не избежать.

Мне нужно настроить доступ в интернет для белого списка адресов внутренней сети...

Советую поставить fwbuilder и настроить всё мышкой. А потом уже посмотреть, во что превращаются твои правила.

Советую поставить fwbuilder и настроить всё мышкой. А потом уже посмотреть, во что превращаются твои правила.

Сложно ответить цензурно.

К сожалению, чтения документации, тебе не избежать.

А по тексту не видно, что уже читал? Хорошо, объясняю подробнее:
В первом случае, по документации, пакет проходит mangle PREROUTING и там отправляется на локальное приложение. После чего _не_должен_ проходить filter FORWARD. Однако, получается наоборот. Теперь ответь мне, человек, советующий fwbuilder, из-за чего происходит сей курьёз?

Я имел в виду всего лишь жугл: оно?

Я имел в виду всего лишь жугл: оно?

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

давай dmesg.

Не очень понимаю, зачем тебе, но вот: http://pastebin.com/tkbHvKit
А вот rc.firewall в последней редакции: http://pastebin.com/WkA5MgXN
Из rc.firewall я вырезал только список адресов с комментариями. Оставил один адрес.

А ты NEW и ESTABLISHED разрешил?

Я же rc.firewall приложил. Да, разрешил. Если не использовать правила для whitelist, то всё работает. Но мне как раз понадобилось добавить белый список. Сейчас работает белый список, но на прокси ничего не попадает. А это довольно большой объём трафика.

Сдаюсь

$IPTABLES -t mangle -A PREROUTING -i $LAN_IFACE '!' -d 192.168.1.22 -p tcp --dport 80 -j TPROXY --on-port 3129

Doing it wrong!

Вот простой православный способ:

iptables -t nat -A PREROUTING -s 192.168.1.0/24 -d ! 192.168.1.22 -p tcp -m multiport --dport 21,25,80110,443,563,777,2080,2082,8080,10000 -j REDIRECT --to-port 3129 
#iptables -t nat -A PREROUTING -s 192.168.1.0/24 -d ! 192.168.1.22 -p udp -m multiport --dport 21,25,80110,443,563,777,2080,2082,8080,10000 -j REDIRECT --to-port 3129

Для создания white-list сам Тукс велел пользоваться ipset. Соответственно, в каждое правило нужно будет добавить "-m set --match-set whitelist src", создать с помощью ipset эту самую таблицу «whitelist» и добавить в неё нужные адреса.

Единственный минус: возможно, что потребуется пересборка ядра для поддержки модуля ip_set.

Doing it wrong!

Тогда почему этот способ описан в руководстве Сквида? WTF???

Может потому, что перед писавшим руководство не стояло задачи настраивать разграничение доступа посредством iptables? А в таблице mangle дропать пакеты категорически не рекомендуется. Но, конечно, можно добавить условие для переброса пакета и в таблицу mangle, а неугодных дропать на filter. Впрочем, неугодных в любом случае лучше резать на фильтре. И всё-таки ipset этот вопрос значительно облегчит.

Ок, значит буду копать в сторону ipset. Спасибо.

Ещё маленький вопрос: если я делаю REDIRECT, то в конфигах сквида должно стоять http_port 192.168.1.22:3129 transparent или tproxy тоже подойдёт?

Если я ничего не путаю, то transparent должно стоять.

Doing it wrong!

с удовольствием послушаю, как сделать прозрачный прокси без TPROXY, но с сохранением IP пользователя на выходе. Объем - примерно 700 пользователей, у каждого белый IP. Нужно чтобы после выхода с прокси IP не изменился...

P.S. С TPROXY у меня уже все работает :-). Просто интересна твоя посылка...

Просто интересна твоя посылка.

В изначальной задаче у ТС не было задачи выдать каждому белый IP, зато была задача настроить заблокировать фаерволом неугодных. В комментарии выше я указал, что можно в принципе начинать фильтрацию и в таблице mangle, но остальное всё равно резать на фильтре.

согласись, это можно сделать и с помощью TPROXY?

Мне кажется, или в таблице mangle по другому сделать было бы затруднительно?

А ещё с REDIRECT не работает прозрачный SSL.
Если напишешь, как всё это организовать буду очень признателен.

а с TPROXY можно разве прозрачный SSL сделать? Это ж вроде man-in-the-middle и как бы не-Ъ.

У меня организовано так:

vpn1 ~ # ip rule
0:      from all lookup local 
50:     from all fwmark 0x1 lookup tproxy 
32766:  from all lookup main 
32767:  from all lookup default

vpn1 ~ # cat /etc/iproute2/rt_tables 
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep

100     tproxy

Кусок правил iptables:

*mangle
:TRANSPARENT_PROXY - [0:0]
-A TRANSPARENT_PROXY -j MARK --set-mark 1
-A TRANSPARENT_PROXY -j ACCEPT
:PREROUTING ACCEPT [0:0]
# for TPROXY
-A PREROUTING -p tcp -m socket -j TRANSPARENT_PROXY
-A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -i eth3 -p tcp --dport 1723 -j ACCEPT
# for TPROXY
-A INPUT -i ppp+ -p tcp --dport 80 -j ACCEPT
#
-A INPUT -j REJECT --reject-with icmp-port-unreachable
СOMMIT

Конфиг сквида:

http_port 3129 tproxy
icp_port 0
max_filedesc 16384
access_log /var/log/squid/access.log
cache_store_log none

acl localhost src 127.0.0.1/32
acl manager proto cache_object
http_access allow manager localhost
http_access deny manager

http_access allow all

shutdown_lifetime 3 seconds

Версия squid и используемая ОС:

vpn1 ~ # squid -v | head -1
Squid Cache: Version 3.1.19
vpn1 ~ # cat /etc/*release
Gentoo Base System release 2.1

Уже разобрался.
Да, SSL можно сделать только с mitm. Кстати, сквид это умеет: http://www.opennet.ru/openforum/vsluhforumID12/5890.html#10