LINUX.ORG.RU
Форум — Admin  

Учет трафика в iptables пренаправляемого на прокси.


0

0

Соит простенький биллинг - iptables, ulogd, mysql. Появилась необходимость настроить прозачный прокси. Настроить не проблема redirect .... Проблема в учете трафика, до установки прокси весь трафик считался в цепочке billing куда перенаправлялся с filter FORWARD. Теперь после редиректа трафик до filter FORWARD не доходит. Т.к. после nat PREROUTING трафик идет локальному приложению. Какой можно найти выход из ситуации что бы этот трафик все же попадал в цепочку billling? Ловить его инпутом перед прокси после редиректа не подходит - адреса назнчачениия уже другие. А у меня биллинг считает отдельно локальный трафик, отдельно тракфик в мир.


есть один метод но он только для малого числа клиентов, надо настроить сквид чтобы в зависимсти от клиента, squid использовал уникальный tos или ip (опции tcp_outgoing_address или tcp_outgoing_tos), метод факитески является костылем так что наверное вам лучше использовать логи сквида либо дописать к сквиду часть которая будет считать трафик во внутреннюю сеть и фиксировать внешний айпи с которым этот трафик связан. или поставить промежуточный маршрутизатор который будет считать а прокси за ним.

x86 ★★
()

а может еще в таблице mangle PREROUTING можно считать?

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

Кстати, судя по докам, картинка кривая. output-цепи должны стоять перед маршрутизацией, иначе смысл postrouting-цепей не совсем понятен.

Вроде, так.

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

Поправьте, если ошибаюсь, а то уже сам сомневаюсь :-).

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

Mangle
допускается выполнять только нижеперечисленные действия:
TOS
TTL
MARK



Nat

DNAT
SNAT
MASQUERADE

tmp
() автор топика
Ответ на: комментарий от Lego_12239

> output-цепи должны стоять перед маршрутизацией
Через OUTPUT цепочки проходят пакеты созданные локальными процессами. НО ! Не каждый процесс при открытии socket-а делает bind на конкретный адрес, поэтому src адрес для пакетов от этих процессов изначально будет неизвестен. А если мы не знаем src IP, то какой смысл пропускать такой НЕДОпакет через firewall ? Как раз для этого сначала и делается маршрутизация (чтоб по dst IP определить куда пойдет пакет и взять с этого интерфейса/маршрута src IP), а потом проход через firewall.
НО ! Еще в ядре, на сколько я помню, можно включить повторную перемаршрутизацию, после прохождения firewall, для того, чтоб через -j MARK можно было влиять на маршрутизацию (чтоб работали ip rule add fwmark ...). Правда, при повторе src IP не меняется (чисто из опыта).

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

Так маршрутизация перед output-цепочками она полноценная или какая-нибудь кастрированная(только для определения src IP, например)?

Lego_12239 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin