Ключевые слова:cisco, wccp, squid, proxy, linux, fedora, redhat, transparent, (найти похожие документы)
From: Alexey Asemov (Alex/AT) <alex@net13.info.>
Newsgroups: email
Date: Mon, 4 Jun 2008 14:31:37 +0000 (UTC)
Subject: Cisco, WCCP, Linux и Squid - надежный прозрачный Web-кеш своими руками
Эта маленькая статья в первую очередь будет интересна тем, кто работает
в провайдинге или имеет в организации оборудование 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 можно считать законченной!
Данная схема была опробована в двух сетях, и функционирует крайне стабильно.
Жду пожеланий/дополнений/замечаний.
Да у меня тоже это работает уже 2 год
правда у меня сам прокси висит всего на одном интерфейсе в локалке
единственное что так и не проверил,
циска будет по нетфлоу сливать трафик уже прошедший через сквид (тоесть ошибочно думать что это инет а он взят из кэша) или реальный?
и еще удобно сделать много проксей одинаковых будет автоматическая рапределение нагрузки
interface FastEthernet0/1
ip flow ingress
ip flow egress
---
Fa0/0.400 - интерфейс, смотрящий на Squid
Fa0/1 - интерфейс, смотрящий в локалку
Кстати в IOS до 12.4(21) работало по другому - надо было сливать с интерфейсов локалки и внешки, сквидовый не трогать, при этом попадал еще и трафик, идущий на сквид. В 12.4(21) изменилось к лучшему.
interface FastEthernet0/1
description Internet
ip address 200.0.1.79 255.255.240.0
no ip redirects
ip wccp web-cache redirect out
duplex auto
speed auto
Диагностика:
sh ip wccp web-cache view
WCCP Routers Informed of:
200.0.1.79
всёработает, только еще неплохо просмотреть параметры файрвола - ассесс листов
незабудьте явно указать cisco
access-list ХХХ permit ip 192.168.16.0 0.0.0.255 any
если используете их. иначе может не пропускать, но нечего не говорить.
и
-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 3128 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp --dport 631 -j ACCEPT
иногда тоже не мешает, ибо настройки серевера обычно не просты.
К тому-же не забудте iptables -t filter -A INPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT - добавить единичку, там где я - иначе может оказаться закрыто файрволом, в остальных кстати тоже.
Подскажите, пожалуйста, на Ubuntu сервер и Squid 2.7.STABLE3 кто нибуть пробовал? У меня squid не хочет слушать указанный порт на интерфейсе который смотрит на циску, все остальное вроде заработало.
То есть я вижу что циска редиректит пакеты и отрабатывает днат на линуксе, однако в логах сквида тишина. Помогите плиз.
Прошу помощи с настройкой этого зверя!
Чел, который нам все это настраивал не доступен. Сам я не могу перенастроить этот роутер. Переворошил кучу информации, но все равно не рискую. Пока работает, но вижу, что хромает на обе ноги.
Есть два сервера (win2003). Первый - прокси (WinGate) и webapp через Cisco VPN client. Второй - App.
Нужно:
Все входящие соединения из одной подсети перенаправить через прокси.
И, если это возможно, объяснить/разжевать.
