The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Cisco, WCCP, Linux и Squid - надежный прозрачный Web-кеш своими руками (cisco wccp squid proxy linux fedora redhat transparent)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: 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 можно считать законченной! Данная схема была опробована в двух сетях, и функционирует крайне стабильно. Жду пожеланий/дополнений/замечаний.

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, bytestore, 16:51, 04/07/2008 [ответить] [смотреть все]
  • +/
    Да у меня тоже это работает уже 2 год
    правда у меня сам прокси висит всего на одном интерфейсе в локалке
    единственное что так и не проверил,
    циска будет по нетфлоу сливать трафик уже прошедший через сквид (тоесть ошибочно думать что это инет а он взят из кэша) или реальный?
    и еще удобно сделать много проксей одинаковых будет автоматическая рапределение нагрузки
     
     
  • 2.5, AlexAT, 14:26, 24/12/2008 [^] [ответить] [смотреть все]
  • +/
    Я сливаю так (все сливается корректно)

    ---

    interface FastEthernet0/0.400
    ip flow egress

    interface FastEthernet0/1
    ip flow ingress
    ip flow egress

    ---

    Fa0/0.400 - интерфейс, смотрящий на Squid
    Fa0/1 - интерфейс, смотрящий в локалку

    Кстати в IOS до 12.4(21) работало по другому - надо было сливать с интерфейсов локалки и внешки, сквидовый не трогать, при этом попадал еще и трафик, идущий на сквид. В 12.4(21) изменилось к лучшему.

     
  • 1.2, telsek, 15:48, 08/07/2008 [ответить] [смотреть все]
  • +/
    IOS 12 2 11 WCCP включается двумя командами Fa 0 1 - смотрит наружу ip wccp ... весь текст скрыт [показать]
     
  • 1.3, jetfox, 16:30, 28/07/2008 [ответить] [смотреть все]  
  • +/
    Единственная проблема, что приходится сильно патчить squid для "нестандартных" заголовков в HTTP запросах
     
  • 1.4, dk, 18:40, 13/08/2008 [ответить] [смотреть все]  
  • +/
    Статья класно написана, за сие автору респект )) Только скажите а как быть с https ??
     
  • 1.6, Filosof, 16:57, 10/04/2009 [ответить] [смотреть все]  
  • +/
    Fedora 7 squid 2.6 stable 12
    http_port 192.168.16.253:3180 transparent vport=80 -  ne pozvolit, ibo "vport" -> web accel mode a nam nado transperent proxy. bez vport squid startanul, shas proverui kak budit rabotat'
     
  • 1.7, Filosof, 21:19, 15/04/2009 [ответить] [смотреть все]  
  • +/
    всёработает, только еще неплохо просмотреть параметры файрвола - ассесс листов
    незабудьте явно указать 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 - добавить единичку, там где я - иначе может оказаться закрыто файрволом, в остальных кстати тоже.

     
  • 1.8, Timofey, 16:29, 02/09/2009 [ответить] [смотреть все]  
  • +/
    Спасибо, заработало.
    RHEL  2.6.18-128.el5
    Squid Cache: Version 2.6.STABLE21
     
  • 1.9, BLiN, 18:51, 26/10/2009 [ответить] [смотреть все]  
  • +/
    Подскажите, пожалуйста, на Ubuntu сервер и Squid 2.7.STABLE3 кто нибуть пробовал? У меня squid не хочет слушать указанный порт на интерфейсе который смотрит на циску, все остальное вроде заработало.
    То есть я вижу что циска редиректит пакеты и отрабатывает днат на линуксе, однако в логах сквида тишина. Помогите плиз.
     
  • 1.10, Gorokhov, 23:21, 28/03/2010 [ответить] [смотреть все]  
  • +/
    LINUX - отключить запрет спуфинга !!
    echo 1 > /proc/sys/net/ipv4/ip_forward
    echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter
    echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
    echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
    echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter
    echo 0 > /proc/sys/net/ipv4/conf/wccp0/rp_filter

    Ну и так далее

     
  • 1.11, Ak, 21:27, 03/04/2010 [ответить] [смотреть все]  
  • +/
    Коллеги, прошу помощи - не получается настроить GRE туннель на Fedora. Не видет cisco squid по WCCP
     
  • 1.12, Alex, 09:38, 04/04/2010 [ответить] [смотреть все]  
  • +/
    Не забудьте открыть необходимые порты. И настроить необходимые правила в iptables (ну и echo 1 > /proc/sys/net/ipv4/ip_forward не забыть).

    Для начала вообще рекомендую на тест сделать

    iptables -P INPUT ACCEPT
    iptables -F INPUT
    iptables -P OUTPUT ACCEPT
    iptables -F OUTPUT
    iptables -P FORWARD ACCEPT
    iptables -F FORWARD

    + настроить в nat-таблице правило.

     
  • 1.13, LJ, 10:55, 20/04/2012 [ответить] [смотреть все]  
  • +/
    2. Снижение количичества

    Буква лишняя.

     
  • 1.14, Alex, 11:07, 07/06/2012 [ответить] [смотреть все]  
  • +/
    Прошу помощи с настройкой этого зверя!
    Чел, который нам все это настраивал не доступен. Сам я не могу перенастроить этот роутер. Переворошил кучу информации, но все равно не рискую. Пока работает, но вижу, что хромает на обе ноги.
    Есть два сервера (win2003). Первый - прокси (WinGate) и webapp через Cisco VPN client. Второй - App.
    Нужно:
    Все входящие соединения из одной подсети перенаправить через прокси.
    И, если это возможно, объяснить/разжевать.

    Заранее благодарю.

     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:





      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor