Роутинг по хостам

[fisher74]

Потому что -h - краткая справка
Надо так смотреть

Код: [Выделить]

~$ man iptables | grep uid-
Сорри... по памяти писал

... --uid-owner ...

[Vady]

И так не работает. Прописал так:

Код: [Выделить]

iptables -t nat -A OUTPUT -o p7p1 -p tcp --dport 80 -m owner ! --uid-owner 13 -j REDIRECT --to-ports 3128Итог: ни в интернет, ни в корпоративную сеть с клиента 10.0.0.2 не попадаю (до кальмара не дошло), а с клиента 192.168.1.2 попадаю в интернет через кальмар, а в корпоративную подсеть - "привет" от кальмара с 403 (что и требовалось).

[fisher74]

Значит с redirect-ом из последней цепочки последней таблицы засада... Я подозревал, что пакет не вернётся обратно...

Значит redirect с локальных процессов не получится. Только запретить, принуждая не трогать глобальную настройку прокси.

[Vady]

Код: [Выделить]

root@TERMINALSERVER:/home/vady# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 959 packets, 96207 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       tcp  --  eth0   *       192.168.1.1          0.0.0.0/0            multiport dports 80,8080 to:127.0.0.1:3128
    0     0 DNAT       tcp  --  eth0   *       192.168.1.0/24       0.0.0.0/0            multiport dports 80,8080 to:192.168.1.1:3128
    1    52 DNAT       tcp  --  p7p1   *       10.0.0.0/24          10.0.0.0/8           multiport dports 80,8080 to:10.0.0.1:3128
    0     0 DNAT       tcp  --  p7p1   *       10.0.0.0/24          172.1.0.0/16         multiport dports 80,8080 to:10.0.0.1:3128
    0     0 DNAT       tcp  --  p7p1   *       10.0.0.0/24          192.224.0.0/16       multiport dports 80,8080 to:10.0.0.1:3128
    1    52 DNAT       tcp  --  p7p1   *       10.0.0.0/24          0.0.0.0/0            multiport dports 80,8080 to:192.168.1.1:3128
    0     0 REDIRECT   tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 3128

Chain INPUT (policy ACCEPT 240 packets, 29143 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 282 packets, 17751 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 259 packets, 16535 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  175 11450 MASQUERADE  all  --  *      eth0    192.168.1.0/24        0.0.0.0/0      Логика такова:
1) всё, что поступает с локального прокси (192.168.1.1), отправить на 127.0.0.1:3128 (без intercept)
2) всё, что поступает с eth0 (192.168.1.0/24), отправить на 192.168.1.1:3128 (с intercept)
3), 4), 5) всё, что поступает с p7p1 (10.0.0.0/24) с адресами назначения, расположенными за корпоративным шлюзом (10.*, 172.*, 192.*), отправить на 10.0.0.1:3128 (с intercept)
6) остальное, что поступает с p7p1, отправить на 192.168.1.1:3128 (с intercept) - ведь именно интерфейс eth0 имеет подключение к интернет-шлюзу.
Результат: первые 5 пунктов успешно выполняются, а 6-й даже ответа на тестовый запрос yandex.ru не получил.
Как логгировать, чтобы определить, на чем именно застрял?

Код: [Выделить]

iptables -t nat -A OUTPUT -o p7p1 -p tcp --dport 80 -m owner ! --uid-owner 13 -j REDIRECT --to-ports 3128Смысл в этом какой?

[fisher74]

Код: [Выделить]

iptables -t nat -A OUTPUT -o p7p1 -p tcp --dport 80 -m owner ! --uid-owner 13 -j REDIRECT --to-ports 3128Смысл в этом какой?

Предполагалось, что http-зпапросы от локальных процессов (браузеры и т.п.) редиректятся на локальный прокси. Понятно, что http-запросы самого прокси исключаются. Но так как цепочка OUTPUT фактически последняя в конвеере netfilter, то оно не срабатывает. Значит полезным действием для этого правила остаётся только DROP.