UMGUM.COM (лучше) 

Cisco route-map + IPTables ( Перенаправление трафика к Squid3 в качестве прозрачного кеширующего прокси-сервера. )

10 декабря 2011  (обновлено 31 января 2015)

OS: Cisco System IOS 12.* and Debian GNU/Linux Squeeze.

Итак, в предыдущих заметках мы настроили "прозрачный" прокси-сервер, отталкиваясь от конфигурации обычного, прямого подключения, прокси. Заметно, что в целом настройка их не особо отличается. На самом деле, главное - это доставка трафика к серверу и правильное его перенаправление внутри такового. Этим мы и займёмся здесь, вначале сообразив, как направить трафик с транзитного маршрутизатора к серверу.

Для перенаправления запросов пользователей воспользуемся возможностью маршрутизаторов 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

Далее определяем "маршрутную карту", которую можно будет привязывать к произвольному интерфейсу для отлова целевого трафика и перенаправления на точку, отличную от общей конфигурации (например: 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

В каждой "маршрутной карте" может быть несколько команд route-map, каждой из которых присвоен порядковый номер. Когда маршрутизатор обрабатывает route-map, он просматривает все команды в соответствии с порядковыми номерами команд.
Если после параметра match идет несколько опций, то к ним применяется логика или, то есть должен совпасть один из перечисленных параметров. Если задано несколько параметров match в отдельных строках, то к ним применяется логика и, то есть должны совпасть все параметры.


Последнее, что остаётся, это привязать "маршрутную карту" к тому интерфейсу, входящий трафик которого мы хотели-бы перенаправить:

int FastEthernet1/1
....
  no shutdown
  ip policy route-map pbr-map-universal
exit

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

Разрешаем ОС работать в качестве "шлюза", передавая транзитный трафик:

# cat /etc/sysctl.conf

....
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 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
....

# 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
....

Возможно это неправильно, но я буду включать и выключать фильтрацию и трансляцию адресов при каждом "поднятии" и "опускании" виртуального сетевого интерфейса "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
....

На этом всё. Если прокси-сервер был запущен, то он должен начать принимать и отрабатывать запросы пользователей, которые не будут даже подозревать о том, что выход в интернет у них не прямой.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )