Итак, в предыдущих заметках мы настроили "прозрачный" прокси-сервер, отталкиваясь от конфигурации обычного, прямого подключения, прокси. Заметно, что в целом настройка их не особо отличается. На самом деле, главное - это доставка трафика к серверу и правильное его перенаправление внутри такового. Этим мы и займёмся здесь, вначале сообразив, как направить трафик с транзитного маршрутизатора к серверу.
Для перенаправления запросов пользователей воспользуемся возможностью маршрутизаторов Cisco Systems избирательно менять следующую точку назначения маршрутизации по произвольным правилам. Есть несколько способов, но мы будем работать с функционалом "route-map". Для перенаправления трафика внутри сервера, на котором работает наш прокси, воспользуемся функционалом IPTables.
Первым делом опишем правилом ACL трафик, который будет отлавливаться и перенаправляться (исключая то, что не должно проводится через прокси):
ip access-list extended acl-pbr-map-universal-proxy
deny ip any 192.168.0.0 0.0.255.255
deny ip any 10.10.0.0 0.0.255.255
permit tcp any any eq 80
exit
deny ip any 192.168.0.0 0.0.255.255
deny ip any 10.10.0.0 0.0.255.255
permit tcp any any eq 80
exit
Далее определяем "маршрутную карту", которую можно будет привязывать к произвольному интерфейсу для отлова целевого трафика и перенаправления на точку, отличную от общей конфигурации (например: 192.168.3.1):
route-map pbr-map-universal permit 10
match ip address acl-pbr-map-universal-proxy
set ip default next-hop 192.168.3.1
exit
match ip address acl-pbr-map-universal-proxy
set ip default next-hop 192.168.3.1
exit
В каждой "маршрутной карте" может быть несколько команд route-map, каждой из которых присвоен порядковый номер. Когда маршрутизатор обрабатывает route-map, он просматривает все команды в соответствии с порядковыми номерами команд.
Если после параметра match идет несколько опций, то к ним применяется логика или, то есть должен совпасть один из перечисленных параметров. Если задано несколько параметров match в отдельных строках, то к ним применяется логика и, то есть должны совпасть все параметры.
Последнее, что остаётся, это привязать "маршрутную карту" к тому интерфейсу, входящий трафик которого мы хотели-бы перенаправить:
int FastEthernet1/1
....
no shutdown
ip policy route-map pbr-map-universal
exit
....
no shutdown
ip policy route-map pbr-map-universal
exit
Теперь, когда запросы перенаправлены на сервер, на котором работает наш "прозрачный" прокси, научим операционную систему перенаправлять его в нужное место.
Разрешаем ОС работать в качестве "шлюза", передавая транзитный трафик:
# cat /etc/sysctl.conf
....
net.ipv4.ip_forward = 1
....
net.ipv4.ip_forward = 1
....
Можно применить параметры изменённого конфигурационного файла целиком:
# sysctl -p
...а можно точечено выполнить команды, немедленно включающие IP forwarding:
# echo 1 > /proc/sys/net/ipv4/ip_forward
Теперь займёмся настройкой IPTables, встроенного в ядро средства управления трафиком.
На всякий случай очистим цепочки PREROUTING таблиц mangle и nat (разумеется, если машина несёт на себе ещё какие-либо сервисы с трансляцией и фильтрацией трафика - этого не следует делать, не разобравшись внимательно с существующими правилами):
# iptables --table mangle --flush PREROUTING
# iptables --table nat --flush PREROUTING
# iptables --table nat --flush PREROUTING
Блокируем прямые обращения на порт доступный только для переадресации:
# iptables --table mangle --append PREROUTING --in-interface eth0 --protocol tcp --dport 3129 --jump DROP
Пробрасываем входящие пакеты, адресованные 80 порту на IP 192.168.1.2 (например) и порт 3129, исключая запросы адресованные непосредственно 80-му порту прокси-сервера:
# iptables --table nat --append PREROUTING --in-interface eth0 --protocol tcp ! --destination 192.168.1.1 --dport 80 --jump DNAT --to-destination 192.168.1.2:3129
Эта конструкция позволяет перенаправить трафик к серверу Squid. Вернётся он, после ответа Squid, в соответствии с таблицей трансляции адресов, в которую заносятся все пакеты, попавшие под действие правила, с обратным изменением целевого адреса и порта.
Проверим, применились ли правила:
# iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 831 packets, 202K bytes)
pkts bytes target prot opt in out source destination
6 288 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3129
....
pkts bytes target prot opt in out source destination
6 288 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3129
....
# iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 742 packets, 37164 bytes)
pkts bytes target prot opt in out source destination
7 336 DNAT tcp -- eth0 * 0.0.0.0/0 !192.168.1.1 tcp dpt:80 to:192.168.0.22:3129
....
pkts bytes target prot opt in out source destination
7 336 DNAT tcp -- eth0 * 0.0.0.0/0 !192.168.1.1 tcp dpt:80 to:192.168.0.22:3129
....
Возможно это неправильно, но я буду включать и выключать фильтрацию и трансляцию адресов при каждом "поднятии" и "опускании" виртуального сетевого интерфейса "eth0:0", в конце концов на нём работают сервисы, нуждающиеся в этом:
# cat /etc/network/interfaces
....
allow-hotplug eth0:0
iface eth0:0 inet static
....
post-up iptables --table mangle --flush PREROUTING
post-up iptables --table nat --flush PREROUTING
post-up iptables --table mangle --append PREROUTING --in-interface eth0 --protocol tcp --dport 3129 --jump DROP
post-up iptables --table nat --append PREROUTING --in-interface eth0 --protocol tcp ! --destination 192.168.1.1 --dport 80 --jump DNAT --to-destination 192.168.1.2:3129
down iptables --table mangle --flush PREROUTING
down iptables --table nat --flush PREROUTING
....
allow-hotplug eth0:0
iface eth0:0 inet static
....
post-up iptables --table mangle --flush PREROUTING
post-up iptables --table nat --flush PREROUTING
post-up iptables --table mangle --append PREROUTING --in-interface eth0 --protocol tcp --dport 3129 --jump DROP
post-up iptables --table nat --append PREROUTING --in-interface eth0 --protocol tcp ! --destination 192.168.1.1 --dport 80 --jump DNAT --to-destination 192.168.1.2:3129
down iptables --table mangle --flush PREROUTING
down iptables --table nat --flush PREROUTING
....
На этом всё. Если прокси-сервер был запущен, то он должен начать принимать и отрабатывать запросы пользователей, которые не будут даже подозревать о том, что выход в интернет у них не прямой.
