Здравствуйте, друзья!Есть роутер (ip: 10.99.99.100/24).
Прописан статический маршрут в сеть 10.0.0.0/24netstat -rn:
10.0.0.0 10.99.99.9 255.255.255.0 UG 0 0 0 eth0
10.99.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0Делаю прозрачный прокси на соседней коробке (ip: 10.0.0.5/24).
Вот по этому ману: http://www.tldp.org/HOWTO/TransparentProxy-6.htmlСоздаю таблицу:
ip rule add fwmark 2 table proxyПытаюсь сделать:
ip route add default via 10.0.0.5 dev eth0 table proxyПолучаю ошибку:
RTNETLINK answers: No such processНижеследующее, конечно же, работает, так как этот "via" находится в одной сети с роутером.
ip route add default via 10.99.99.5 dev eth0 table proxyПомогите, пожалуйста, сделать дефолт роутинг помеченных пакетов на айпи из другой сети
(наверное, я правильно сформулировал).Спасибо заранее!
>[оверквотинг удален]
> Пытаюсь сделать:
> ip route add default via 10.0.0.5 dev eth0 table proxy
> Получаю ошибку:
> RTNETLINK answers: No such process
> Нижеследующее, конечно же, работает, так как этот "via" находится в одной сети
> с роутером.
> ip route add default via 10.99.99.5 dev eth0 table proxy
> Помогите, пожалуйста, сделать дефолт роутинг помеченных пакетов на айпи из другой сети
> (наверное, я правильно сформулировал).
> Спасибо заранее!кофиги показывай и runtime инфу - телепатов нет.
>[оверквотинг удален]
>> ip route add default via 10.0.0.5 dev eth0 table proxy
>> Получаю ошибку:
>> RTNETLINK answers: No such process
>> Нижеследующее, конечно же, работает, так как этот "via" находится в одной сети
>> с роутером.
>> ip route add default via 10.99.99.5 dev eth0 table proxy
>> Помогите, пожалуйста, сделать дефолт роутинг помеченных пакетов на айпи из другой сети
>> (наверное, я правильно сформулировал).
>> Спасибо заранее!
> кофиги показывай и runtime инфу - телепатов нет.ок, какие конфиги?
runtime?
# cat /proc/net/netlink
# depmod -n | grep netlinkчё говорят?
> # cat /proc/net/netlink
> # depmod -n | grep netlink
> чё говорят?#cat /proc/net/netlink
sk Eth Pid Groups Rmem Wmem Dump Locks Drops
f6a0a400 0 0 00000000 0 0 (null) 2 0
c16e5400 0 1639 00000110 0 0 (null) 2 0
f637ae00 6 0 00000000 0 0 (null) 2 0
f6273200 7 0 00000000 0 0 (null) 2 0
f6b31e00 9 1296 00000000 0 0 (null) 2 0
f621f600 9 0 00000000 0 0 (null) 2 0
f600d200 10 0 00000000 0 0 (null) 2 0
f6a8f400 11 0 00000000 0 0 (null) 2 0
f63fbe00 15 541 00000001 0 0 (null) 2 0
f6b31c00 15 -4263 00000000 0 0 (null) 2 0
c15d2c00 15 -4264 00000000 0 0 (null) 2 0
f6a0a200 15 0 00000000 0 0 (null) 2 0
f6aaec00 16 0 00000000 0 0 (null) 2 0
f6aaee00 18 0 00000000 0 0 (null) 2 0#depmod -n | grep netlink
kernel/net/netfilter/nfnetlink.ko:
kernel/net/netfilter/nfnetlink_queue.ko: kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/nfnetlink_log.ko: kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/nf_conntrack_netlink.ko: kernel/net/netfilter/nf_conntrack.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/xt_set.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/xt_NFLOG.ko: kernel/net/netfilter/nfnetlink_log.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/xt_osf.ko: kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set.ko: kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_bitmap_ip.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_bitmap_ipmac.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_bitmap_port.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_hash_ip.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_hash_ipport.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_hash_ipportip.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_hash_ipportnet.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_hash_net.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_hash_netport.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
kernel/net/netfilter/ipset/ip_set_list_set.ko: kernel/net/netfilter/ipset/ip_set.ko kernel/net/netfilter/nfnetlink.ko
alias net-pf-16-proto-12 nfnetlink
alias nfnetlink-subsys-3 nfnetlink_queue
alias nfnetlink-subsys-4 nfnetlink_log
alias nfnetlink-subsys-2 nf_conntrack_netlink
alias nfnetlink-subsys-1 nf_conntrack_netlink
alias ip_conntrack_netlink nf_conntrack_netlink
alias nfnetlink-subsys-5 xt_osf
alias nfnetlink-subsys-6 ip_set
alias symbol:nfnetlink_parse_nat_setup_hook nf_conntrack
alias symbol:nfulnl_log_packet nfnetlink_log
alias symbol:nfnetlink_unicast nfnetlink
alias symbol:nfnetlink_subsys_register nfnetlink
alias symbol:nfnetlink_set_err nfnetlink
alias symbol:nfnl_unlock nfnetlink
alias symbol:nfnetlink_send nfnetlink
alias symbol:nfnl_lock nfnetlink
alias symbol:nfnetlink_subsys_unregister nfnetlink
alias symbol:nfnetlink_has_listeners nfnetlink
Наверное:
ip route add to 10.99.99.0/24 dev eth0 table proxy
ip route add to 10.0.0.0/24 via 10.99.99.9 dev eth0 table proxy
ip route add default via 10.0.0.5 dev eth0 table proxyА вообще-то, "default", должен быть в той-же самой сети, по определению.
> Наверное:
> ip route add to 10.99.99.0/24 dev eth0 table proxy
> ip route add to 10.0.0.0/24 via 10.99.99.9 dev eth0 table proxy
> ip route add default via 10.0.0.5 dev eth0 table proxy
> А вообще-то, "default", должен быть в той-же самой сети, по определению.К сожалению, опять не сработало:
#ip route add to 10.99.99.0/24 dev eth0 table proxy
#ip route add to 10.0.0.0/24 via 10.99.99.9 dev eth0 table proxy
#ip route add default via 10.0.0.5 dev eth0 table proxy
RTNETLINK answers: No such process
> А вообще-то, "default", должен быть в той-же самой сети, по определению.Ок!
Переделал сетевые настройки карточки роутера на 10.99.99.100/8 (чтобы 10.0.0.5 оказался в той же сети).
# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
UUID=4021d250-a1d3-4421-8258-7265f9c4b5d3
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
IPV6INIT=no
USERCTL=no
IPADDR=10.99.99.100
NETMASK=255.0.0.0#ip route
8x.xx.xx.0/25 dev eth1 proto kernel scope link src 8x.xx.xx.xx
10.0.0.0/24 via 10.99.99.9 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
10.0.0.0/8 dev eth0 proto kernel scope link src 10.99.99.100
default via 85.xx.xx.xx dev eth1# ip rule
0: from all lookup local
32765: from all fwmark 0x2 lookup proxy
32766: from all lookup main
32767: from all lookup default# ip route show table proxy
10.0.0.0/24 via 10.99.99.9 dev eth0
10.99.99.0/24 dev eth0 scope link
default via 10.0.0.5 dev eth0То есть, маршрут вписался, однако пакеты на 10.0.0.5 из этой таблицы уходят с интерфейса не via 10.99.99.9, а просто выпихиваются наружу (подключил в хаб к 10.10.10.100 машину с ip 10.0.0.5 и tcpdump'ом увидел пакеты).
При этом, из шелла пинг на 10.0.0.5 ходит правильным маршрутом.
Что ж делать-то?
> Что ж делать-то?Картинку структуры сети нарисуй, нифига ж непонятно, чё и куда пытаешься отправить!
вот тут какая-то жопа.
10.0.0.0/24 via 10.99.99.9 dev eth0
10.0.0.0/8 dev eth0 proto kernel scope link src 10.99.99.100
>> Что ж делать-то?
> Картинку структуры сети нарисуй, нифига ж непонятно, чё и куда пытаешься отправить!
> вот тут какая-то жопа.
> 10.0.0.0/24 via 10.99.99.9 dev eth0
> 10.0.0.0/8 dev eth0 proto kernel scope link src 10.99.99.100Картинка по ссылке. Полупрозрачный комп - это тот, который я подключал для теста.
http://leprastuff.ru/data/img/20130725/4e464bcd38048b1134437...
>[оверквотинг удален]
> 32767: from all lookup default
> # ip route show table proxy
> 10.0.0.0/24 via 10.99.99.9 dev eth0
> 10.99.99.0/24 dev eth0 scope link
> default via 10.0.0.5 dev eth0
> То есть, маршрут вписался, однако пакеты на 10.0.0.5 из этой таблицы уходят
> с интерфейса не via 10.99.99.9, а просто выпихиваются наружу (подключил в
> хаб к 10.10.10.100 машину с ip 10.0.0.5 и tcpdump'ом увидел пакеты).
> При этом, из шелла пинг на 10.0.0.5 ходит правильным маршрутом.
> Что ж делать-то?Поправка:
(подключил в хаб к 10.99.99.100 машину с ip 10.0.0.5 и tcpdump'ом увидел пакеты)
>[оверквотинг удален]
>> 10.99.99.0/24 dev eth0 scope link
>> default via 10.0.0.5 dev eth0
>> То есть, маршрут вписался, однако пакеты на 10.0.0.5 из этой таблицы уходят
>> с интерфейса не via 10.99.99.9, а просто выпихиваются наружу (подключил в
>> хаб к 10.10.10.100 машину с ip 10.0.0.5 и tcpdump'ом увидел пакеты).
>> При этом, из шелла пинг на 10.0.0.5 ходит правильным маршрутом.
>> Что ж делать-то?
> Поправка:
> (подключил в хаб к 10.99.99.100 машину с ip 10.0.0.5 и tcpdump'ом увидел
> пакеты)маркируете только в PREROUTING? если да, то из шелла пакеты не будут маркироваться и в table proxy не попадут, тогда по идее если уберете маркировку то пакет к 10.0.0.5 пойдет правильно.
если это верно, то проблема в table proxyпробовали в table proxy
10.99.99.0/24 dev eth0 scope link изменить на
10.99.99.0/8 dev eth0 scope link
>[оверквотинг удален]
>>> default via 10.0.0.5 dev eth0
>>> То есть, маршрут вписался, однако пакеты на 10.0.0.5 из этой таблицы уходят
>>> с интерфейса не via 10.99.99.9, а просто выпихиваются наружу (подключил в
>>> хаб к 10.10.10.100 машину с ip 10.0.0.5 и tcpdump'ом увидел пакеты).
>>> При этом, из шелла пинг на 10.0.0.5 ходит правильным маршрутом.
>>> Что ж делать-то?
>> Поправка:
>> (подключил в хаб к 10.99.99.100 машину с ip 10.0.0.5 и tcpdump'ом увидел
>> пакеты)
> маркируете только в PREROUTING?Да, конечно. В POSTROUTING их маркировать уже нет смысла. Я делаю прозраный прокси и мне нужно, что бы с роутера покеты уходили на прокси, а не в интернет.
#port forward for SQUID
#$Ipt -t nat -A PREROUTING -p tcp -s 10.0.0.6 -i $INT_IFACE --dport 80 -j MARK --set-mark 2
#echo "nat21"; $Ipt -t mangle -A PREROUTING -m mark --mark 2 -j ACCEPT
> если да, то из шелла пакеты не будут
> маркироваться и в table proxy не попадут, тогда по идее если
> уберете маркировку то пакет к 10.0.0.5 пойдет правильно.Все верно! Так и есть.
> если это верно, то проблема в table proxy
> пробовали в table proxy
> 10.99.99.0/24 dev eth0 scope link изменить на
> 10.99.99.0/8 dev eth0 scope linkПопробовал только что, неуспешно:
# ip route del 10.99.99.0/24 dev eth0 table proxy
# ip route add 10.99.99.0/8 dev eth0 scope link table proxy
RTNETLINK answers: Invalid argument
>[оверквотинг удален]
>>> пакеты)
>> маркируете только в PREROUTING?
> Да, конечно. В POSTROUTING их маркировать уже нет смысла. Я делаю прозраный
> прокси и мне нужно, что бы с роутера покеты уходили на
> прокси, а не в интернет.
> #port forward for SQUID
> #$Ipt -t nat -A PREROUTING -p tcp -s 10.0.0.6 -i $INT_IFACE --dport
> 80 -j MARK --set-mark 2
> #echo "nat21"; $Ipt -t mangle -A PREROUTING -m mark --mark 2 -j
> ACCEPTможет все таки через dnat сделать, а то вить еще и на 10.99.99.9 как то эти пакеты выщимлять придется, про ответные пакеты на прямую - это в обоих случаях.
>[оверквотинг удален]
>> уберете маркировку то пакет к 10.0.0.5 пойдет правильно.
> Все верно! Так и есть.
>> если это верно, то проблема в table proxy
>> пробовали в table proxy
>> 10.99.99.0/24 dev eth0 scope link изменить на
>> 10.99.99.0/8 dev eth0 scope link
> Попробовал только что, неуспешно:
> # ip route del 10.99.99.0/24 dev eth0 table proxy
> # ip route add 10.99.99.0/8 dev eth0 scope link table proxy
> RTNETLINK answers: Invalid argumentтеоретически маршрут по умолчанию из другой подсети прописать можно, но учитывая что при этом передача идет по mac-адресу и ip не трогается, а у вас 10.0.0.5 отделен от 10.99.99.100, то придется еще и на 10.99.99.9 что то городить.
>[оверквотинг удален]
>> прокси и мне нужно, что бы с роутера покеты уходили на
>> прокси, а не в интернет.
>> #port forward for SQUID
>> #$Ipt -t nat -A PREROUTING -p tcp -s 10.0.0.6 -i $INT_IFACE --dport
>> 80 -j MARK --set-mark 2
>> #echo "nat21"; $Ipt -t mangle -A PREROUTING -m mark --mark 2 -j
>> ACCEPT
> может все таки через dnat сделать, а то вить еще и на
> 10.99.99.9 как то эти пакеты выщимлять придется, про ответные пакеты на
> прямую - это в обоих случаях.С DNAT'ом у меня не срослось - пакеты до прокси доходят, но она (прокси) их не обрабатывает. А все маны для сквида 2.4, где еще httpd_accel было.
Еще мне не понравилась оговорка, что вариант с DNAT не работает в "экзотических" случаях, а еще что-то про http/1.1
Хотя, это, определенно, решение проблемы.
>[оверквотинг удален]
>>> 10.99.99.0/24 dev eth0 scope link изменить на
>>> 10.99.99.0/8 dev eth0 scope link
>> Попробовал только что, неуспешно:
>> # ip route del 10.99.99.0/24 dev eth0 table proxy
>> # ip route add 10.99.99.0/8 dev eth0 scope link table proxy
>> RTNETLINK answers: Invalid argument
> теоретически маршрут по умолчанию из другой подсети прописать можно, но учитывая что
> при этом передача идет по mac-адресу и ip не трогается, а
> у вас 10.0.0.5 отделен от 10.99.99.100, то придется еще и на
> 10.99.99.9 что то городить.Ой, тут не совсем понял, что имелось ввиду)
>[оверквотинг удален]
>>>> 10.99.99.0/8 dev eth0 scope link
>>> Попробовал только что, неуспешно:
>>> # ip route del 10.99.99.0/24 dev eth0 table proxy
>>> # ip route add 10.99.99.0/8 dev eth0 scope link table proxy
>>> RTNETLINK answers: Invalid argument
>> теоретически маршрут по умолчанию из другой подсети прописать можно, но учитывая что
>> при этом передача идет по mac-адресу и ip не трогается, а
>> у вас 10.0.0.5 отделен от 10.99.99.100, то придется еще и на
>> 10.99.99.9 что то городить.
> Ой, тут не совсем понял, что имелось ввиду)10.99.99.9 физически разделяет 10.99.99.100 и 10.0.0.5?
10.0.0.5 - mac 1:2:3
10.99.99.9 - mac 4:5:610.99.99.100 допустим догадывается что шлюз по умолчанию за 10.99.99.9 и пересылает пакет на mac 4:5:6 , как 10.99.99.9 поймет что это пакет нужно переслать на mac 1:2:3, ip 10.0.0.5 вить в пакете не фигурирует ?
>[оверквотинг удален]
>>>> Попробовал только что, неуспешно:
>>>> # ip route del 10.99.99.0/24 dev eth0 table proxy
>>>> # ip route add 10.99.99.0/8 dev eth0 scope link table proxy
>>>> RTNETLINK answers: Invalid argument
>>> теоретически маршрут по умолчанию из другой подсети прописать можно, но учитывая что
>>> при этом передача идет по mac-адресу и ip не трогается, а
>>> у вас 10.0.0.5 отделен от 10.99.99.100, то придется еще и на
>>> 10.99.99.9 что то городить.
>> Ой, тут не совсем понял, что имелось ввиду)
> 10.99.99.9 физически разделяет 10.99.99.100 и 10.0.0.5?Ага.
> 10.0.0.5 - mac 1:2:3
> 10.99.99.9 - mac 4:5:6
> 10.99.99.100 допустим догадывается что шлюз по умолчанию за 10.99.99.9 и пересылает пакет
> на mac 4:5:6 , как 10.99.99.9 поймет что это пакет нужно
> переслать на mac 1:2:3, ip 10.0.0.5 вить в пакете не фигурирует
> ?Кажется, понял. Да, работать по макам - это не наш путь.
Может у вас есть успешный опыт настройки прозрачного прокси (squid-3.1) на отдельной от роутера коробке при помощи DNAT? Буду весьма признателен.
>[оверквотинг удален]
> Ага.
>> 10.0.0.5 - mac 1:2:3
>> 10.99.99.9 - mac 4:5:6
>> 10.99.99.100 допустим догадывается что шлюз по умолчанию за 10.99.99.9 и пересылает пакет
>> на mac 4:5:6 , как 10.99.99.9 поймет что это пакет нужно
>> переслать на mac 1:2:3, ip 10.0.0.5 вить в пакете не фигурирует
>> ?
> Кажется, понял. Да, работать по макам - это не наш путь.
> Может у вас есть успешный опыт настройки прозрачного прокси (squid-3.1) на отдельной
> от роутера коробке при помощи DNAT? Буду весьма признателен.есть.
для начала определитесь нужно ли что бы ip прокси был из той же подсети что и клиент , если да то на коробке придется еще и snat для заворачиваемых пакетов делать для правильного хождения ответов, но при этом в логах прокси будет ip роутера, а не клиента
>[оверквотинг удален]
>>> ?
>> Кажется, понял. Да, работать по макам - это не наш путь.
>> Может у вас есть успешный опыт настройки прозрачного прокси (squid-3.1) на отдельной
>> от роутера коробке при помощи DNAT? Буду весьма признателен.
> есть.
> для начала определитесь нужно ли что бы ip прокси был из той
> же подсети что и клиент , если да то на коробке
> придется еще и snat для заворачиваемых пакетов делать для правильного хождения
> ответов, но при этом в логах прокси будет ip роутера, а
> не клиентаКлиент, прокси и роутер будут в разных сетях. Соответственно, для примера:
10.0.1.10/24 - клиент
10.0.0.5/24 - прокси
10.99.99.100/24 - роутер.Если же в этом случае в логах прокси будут ip только роутера - тогда этот вариант не годится.
У меня всегда остается вариант поставить прокси в ту же сеть, что и роутер. Не очень желательно (придется менять архтектуру со всеми вытекающими), но как вариант.
> Может у вас есть успешный опыт настройки прозрачного прокси (squid-3.1) на отдельной
> от роутера коробке при помощи DNAT? Буду весьма признателен.а в чем собственно проблема?
>> Может у вас есть успешный опыт настройки прозрачного прокси (squid-3.1) на отдельной
>> от роутера коробке при помощи DNAT? Буду весьма признателен.
> а в чем собственно проблема?делал вот так:
iptables -t nat -A PREROUTING -i eth0 ! -s squid-box -p tcp --dport 80 -j DNAT --to squid-box:3128
Пакет до прокси доходит, я вижу его tcpdump'ом. Но дальше ничего не происходит.
а когда вот так делаю:
iptables -t nat -A PREROUTING -i eth0 ! -s squid-box -p tcp --dport 80 -j DNAT --to squid-box:3128
iptables -t nat -A POSTROUTING -o eth0 -s local-network -d squid-box -j SNAT --to iptables-boxПакет до прокси не доходит вообще, хотя выходят из роутера (видно tcpdump'ом). Наверное, из-за особенностей моей топологии.
Еще раз картинка:http://leprastuff.ru/data/img/20130725/4e464bcd38048b1134437...
На всякий случай, конфиг прокси:# cat /etc/squid/squid.conf
visible_hostname domain.local
#
# Recommended minimum configuration:
#
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
#acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#acl localnet src fc00::/7 # RFC 4193 local private network range
#acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machinesacl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager# Deny requests to certain unsafe ports
http_access deny !Safe_ports# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
## Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost# And finally deny all other access to this proxy
http_access deny all# Squid normally listens to port 3128
http_port 3128 transparent# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp: &n... 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320cache deny all
no_cache deny all
>>> Может у вас есть успешный опыт настройки прозрачного прокси (squid-3.1) на отдельной
>>> от роутера коробке при помощи DNAT? Буду весьма признателен.
>> а в чем собственно проблема?
> делал вот так:
> iptables -t nat -A PREROUTING -i eth0 ! -s squid-box -p tcp
> --dport 80 -j DNAT --to squid-box:3128tcpdump ответные пакеты показывал?
логи прокси смотрели?
прокси запустился и netstat видит что он слушает порт 3128?
были обращения клиентов в логах?если клиенты тоже идут через 10.0.0.1/10.99.99.9 , то возможно ответ доходил до этого роутера и дальше шел клиенту, не дойдя до 10.99.99.100 и не пройдя обратного преобразования на nat
> Пакет до прокси доходит, я вижу его tcpdump'ом. Но дальше ничего не
> происходит.
> а когда вот так делаю:
> iptables -t nat -A PREROUTING -i eth0 ! -s squid-box -p tcp
> --dport 80 -j DNAT --to squid-box:3128
> iptables -t nat -A POSTROUTING -o eth0 -s local-network -d squid-box -j
> SNAT --to iptables-box
> Пакет до прокси не доходит вообще, хотя выходят из роутера (видно tcpdump'ом).тогда смотреть настройки на 10.0.0.1/10.99.99.9
> Наверное, из-за особенностей моей топологии.
> Еще раз картинка:
> http://leprastuff.ru/data/img/20130725/4e464bcd38048b1134437...10.0.0.1/10.99.99.9 может организовать логическую подсеть между 10.99.99.100 и прокси?
>[оверквотинг удален]
> 1440 20% 10080
> refresh_pattern ^gopher: 1440
> 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0%
> 0
> refresh_pattern .
> 0
> 20% 4320
> cache deny all
> no_cache deny all
Итак, я нашел у себя ошибку в схеме с DNAT'ом и схема заработала! Я в SNAT'e неправильно прописал последний ip.$Ipt -t nat -A PREROUTING -i eth0 ! -s $proxy -p tcp --dport 80 -j DNAT --to 10.0.0.5:3128
$Ipt -t nat -A POSTROUTING -o eth0 -s $int_net -d 10.0.0.5 -j SNAT --to 10.99.99.100Верно ваше утверждение, что без SNATa, обратные пакеты не пройдут через 10.99.99.100. Тестовая машина тоже в сети 10.0.0.0/24. Ответ идет напрямую и ничего путного не получается.
Финита ля комедиа.Спасибо вам большое, вы меня в правильную сторону развернули вопросами)
Тем не менее, моя задача не решена, поскольку на прокси сервере теперь нельзя дифференцировать запросы по айпи (все они приходят с роутера, естественно). Поэтому, придется работать через fwmark. А ввиду всей дискуссии выше, я понял, что роутер и прокси должны находиться в одной сети.
> 10.0.0.1/10.99.99.9 может организовать логическую подсеть между 10.99.99.100 и прокси?Я к сожалению, не владею терминологией. Что имеется ввиду?
Спасибо вам за уделенное мне время!
>[оверквотинг удален]
> Тестовая машина тоже в сети 10.0.0.0/24. Ответ идет напрямую и ничего
> путного не получается.
> Финита ля комедиа.
> Спасибо вам большое, вы меня в правильную сторону развернули вопросами)
> Тем не менее, моя задача не решена, поскольку на прокси сервере теперь
> нельзя дифференцировать запросы по айпи (все они приходят с роутера, естественно).
> Поэтому, придется работать через fwmark. А ввиду всей дискуссии выше, я
> понял, что роутер и прокси должны находиться в одной сети.
>> 10.0.0.1/10.99.99.9 может организовать логическую подсеть между 10.99.99.100 и прокси?
> Я к сожалению, не владею терминологией. Что имеется ввиду?vlan, bridge если можно прокси воткнуть в отдельный интерфейс
> Спасибо вам за уделенное мне время!
>>> 10.0.0.1/10.99.99.9 может организовать логическую подсеть между 10.99.99.100 и прокси?
>> Я к сожалению, не владею терминологией. Что имеется ввиду?
> vlan, bridge если можно прокси воткнуть в отдельный интерфейсПонял вас. Что-то подобное я и сделаю. Но это уже за пределами топика.
Еще раз спасибо!
> А ввиду всей дискуссии выше, я
> понял, что роутер и прокси должны находиться в одной сети.Нет, могут и в разных, но на разных интерфейсах - eth{0,1}, тогда если
все с маршрутами верно(на обоих устройствах) SNAT не нужен.Если честно можно и вашу схему, реализовать c помощью alias -
eth0 - 10.99.99.100/24 eth0:1 - 10.0.0.2/24, но не советую,
гонять туда-сюда по одному проводу, одни и теже пакеты,
как минимум два раза, плохая затея, на уровне МАС адресов будет чехорда и плохо
уловимые ошибки.
