Iptables

[avb]

ну так никаких других же вменяемых мануалов на тему и нету то.

[drvtiny]

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -p tcp --dport 8081 -j REDIRECT --to-port 3128

А если ещё короче, то

Код: Выделить всё

iptables -t nat -A PREROUTING -p tcp -m multiport --dports http,https,8080 -j REDIRECT --to-port 3128 

Не пишу --sport 1024: потому как где-то вычитал, что в таблице nat фильтрацией лучше не заниматься. Для этого есть filter, обрабатываемый после nat (в данном случае INPUT на порт 3128) В принципе логично
Да, и хватит уже поощрять тех (нелестный эпитет) администраторов, которые настраивают свои общедоступные веб-сервера на нестандартные порты типа 8081, 8082, 8888, а мне тут и 5668 как-то встречался. Пока iptables не умеет отслеживать HTTP-соединения по иным признакам, кроме номера порта источника/назначения, я думаю, следует жёстко фильтровать все "левые" порты.

[Hermit]

drvtiny, https прозрачно не проксиреутся!!

[drvtiny]

Н-да, сорри, я собственно безотносительно к задаче прозрачного проксирования давал ответ. Хотя, помнится, мне как-то грешным делом сам Кантер говорил, что HTTPS-трафик на SQUID всё-таки может прозрачно проксироваться, хотя при этом он не кешируется и не фильтруется. В одном из старых номеров Системного администратора также доказывалось, что прозрачное проксирование HTTPS возможно, хотя и бесполезно. Не исключаю, что так оно и есть, но я, откровенно говоря, не проверял. Сертификаты SSL - это, некоторым образом, моя слабость, так что когда я увидел в конфиге squid'а соответствукющие опции настройки, мне очень быстро расхотелось подобной мурой заниматься. Трафик у меня всё равно нормальной биллинговой системой считается, а не примитивными лог-анализаторами для SQUID'а, так что смысла проксировании (прозрачном или не очень) HTTPS я просто не вижу.