From: Alexey Asemov (Alex/AT) <alex@net13.info.>

Эта маленькая статья в первую очередь будет интересна тем, кто работает
в провайдинге или имеет в организации оборудование Cisco (роутеры).

Цель статьи - помочь в построении надежного Web-кеша для пользователей с
использованием только открытого программного обеспечения - Linux и
Squid, а также возможностей оборудования Cisco. Задача не такая
тривиальная, какой могла бы казаться, и содержит несколько подводных
камней.

Данная статья предполагает наличие технической квалификации
применительно к оборудованию Cisco и ОС Linux, очевидные моменты
(необходимость автостарта и перезагрузки конфигурации Squid, общие
настройки Cisco и т.п.) не поясняются.

Что дает нам прозрачное Web-кеширование с использованием Cisco/Squid:

1. Снижение общего объема Web-трафика (из практики - в пределах 10-20%
при 200 пользователях) во внешнюю сеть.

2. Снижение количичества "медленных" Web-запросов к Web-серверам (в
пределах 30-50% при 200 пользователях) во внешнюю сеть, как следствие -
повышенный комфорт для пользователей.

3. Возможность фильтрации Web-трафика средствами Squid. Правда, если кеш
упадет, фильтрация будет отключена, но это нештатная ситуация. В данной
статье фильтрация трафика не рассматривается, однако она тривиальна.

4. Возможность журналирования Web-трафика средствами Squid. Если кеш
упадет - журнал также не будет вестись, но это см. выше. Настройка
журналирования также выходит за рамки данной статьи.

5. Отсутствие необходимости настройки пользователей на прокси. Кроме
того, пользовательское ПО вообще не обнаружит прокси в данном случае,
оно будет считать, что обменивается данными с настоящим сервером.

6. Надежность. Даже в случае падения кеш-сервера пользователи смогут
использовать Web, поскольку Cisco автоматически пустит трафик в обход
кеша.

7. Производительность. Для работы кеша не требуется промежуточной
фильтрации трафика дополнительными устройствами (обычно для этого
ставится сервер-шлюз) - Cisco сделает это самостоятельно.


Наши пререквизиты:

1. Роутер Cisco 1841 с IOS 12.4(11)T4 Advanced IP Services
(C1841-ADVIPSERVICESK9-M). Должно работать и на других роутерных
платформах и версиях IOS с поддержкой WCCP. На Cisco ASA не будет
работать в принципе - там весьма ущербный WCCP. По L3-свитчам
информации, к сожалению, нет.

2. Linux Red Hat Fedora (7/8/9/...) с установленным Squid. В других
версиях Linux настройка также возможна, однако может серьезно
отличаться.

3. Сеть 192.168.15.0/24 - локальная сеть (наш адрес - 192.168.15.254).
Естественно, ваша конфигурация может (и скорее всего будет) отличаться,
но это не принципиально.

4. Сеть 55.66.77.88/30 - сеть провайдера (из нее нам выделен один адрес
в Internet - 55.66.77.90, наш шлюз - 55.66.77.89). Естественно, ваша
конфигурация может (и скорее всего будет) отличаться, но это не
принципиально.

5. Сеть 192.168.16.0/24 - сеть DMZ (в ней находится Web-кеш). Адрес
роутера в данной сети - 192.168.16.254, кеша - 192.168.16.253. Остальные
узлы не принципиальны. Вы можете выбрать любую сеть для связки
роутер-кеш, главное, чтобы она не содержала Web-клиентов, и не была до
этого настроена на кеш-сервере.

6. Мы предполагаем, что кеш-сервер также имеет адрес в локальной сети -
192.168.15.253 (например, для доступа к статистике, чтобы не нагружать
роутер). В вашем случае этого может и не быть - это не обязательно.

7. На роутере должно быть достаточно интерфейсов для подключения: а)
локальной сети; б) сети провайдера; в) сети Web-кеша. Если интерфейсов
не хватает - можно использовать VLAN (субинтерфейсы) и свитч с
поддержкой VLAN, как, например, делает автор данной статьи.

Итак, начнем:

1. Настройка сетевых интерфейсов Cisco.

Предположим, что сетевые интерфейсы Cisco уже настроены следующим
образом (используется NAT, но это не принципиально, названия/номера
интерфейсов также взяты произвольно и могут отличаться):

Интерфейс Internet (Fa0/0):

 interface FastEthernet0/0
 ip address 55.66.77.90 255.255.255.252
 ip nat outside


Интерфейс локальной сети (Fa0/1):

 interface FastEthernet0/1
 ip address 192.168.15.254 255.255.255.0
 ip nat inside


Нам необходимо настроить еще один интерфейс для связи с нашим кешем. Сделаем это.

Интерфейс для связи с кешем (Fa0/2):

 interface FastEthernet0/2
 ip address 192.168.16.254 255.255.255.0
 ip nat inside


Не забудьте включить интерфейс командой no shutdown.


2. Настройки NAT на Cisco.

Предположим, что роутинг и NAT настроены следующим образом (ваша
конфигурация может отличаться, но общие аспекты все равно будут
понятны):

Маршрутизация в Internet (маршрут по умолчанию):

 ip route 0.0.0.0 0.0.0.0 55.66.77.89


NAT:

 ip nat inside source interface FastEthernet0/0 overload


В общем случае конфигурация NAT не требует модификации. Если же у вас
ведется NAT по некоторым спискам доступа (ACL) - не забудьте включить
туда Web-кеш (в нашем случае 192.168.16.253).


3. Настройки ACL на Cisco для интерфейса связи с кешем.

Если вы настраиваете ACL на интерфейсе связи с Web-кешем - вам нужно
будет разрешить протокол GRE (IP GRE) и протокол WCCP (UDP 2048) как в
сторону Web-кеша от роутера, так и со стороны Web-кеша к роутеру. В
принципе, для GRE должно быть достаточно разрешения от роутера к кешу,
но обратное сделать на всякий случай тоже не помешает.

Кроме того, не забудьте разрешить адресу Web-кеша (192.168.16.253 в
нашем случае) выход в Internet.


4. Настройки связи с роутером на Linux.

Предположим, мы имеем уже настроенный интерфейс локальной сети, а также
роутинг в Internet:

Настройки интерфейса локальной сети eth0 на Linux в
/etc/sysconfig/network-scripts/ifcfg-eth0:

 DEVICE=eth0
 BOOTPROTO=static
 ONBOOT=yes
 IPADDR=192.168.15.253
 NETWORK=192.168.15.0
 NETMASK=255.255.255.0


Настройки роутинга в Internet на Linux в
/etc/sysconfig/network-scripts/route-eth0:

 default via 192.168.15.254 proto static


Создаем новый интерфейс для связи с маршрутизатором (физически он должен
быть подключен к необходимому порту маршрутизатора, или входить в
необходимый VLAN, если вы используете конфигурацию с VLAN).

Настройки интерфейса связи с маршрутизатором eth1 на Linux в
/etc/sysconfig/network-scripts/ifcfg-eth1:

 DEVICE=eth1
 BOOTPROTO=static
 ONBOOT=yes
 IPADDR=192.168.16.253
 NETWORK=192.168.16.0
 NETMASK=255.255.255.0


Теперь нам нужно настроить роутинг. "Подводный камень" тут заключается в
том, что весь трафик, идущий от кеш-сервера (Squid) в локальную сеть,
должен _обязательно_ проходить через маршрутизатор. В противном случае
ничего работать не будет.

Для того, чтобы завернуть весь трафик, идущий от адреса кеша в локальную
сеть, на маршрутизатор, нам нужно создать отдельную таблицу
маршрутизации. Добавляем в файл /etc/iproute2/rt_tables следующую
строчку (номер и название таблицы могут отличаться):

 100 service


Мы создали таблицу маршрутизации. Теперь нам необходимо ее заполнить.
Создаем файл /etc/sysconfig/network-scripts/route-eth1.

Настройки роутинга для связки кеш-локальная сеть на Linux в
/etc/sysconfig/network-scripts/route-eth1:

 default via 192.168.16.254 proto static table service


Заметьте - мы использовали в команде имя таблицы маршрутизации,
добавленное нами ранее в файл /etc/iproute2/rt_tables.

Мало заполнить таблицу маршрутизации. Необходимо еще указать (создав
соотвеетствующее правило маршрутизации), чтобы весь трафик от адреса
кеша обрабатывался именно этой таблицей. Это называется policy routing.
Создаем файл /etc/sysconfig/network-scripts/rule-eth1.

Настройки правил policy routing связки кеш-локальная сеть на Linux в
/etc/sysconfig/network-scripts/rule-eth1:

 from 192.168.16.253 table service prio 1000


Таким образом, весь трафик от адреса 192.168.16.253 будет обрабатываться
таблицей маршрутизации service, ранее созданной нами.
Параметр prio (1000) здесь - это приоритет (порядок) правила.
Стандартная маршрутизация имеет приоритеты 32766 и 32767, поэтому наше
правило будет обрабатываться раньше стандартной маршрутизации.

Теперь необходимо перезапустить интерфейс eth1 для того, чтобы все,
созданное нами, вступило в силу. Это можно сделать командами 
ifdown eth1 и ifup eth1.

Для правильной работы WCCP необходимо декапсулировать трафик GRE,
приходящий от маршрутизатора. Пользовательские запросы приходят
инкапсулированными именно в GRE. Это самый сложный момент настройки, так
как ядро системы должно содержать поддержку GRE, кроме того, ОС должна
уметь создавать туннели. В ядро и скрипты Fedora эта поддержка уже
включена. Если вы используете другую версию Linux - постарайтесь найти
документацию по настройке поддержки туннелей GRE для вашей весрии.

Первым делом нужно добавить загрузку модуля gre для будущего интерфейса
gre0 в конфигурацию системы. Для этого добавляем в файл
/etc/modprobe.conf следующую строчку:

 alias gre0 ip_gre


После этого создаем файл конфигурации для интерфейса нашего туннеля GRE
к маршрутизатору.

Настройки интерфейса туннеля GRE gre0 на Linux в
/etc/sysconfig/network-scripts/ifcfg-gre0:

 DEVICE=gre0
 BOOTPROTO=static
 IPADDR=10.7.7.5
 NETMASK=255.255.255.252
 ONBOOT=yes


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

Не забудьте запустить только что созданный туннельный интерфейс командой
ifup gre0.

Теперь все наши интерфейсы готовы к работе. Следующим этапом будет
настройка перенаправления запросов на Squid с помощью IPTables.


5. Настройки IPTables на Linux.

Если вы уже используете IPTables, как файрвол, вам обязательно нужно
разрешить входящий и исходящий трафик, используемый при работе WCCP.
Сделать это можно следующими командами IPTables (я предполагаю, что весь
трафик, кроме разрешаемого, запрещен - ваша конфигурация может
отличаться):

Разрешаем прохождение всего уже проверенного трафика:

 iptables -t filter -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


Разрешаем локальный трафик (в пределах сервера):

 iptables -t filter -A INPUT -i lo -j ACCEPT


Разрешаем весь трафик, пришедший по GRE-туннелю:

 iptables -t filter -A INPUT -i gre0 -j ACCEPT


Разрешаем, собственно, сам протокол GRE со стороны маршрутизатора:

 iptables -t filter -A INPUT -i eth1 -s 192.168.16.254 -p gre -j ACCEPT


Разрешаем WCCP со стороны маршрутизатора:

 iptables -t filter -A INPUT -i eth1 -s 192.168.16.254 -p udp -m udp --dport 2048 -j ACCEPT


Разрешаем исходящий трафик (весь, если будете ограничивать - не забудьте
разрешить вышеперечисленное):

 iptables -t filter -A OUTPUT -j ACCEPT


Теперь нужно перенаправить трафик Web-запросов от роутера на Squid
(сделано для стандартного Webcache - порта 80, для других портов
делается аналогично, однако порты прозрачного прокси Squid тоже должны
быть разными - см. мануал по Squid). Мы будем использовать для этих
целей порт Squid 3180.

 iptables -t nat -A PREROUTING -i gre0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.16.253:3180


Итак, файрвол IPTables настроен. Осталось включить функционал NAT. Для
этого прописываем в файл /etc/sysctl.conf параметр (обычно он уже есть,
достаточно изменить значение):

 net.ipv4.ip_forward = 1


Теперь можно применить данную настройку командой sysctl -p,
однако обычно проще сделать echo 1 > /proc/sys/net/ipv4/ip_forward.

Поздравляем! Настройка связи с маршрутизатором на этом закончена. Теперь
перейдем к настройке Squid.


6. Настраиваем Squid.

Настройка Squid крайне проста. На данном этапе придется поработать с
файлом конфигурации squid.conf. Сначала нужно назначить порт для
прослушивания запросов от маршрутизатора (3180).

 http_port 192.168.16.253:3180 transparent vport=80


vport здесь указывает, какой порт использовать для обращений
к Web-серверу. Если мы хотим добавить кеш для Web-серверов на другом
порту - делаем еще один http_port на другом порту сервера, с
другим vport. Естественно, нужно будет указать этот
дополнительный порт в конфигурации IPTables (об этом уже упоминалось) и
настроить на Cisco, однако в рамках данной статьи мы такую настройку
делать не будем.

Далее говорим Squid, что он будет работать с WCCP версии 2 на
маршрутизаторе. Настройки для WCCP версии 1 отличаются слабо, почерпнуть
их можно из мануалов по Squid и Cisco.

 wccp2_router 192.168.16.254


Заставляем Squid использовать адрес связки с кешем для исходящих соединений.

 tcp_outgoing_address 192.168.16.253


Говорим Squid, что URL могут содержать подчеркивания (иначе можно
нарваться на глюки с некоторыми браузерами):

 allow_underscore on


Слегка увеличиваем ограничение на размер заголовков HTTP (опять же, во
избежание глюков).

 request_header_max_size 128 KB


Отключаем поддержку многократных запросов в одном соединении HTTP/1.1
для Squid (на данный момент наблюдаются проблемы с данной функцией):

 client_persistent_connections off
 server_persistent_connections off


Создаем ACL для наших пользователей и самого сервера.

 acl S_SELF src 127.0.0.1
 acl S_SELF src 192.168.15.253
 acl S_SELF src 192.168.16.253

 acl S_LAN src 192.168.15.0/255.255.255.0


Разрешаем доступ от сервера и от локальной сети, всем остальным - запрещаем.

 http_access allow S_SELF
 http_access allow S_LAN
 http_access deny ALL


Разрешаем получение ответов от любых серверов.

 http_reply_access allow ALL


На этом настройка прозрачного прокси Linux/Squid завершена. Осталась
сущая мелочь - разрешить маршрутизатору передавать запросы на
кеш-сервер.

Не забудьте запустить/перезапустить Squid или перезагрузить его
конфигурацию.

7. Разрешаем перенаправление маршрутизатором запросов к Web-серверам на наш Web-кеш.

Настройка WCCP для некоторых версий IOS может отличаться. Внимательно
прочтите руководство к вашей версии IOS перед началом настройки. Если
ваш IOS требует явного указания версии 2 для WCCP - сделайте это. Если
ваш IOS не поддерживает WCCPv2 - перенастройте Squid на использование
версии 1.

Для того, чтобы маршрутизатор смог перенаправлять запросы от
пользователей нашему кешу, его нужно настроить соответствующим образом.
Во-первых, создаем список доступа для тех, от кого разрешено
перенаправление запросов.

 ip access-list standard WCCP_Redirect
 deny 192.168.15.253
 deny 192.168.16.253
 permit 198.168.15.0 0.0.0.255
 deny any


Здесь находится второй подводный камень. Обратите внимание, что мы
исключили сам Web-кеш из списка перенаправления. В противном случае кеш
может (при некоторых условиях) начать запрашивать Web-страницы сам у
себя.

Настраиваем WCCP на перенаправление с использованием списка доступа.

 ip wccp web-cache redirect-list WCCP_Redirect


И наконец, указываем, что входящие Web-запросы с интерфейса локальной
сети (Fa0/1) необходимо перенаправлять на Web-кеш.

 interface FastEthernet0/1
 ip wccp web-cache redirect in


Далее можно посмотреть журнал доступа Web-кеша и убедиться в том, что
перенаправление работает.

На этом нашу первоначальную настройку прозрачного Web-кеша с
использованием Cisco/WCCP/Linux/Squid можно считать законченной!

Данная схема была опробована в двух сетях, и функционирует крайне стабильно.

Жду пожеланий/дополнений/замечаний.