Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Спасибо 05.03.04 18:55 Число просмотров: 1506
Автор: sklif Статус: Незарегистрированный пользователь
|
|
Спасибо за ссылку. Про iproute2 я в курсе был. Вещь полезная, но она не поможет решить проблему, или я чего то не понимаю. в принципе не стал изобретать велосипед и все сделал перелопачиванием сквидовых логов. Сабж был открыт по причине - вдруг есть приемлемое решение , о котором я не знаю. Судя по количеству просмотров и ответов - нет.
|
|
<sysadmin>
|
Squid и iptables !!! 27.02.04 10:07
Автор: sklif Статус: Незарегистрированный пользователь
|
Итак!
Есть сервер под управлением Linux Slackware 8.1 (ядро 2.4.18). Два сетевых интерфейса. Один сетевой интерфейс, пусть это будет
eth0, имеет реальный ip-адрес и смотрит в сеть провайдера. Второй сетевой интерфейс, eth1 соответственно, имеет фиктивный ip-адрес
и смотрит в локальную сеть. На сервере стоит Squid и в iptables для пользователей локальной сети настроен прозрачный прокси следующим образом:
1) в таблице nat в цепочке PREROUTING пакеты идущие на 80 порт перенаправляются (-j REDIRECT) на порт 3128.
2) в таблице nat в цепочке POSTROUTING выполняется действие SNAT для всех src-ip из локалки для не http трафика.
Все просто в общем.
Далее, входящий трафик считается в ip-tables при помощи действия ULOG, и результаты на лету заносятся в MySQL базу.
С не http трафиком все понятно, пакеты летают через цепочку FORWARD таблицы filter, замечательно отлавливаются и пишутся в базу.
А вот с http трафиком начинаются вопросы.
Итак, клиент посылает пакет на 80 порт скажем на www.ya.ru. Этот пакет под действием правила REDIRECT попадает в цепочку INPUT и в конечном счете
попадает к локальному процессу, а именно к Squid. Дальше Squid либо возвращает ответ из кэша (если он там есть), при этом формируется новый пакет, который проходит через цепочку
OUTPUT таблицы filter и возвращается клиенту; либо формирует запрос во внешнюю сеть.
Я могу при помощи правил и действия ULOG подсчитать весь входящий http трафик, который идет к Squid извне. Я могу подсчитать весь
трафик, который Squid отдает в локалку пользователям.
Уважаемые знатоки, внимание вопрос !
Как в iptables (без перелопачивания сквидовых текстовых логов) связать (или отследить) пакет , который прилетел извне на Squid, и пакет, который Squid отправил в локалку пользователю на основании этого прилетевшего ?
То есть надо знать, откуда реально пришел пакет (с ip адрес прова, или с cisco.com или еще откуда-нибудь) и на каком фиктивном pi он в конечном счете осел в локалке.
Вся фигня в том, что это два разных пакета, и повязаны они только внутри Squid.
Есть одна мысль, как можно эту проблему победить. В таблице mangle при помощи действия MARK метить пришедшие на Squid извне пакеты. Но тогда возникает еще один вопрос,
умеет ли Squid или можно его как то заставить ? распознавать эти метки и лепить такие же на формируемые им пакеты, которые он отдат в локалку пользователям.
В мануале по ip-tables сказано, что некоторые прграммы умеют работать с такими метками (например iproute2).
Всем заранее спасибо за ответы.
P.S. В пакетах, которые Squid отдает в локалку пользователям, время равно 0 всегда. Это что за особенность такая ?
|
| |
Спасибо 05.03.04 18:55
Автор: sklif Статус: Незарегистрированный пользователь
|
|
Спасибо за ссылку. Про iproute2 я в курсе был. Вещь полезная, но она не поможет решить проблему, или я чего то не понимаю. в принципе не стал изобретать велосипед и все сделал перелопачиванием сквидовых логов. Сабж был открыт по причине - вдруг есть приемлемое решение , о котором я не знаю. Судя по количеству просмотров и ответов - нет.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
