Имеем три канала в Интернет, IP интерфейсов: x.x.x.x, y.y.y.y, z.z.z.z
Создаем правила, для того чтобы пакеты каждого абонента (или группы) отправлять по своему каналу в Интернет.
IPTABLES:1. В mangle, PREROUTING, пакет пришедший с адреса АБОН1 макрируем как MARK=1
В mangle, PREROUTING, пакет пришедший с адреса АБОН2 макрируем как MARK=2
В mangle, PREROUTING, пакет пришедший с адреса АБОН3 макрируем как MARK=32. В nat, POSTROUTING, пакет с MARK=1, SNAT to x.x.x.x
В nat, POSTROUTING, пакет с MARK=2, SNAT to y.y.y.y
В nat, POSTROUTING, пакет с MARK=3, SNAT to z.z.z.z
IP RULE:1. ip rule add fwmark 1 table 1
2. ip rule add fwmark 2 table 2
3. ip rule add fwmark 3 table 3
IP ROUTE:1. ip route add default via шлюз_от_x.x.x.x table 1
2. ip route add default via шлюз_от_y.y.y.y table 2
3. ip route add default via шлюз_от_z.z.z.z table 3
Все бы было хорошо, если бы не пришлось использовать прозрачный прокси для http-трафика.Делаю так:
1. В nat, PREROUTING, пакет на 80 порт -> REDIRECT --to-ports 3128Тем самым пакет попадает в цепочку INPUT, а потом смело вываливается из брандмауэра и попадает в прокси. Тот в свою очередь отправляет его от имени локальной машины в Интернет через “default route”.
Как быть?
И чтобы http-трафик журналировать, и чтобы каждый пользователь пользовался только своим каналом.
>Имеем три канала в Интернет, IP интерфейсов: x.x.x.x, y.y.y.y, z.z.z.z
>Создаем правила, для того чтобы пакеты каждого абонента (или группы) отправлять по
>своему каналу в Интернет.
>
>
>IPTABLES:
>
>1. В mangle, PREROUTING, пакет пришедший с адреса АБОН1 макрируем как MARK=1
>
> В mangle, PREROUTING, пакет пришедший с адреса АБОН2 макрируем
>как MARK=2
> В mangle, PREROUTING, пакет пришедший с адреса АБОН3 макрируем
>как MARK=3
>
>2. В nat, POSTROUTING, пакет с MARK=1, SNAT to x.x.x.x
> В nat, POSTROUTING, пакет с MARK=2, SNAT to y.y.y.y
>
> В nat, POSTROUTING, пакет с MARK=3, SNAT to z.z.z.z
>
>
>
>IP RULE:
>
>1. ip rule add fwmark 1 table 1
>2. ip rule add fwmark 2 table 2
>3. ip rule add fwmark 3 table 3
>
>
>IP ROUTE:
>
>1. ip route add default via шлюз_от_x.x.x.x table 1
>2. ip route add default via шлюз_от_y.y.y.y table 2
>3. ip route add default via шлюз_от_z.z.z.z table 3
>
>
>Все бы было хорошо, если бы не пришлось использовать прозрачный прокси для
>http-трафика.
>
>Делаю так:
>1. В nat, PREROUTING, пакет на 80 порт -> REDIRECT --to-ports 3128
>
>Тем самым пакет попадает в цепочку INPUT, а потом смело вываливается из
>брандмауэра и попадает в прокси. Тот в свою очередь отправляет его
>от имени локальной машины в Интернет через “default route”.
>
>
>Как быть?
>И чтобы http-трафик журналировать, и чтобы каждый пользователь пользовался только своим каналом.
запускай 3 сквида
заставляй их биндиться к x.x.x.x:3128, y.y.y.y:3128 и z.z.z.z:3128
а также биндиться _исходящими_ своими соединениями к соотв. ipшникам
ip rule add src x.x.x.x table 1
ip rule add src y.y.y.y table 2
ip rule add src z.z.z.z table 3
ну и редиректи каждую группу на свой сквид\^P^/
>запускай 3 сквида
>заставляй их биндиться к x.x.x.x:3128, y.y.y.y:3128 и z.z.z.z:3128
>а также биндиться _исходящими_ своими соединениями к соотв. ipшникам
>ip rule add src x.x.x.x table 1
>ip rule add src y.y.y.y table 2
>ip rule add src z.z.z.z table 3
>ну и редиректи каждую группу на свой сквидСпасибо perece - в очередной раз помогаете.
Вопрос как теперь запустить 3 сквида, это ведь 3 конфигурационных файла для него и пр... Ну ладно, поиском пройдусь - решу проблему.
Вот еще вопрос: А если не городить огород с десятком сквидов ? Есть ли какие-небудь утилиты для журналирования http-трафика (кто/куда/зачем) типа сквида, но только совсем чтобы прозрачно работал безо-всяких-там редиректов?
>>запускай 3 сквида
>>заставляй их биндиться к x.x.x.x:3128, y.y.y.y:3128 и z.z.z.z:3128
>>а также биндиться _исходящими_ своими соединениями к соотв. ipшникам
>>ip rule add src x.x.x.x table 1
>>ip rule add src y.y.y.y table 2
>>ip rule add src z.z.z.z table 3
>>ну и редиректи каждую группу на свой сквид
>
>Спасибо perece - в очередной раз помогаете.
>
>Вопрос как теперь запустить 3 сквида, это ведь 3 конфигурационных файла для
>него и пр... Ну ладно, поиском пройдусь - решу проблему.
>
>Вот еще вопрос: А если не городить огород с десятком сквидов ?
>Есть ли какие-небудь утилиты для журналирования http-трафика (кто/куда/зачем) типа сквида, но
>только совсем чтобы прозрачно работал безо-всяких-там редиректов?
нету.
1) трудно реализовать, ибо длинный запрос может содержаться более чем в 1 пакете
2) это легко обходится с клиентской стороны установкой mtu в очень небольшое значение.
3) много "похожих" фрагментов может лететь в POST-запросе в "теле" поста (аплуд по http) - будут фальшпозитивы.
задачка логирования адресов уровня приложения (а именно таковыми являются урлы) на сетевом уровне, где работает фильтр пакетов - не решается.\^P^/
>Как быть?
>И чтобы http-трафик журналировать, и чтобы каждый пользователь пользовался только своим каналом.
>
найдешь решение дай знать ;)
у меня со squid так ничего и не вышло :(
Могу посоветовать попробовать в сквиде написать так:
acl one_net src 192.168.1.0/24 (например одна сетка или можно написать определенные адреса)
acl two_net src 192.168.2.0/24 (другая)
tcp_outgoing_address 192.168.1.253 one_net (на выходе со сквида на этот acl адрес будет такой)
tcp_outgoing_address 192.168.2.253 two_net (соответственно другая сетка)а потом в файерволе перенаправлять адреса туда куда надо
>Могу посоветовать попробовать в сквиде написать так...Собственно так и сделал, но на это решился только когда выискал способ загружать список адресов из файла, очень не хотелось постоянно модифицировать squid.conf
А способ вот: acl one_net src "/usr/local/etc/squid/access_full_list"
>>Могу посоветовать попробовать в сквиде написать так...
>
>Собственно так и сделал, но на это решился только когда выискал способ
>загружать список адресов из файла, очень не хотелось постоянно модифицировать squid.conf
>
>А способ вот: acl one_net src "/usr/local/etc/squid/access_full_list"У тебя я так понял linux (не знаю как там), но допустим в FreeBSD можно еще в файерволе создать таблицы с адресами для проверки.