Wccp что это
interface FastEthernet0/0.400
ip flow egress
interface FastEthernet0/1
ip flow ingress
ip flow egress
Fa0/0.400 — интерфейс, смотрящий на Squid
Fa0/1 — интерфейс, смотрящий в локалку
ip wccp web-cache
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
WCCP Clients Visible:
172.30.30.3
WCCP Clients NOT Visible:
-none-
sh ip wccp web-cache detail
WCCP Client information:
WCCP Client ID: 172.30.30.3
Protocol Version: 2.0
State: Usable
Initial Hash Info: 00000000000000000000000000000000
00000000000000000000000000000000
Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Hash Allotment: 256 (100.00%)
Packets s/w Redirected: 556013
Connect Time: 03:44:07
Bypassed Packets
Process: 0
Fast: 0
CEF: 0
Errors: 0
и
-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
иногда тоже не мешает, ибо настройки серевера обычно не просты.
Web Cache Communication Protocol
Web Cache Communication Protocol (WCCP) — разработанный компанией Cisco протокол перенаправления контента. Предоставляет механизм перенаправления потоков трафика в реальном времени. Имеет встроенные масштабирование, балансировку нагрузки, отказоустойчивость. Cisco IOS Release 12.1 и поздние разрешают использовать либо версию 1, либо версию 2 протокола.
WCCP позволяет использовать Cisco Cache Engines (или другие устройства хранения кэша с работающим WCCP) для локализации источника web-трафика в сети. Такие устройства дают возможность выполнять запросы контента локально. Локализация трафика снижает стоимость передачи и время скачивания.
Версии протокола
- Только один роутер обслуживает группу устройств.
- Поддерживает только HTTP (TCP порт 80) перенаправление трафика.
- Использует протокол GRE для предотвращения модификации пакетов.
- Роутеры и устройства хранения кэша соединяются друг с другом по протоколу UDP, порт 2048.
- Позволяет использовать до 32 роутеров (серверов WCCP).
- Поддерживает до 32 устройств/ускорителей (клиентов WCCP)
- Поддерживает любые IP и TCP протоколы.
- Поддерживает до 256 сервиc-групп (групп обслуживания).
- Добавлено шифрование с использованием хэша MD5.
Основные функции WCCP
Регистрация.
- Ускоритель или устройство — клиент WCCP.
- Регистрирует WCCP сервис (0-255) сообщением «Я здесь» если приложение работает.
- Регистрирует заявивших о себе клиентов WCCP в сервис-группе, предоставляет уведомления присутствия, запрашивает интересующий трафик.
- Передает «Я здесь» каждые 10 секунд.
- Роутер — WCCP сервер.
- Принимает регистрацию сервис-групп (0-255).
- Подтверждает получение «Я здесь» сообщением «Я тебя вижу».
- Ждет тридцать секунд прежде чем объявить устройство вышедшим из строя.
- Докладывает устройствам о других устройствах.
- Наименование роутера — высший IP интерфейса или высший IP петли если хоть одна существует.
- Перенаправляет трафик на устройство.
- Выбирает устройства в группе.
- Хэширует 256 потоков.
- Маскирует 128 потоков семибитной маской, создаваемой по IP/Port источника или назначения.
Редирект от роутера к устройству хранения кэша.
- Механиз WCCP GRE создает туннель от роутера до локального или удаленного устройства.
- Механизм перенаправления WCCP L2 перезаписывает MAC адреса в пакетах до локального устройства.
- Списки редиректов позволяют роутеру разрешать/запрещать трафик до пункта назначения.
Возврат от устройства хранения кэша до роутера.
- WCCP GRE возврат.
- WCCP L2 возврат.
- Устройство может возвращать трафик любым другим путём, включая роутинг.
Продукты, поддерживающие WCCP
- Интернет-протоколы
- Прокси-серверы
Wccp
Web Cache Communication Protocol (WCCP) — разработанный компанией Cisco протокол перенаправления контента. Предоставляет механизм перенаправления потоков траффика в реальном времени. Имеет встроенные масштабирование, балансировку нагрузки, отказоустойчивость. Cisco IOS Release 12.1 и поздние разрешают использовать либо версию 1, либо версию 2 протокола. WCCP позволяет использовать Cisco Cache Engines (или другие устройства хранения кэша с работающим WCCP) для локализации источника web-траффика в сети. Такие устройства дают возможность выполнять запросы контента локально. Локализация траффика снижает стоимость передачи и время скачивания.
Версии протокола
- Только один роутер обслуживает группу устройств.
- Поддерживает только HTTP (TCP порт 80) перенапраление траффика.
- Использует протокол GRE для преотвращения модицикации пакетов.
- Роутеры и устройства хранения кэша соединяются друг с другом по протоколу UDP, порт 2048.
- Позволяет использовать до 32 роутеров (серверов WCCP).
- Поддерживает до 32 устройств/ускорителей (клиентов WCCP)
- Поддерживает любые IP и TCP протоколы.
- Поддерживает до 256 сервиc-групп (групп обслуживания).
- Добавлено шифрование с использованием хэша MD5.
Основные функции WCCP
Регистрация.
- Ускоритель или устройство – клиент WCCP.
- Регистрирует WCCP сервис (0-255) соощением “Я здесь” если приложение работает.
- Регистрирует заявивших о себе клиентов WCCP в сервис-группе, предоставляет уведомления присутствия, запршивает интересующий траффик.
- Передает “Я здесь” каждые 10 секунд.
- Роутер — WCCP сервер.
- Принимает регистрацию сервис-групп (0-255).
- Подтверждает получение “Я здесь” сообщением “Я тебя вижу”.
- Ждет тридцать секунд прежде чем объявить устройство вышедшим из строя.
- Докладывает устройствам о других устройствах.
- Наименование роутера – высший IP интерфейса или высший IP петли если хоть одна существует.
- Перенапрвляет траффик на устройство.
- Выбирает устрофства в группе.
- Хэширует 256 потоков.
- Маскирует 128 потоков сеимибитной маской, создаваемой по IP/Port источника или назначения.
Редирект от роутера к устройству хранения кэша.
- Механиз WCCP GRE создает туннель от роутера до локального или удаленного устройства.
- Механизм перенаправления WCCP L2 перезаписывает MAC адреса в пакетах до локального устройства.
- Списки редиректов позволяют роутеру разрешать/запрещать траффик до пункта назначения.
Возврат от устройства хранения кэша до роутера.
- WCCP GRE возврат.
- WCCP L2 возврат.
- Устройство может возвращать трафиик любм другим путем, включая роутинг.
Wikimedia Foundation . 2010 .
Еще одна статья о кэшировании веб-трафика
Про организацию прозрачного кэширования веб-трафика с использованием протокола WCCP написано много, в том числе есть хорошая статья на хабре. Обычно в этих статьях рассматривается схема, подобная изображенной на рисунке слева.
На первый взгляд, решение обладает сплошными достоинствами: реализация несложна, кэширование выполняется абсолютно прозрачно для пользователей, при отказе прокси-сервера запросы автоматически будут перенаправлены напрямую.
Но всегда ли внедрение WCCP проходит гладко? И если нет, как бороться с возникающими проблемами?
Например, практически во всех статьях упоминается, что сервер кэширования должен находиться в том же сегменте, что и пользователи, но причины этого не уточняются. А как быть, если политика безопасности требует, чтобы все серверы находились в демилитаризованной зоне и были защищены межсетевым экраном (МЭ)?
Недавно пришлось столкнуться с подобным требованием при установке сервера кэширования в сети оператора связи, упрощенная схема которой изображена на заглавном рисунке справа.
Если читателям интересно, какие проблемы встречаются при реализации подобных схем, и как можно обойти ограничения — добро пожаловать.
Теория — стандарты и особенности реализации
Для начала немного теории. Протокол WCCP предназначен для перенаправления трафика (не только веб) в реальном времени. Изначально протокол был разработан компанией Cisco, потом стал открытым стандартом, использующимся большинством вендоров.
На сегодняшний день актуальной является версия 2, находящаяся в статусе Internet-Draft и описываемая документом draft-mclaggan-wccp-v2rev1-00.
Остановимся на нескольких важных моментах работы этого протокола (см. рисунок).
- Если сервер готов обрабатывать запросы на кэширование трафика, он посылает сообщения WCCP2_HERE_I_AM.
- Маршрутизатор отправляет серверу сообщение WCCP2_I_SEE_YOU, содержащее сведения о настройках, в частности, поле “Receive ID”.
- Сервер в ответ посылает еще одно сообщение WCCP2_HERE_I_AM, в котором содержится поле “Receive ID” с тем же значением, что и на предыдущем шаге, тем самым подтверждая, что готов работать совместно с маршрутизатором.
- Маршрутизатор, получив такое сообщение, понимает, что с этого момента запросы пользователей к веб-сайтам следует перенаправлять на сервер кэширования.
Система готова к работе. Процесс обмена сообщениями WCCP2_HERE_I_AM и WCCP2_I_SEE_YOU повторяется периодически (по умолчанию — раз в 10 секунд), и если маршрутизатор не получает ответа от сервера кэширования, последний исключается из процесса.
В реальности протокол несколько сложнее, он предусматривает аутентификацию, разные алгоритмы перенаправления и т. п., но мы сознательно опустим подробности, неважные для дальнейшего понимания. Интересующиеся читатели могут найти их в соответствующем драфте, ссылка на который приведена выше.Такая реализация способствует отказоустойчивости решения — если сервер кэширования откажет и перестанет отправлять сообщения WCCP2_HERE_I_AM, маршрутизатор перестанет пытаться перенаправлять пакеты и начнет отправлять их в Интернет напрямую. После восстановления сервиса процесс обмена сообщениями WCCP2_HERE_I_AM/WCCP2_I_SEE_YOU повторится, и схема кэширования снова начнет работать.
Для пользователей такой отказ либо совсем незаметен, либо это может выглядеть как однократное сообщение «Unable to connect», которое пропадет после повторной загрузки страницы в браузере.
В Wireshark процесс обмена сообщениями WCCP выглядит так, как изображено на следующем рисунке. Обратите внимание на столбец Time. Образ трафика взят с реально существующей системы, поэтому IP-адреса приведены в усеченном виде в целях безопасности.
Посмотрим, что происходит при попытке клиента получить данные от веб-сервера. Для наглядности присвоим хостам конкретные IP-адреса, воспользовавшись специальными диапазонами, выделенными для использования в примерах, а для простоты пока исключим из рассмотрения всю лишнюю функциональность (NAT, межсетевое экранирование и т. п.).
- Пользовательский браузер инициирует TCP-сессию, отправляя пакет с SRC IP 198.51.100.150, DST IP 192.0.2.20, DST TCP port 80, флагом TCP SYN.
- Маршрутизатор, получив такой пакет, не отправляет его дальше в Интернет, а упаковывает целиком в пакет GRE и отправляет серверу кэширования. Пакет GRE имеет, соответственно, SRC IP 192.51.100.1 и DST IP 198.51.100.100. В Wireshark это выглядит, как показано на следующем рисунке.
- Сервер кэширования, получив такой пакет, в первую очередь принимает решение, будет ли он этот пакет обрабатывать. Если нет — пакет отправляется обратно маршрутизатору для нормального форвардинга через тот же самый GRE-туннель, и алгоритм завершается. Если да, то сервер переходит к следующему шагу.
- Сервер кэширования от своего имени устанавливает соединение с веб-сервером, для чего отправляет пакет с SRC IP 198.51.100.100, DST IP 192.0.2.20, DST TCP port 80, флагом TCP SYN.
- В ответ веб-сервер отправляет пакет с SRC IP 192.0.2.20, SRC TCP port 80, DST IP 198.51.100.100, флагами TCP SYN/ACK, т. е. пока все идет в соответствии с обычным началом TCP-сессии по алгоритму three-way handshake.
- Сервер кэширования, получив ответ от веб-сервера, делает два действия:
- отправляет веб-серверу пакет с SRC IP 198.51.100.100, DST IP 192.0.2.20, DST TCP port 80, флагом ACK, т. е. продолжает нормальную TCP-сессию, которая для веб-сервера выглядит так, как будто к нему обратился обычный клиент с IP–адресом 198.51.100.100.
- отправляет веб-клиенту пакет с SRC IP 192.0.2.20, SRC TCP port 80, DST IP 198.51.100.150, флагами TCP SYN/ACK, т. е. для клиента ситуация выглядит так, как будто веб-сервер ответил ему напрямую. Запомним этот момент, он является ключевым для дальнейшего понимания.
- Итак, у нас имеется две установленные TCP-сессии, одна между клиентом и сервером кэширования, другая — между сервером кэширования и веб-сервером. Сервер кэширования получает контент с веб-сервера обычным способом, транслирует клиенту, попутно сохраняя его в памяти или (и) на диске.
При последующих обращениях к тому же контенту сервер кэширования, при соблюдении определенных условий, сможет не выкачивать его веб-сервера повторно, а отдавать веб-клиенту самостоятельно.
Описанный алгоритм схематически изображен на рисунке.
- Пакеты внутри GRE-туннеля отправляются преимущественно от маршрутизатора к серверу кэширования (за исключением ситуации, когда сервер кэширования не может обработать пакет, и отправляет его маршрутизатору обратно для нормального форвардинга).
- В обратную сторону, т. е. от сервера кэширования к веб-клиенту, пакеты направляются напрямую, вообще минуя маршрутизатор.
- Сервер кэширования устанавливает для пакетов в сторону веб-клиента не свой адрес, а адрес веб-сайта, к которому сделан запрос.
Такая реализация протокола значительно снижает загрузку маршрутизатора, т. к. ему приходится перенаправлять только трафик от веб-клиента к веб-серверу, объем которого обычно небольшой. Трафик от веб-сервера, объем которого обычно значительный, не подвергается никакой сложной обработке — он просто маршрутизируется.
Но такая реализация создает ассиметричный трафик, который, в свою очередь, порождает сложности, рассмотренные в следующем разделе.
Практика — борьба с маршрутизаторами и межсетевыми экранами
Модифицируем предыдущую схему — поместим сервер кэширования за межсетевой экран:
Будем считать, что мы используем популярное оборудование — маршрутизатор Cisco с ПО Cisco IOS версии 12.3 и выше, межсетевой экран Cisco ASA с ПО версии 8.2 и выше, сервер кэширования на основе Linux (дистрибутив RHEL или CentOS), ПО кэширования Squid.
Как в этом случае все настроить? Предположим, что базовая функциональность уже настроена, т. е. веб-клиент и сервер кэширования в состоянии обращаться к ресурсам в Интернете. Начнем с настройки WCCP на Cisco.Проведем подготовительную работу, для чего создадим два списка доступа:
ip access-list standard l_wccp_service permit 203.0.113.100 ip access-list extended l_wccp_redirect permit tcp host 198.51.100.150 any eq wwwПервый определяет, от каких кэширующих серверов разрешено принимать сообщения WCCP2_HERE_I_AM.
Второй определяет, какой трафик необходимо заворачивать на сервер кэширования.Настроим WCCP и включим его на интерфейсе, смотрящем в сторону внутренних пользователей, т. е. имеющем адрес 198.51.100.1. Для определенности пусть это будет FastEthernet0/0):
ip wccp web-cache redirect-list l_wccp_redirect group-list l_wccp_service interface FastEthernet0/0 ip wccp web-cache redirect inНа межсетевом экране разрешим обмен пакетами WCCP и GRE между маршрутизатором и сервером кэширования.
access-list l_wccp extended permit gre host 198.51.100.1 host 203.0.113.100 access-list l_wccp extended permit udp host 198.51.100.1 host 203.0.113.100 access-group l_wccp in interface outsideТеперь настроим сервер кэширования. Для начала установим и настроим squid, для чего с помощью любимого текстового редактора откроем файл /etc/squid/squid.conf и убедимся, что он содержит следующие строки:
# /etc/squid/squid.conf http_port 3128 transparent wccp2_router 198.51.100.1 wccp2_forwarding_method 1 wccp2_return_method 1 wccp2_assignment_method hash wccp2_service standard 0Cоздадим туннельный интерфейс, для чего опять же в любимом редакторе создадим файл /etc/sysconfig/network-scripts/ifcfg-tun0 со следующим содержимым:
# /etc/sysconfig/network-scripts/ifcfg-tun0 DEVICE=tun0 BOOTPROTO=none ONBOOT=yes TYPE=GRE PEER_OUTER_IPADDR=198.51.100.1 PEER_INNER_IPADDR=192.168.168.1 MY_INNER_IPADDR=192.168.168.2IP-адреса PEER_INNER_IPADDR и MY_INNER_IPADDR могут быть абсолютно любыми — через этот туннель нормальным способом ничего маршрутизироваться не будет. Вместо этого весь приходящий в него TCP-трафик с DST port 80 будет заворачиваться на squid с использованием iptables. В предположении, что squid отвечает на порту 3128, поднимем туннельный интерфейс и завернем нужный трафик на squid:
/etc/sysconfig/network-scripts/ifup tun0 iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 203.0.113.100:3128 /etc/init.d/iptables saveПроверим, что сервер кэширования зарегистрировался на маршрутизаторе:
cisco# show ip wccp Global WCCP information: Router information: Router Identifier: 198.51.100.1 Protocol Version: 2.0 Service Identifier: web-cache Number of Service Group Clients: 1 Number of Service Group Routers: 1 Total Packets s/w Redirected: 175623 Process: 0 Fast: 0 CEF: 175623 Redirect access-list: l_wccp_redirect Total Packets Denied Redirect: 113892411 Total Packets Unassigned: 20590 Group access-list: l_wccp_service Total Messages Denied to Group: 26558 Total Authentication failures: 0 Total Bypassed Packets Received: 0Здесь нас может ожидать неприятная засада: у маршрутизатора обычно бывает несколько интерфейсов с разными IP-адресами. И ничто не мешает ему отправлять пакеты WCCP2_I_SEE_YOU с SRC IP одного интерфейса, а пакеты GRE — с SRC IP другого интерфейса.
В некоторых, но далеко не во всех версиях встроенного программного обеспечения маршрутизаторов Cisco IOS предусмотрена команда “ ip wccp source-interface”, которая позволяет жестко задать интерфейс, IP-адрес которого будет использоваться в качестве SRC IP для всех пакетов, имеющих отношение к подсистеме WCCP.Если ваш маршрутизатор поддерживает такую команду, вам повезло. Выполните ее:
ip wccp source-interface FastEthernet 0/0Если же в ответ на такую команду маршрутизатор выдаст что-то вроде “Syntax error”, поступаем следующим образом — запускаем на МЭ диагностику, а на сервере кэширования какой-нибудь сетевой анализатор (хотя бы tcpdump) и выясняем, с каких IP-адресов приходят пакеты WCCP, и с каких — пакеты GRE.
Далее в настройках squid прописываем первый IP-адрес, в настройках туннельного интерфейса и iptables — второй. Модифицируем соответствующим образом списки доступа на МЭ.
Чтобы IP-адрес, с которого приходят пакеты WCCP, не ездил между интерфейсами при последующих перенастройках маршрутизатора, можно завести на последнем loopback-интерфейс. В этом случае протокол WCCP будет использовать для отправки своих пакетов наибольший IP-адрес среди всех loopback-интерфейсов.
interface lo0 ip address 198.51.100.20 255.255.255.255Проверим, что перенаправление работает. Для начала убедимся, что счетчики пакетов в списках доступа, созданных ранее, растут:
cisco# show access-list l_wccp_redirect Extended IP access list l_wccp_redirect 10 permit tcp host 198.51.100.150 any eq www (2399 matches)Потом откроем произвольную веб-страницу в браузере клиентской машины. И наверняка ничего у нас не получится. При попытках разобраться мы наверняка найдем сообщения в логах межсетевого экрана примерно такого вида:
%ASA-4-313004: Denied ICMP type=0, from 192.0.2.20 on interface dmz to 198.51.100.150: no matching sessionЕсли мы попробуем погуглить, первая же ссылка скажет нам что-нибудь про ассиметричный роутинг. Разберемся, что это означает.
Межсетевой экран Cisco ASA представляет собой устройство, работающее в режиме Stateful Inspection, т. е. для того чтобы пропустить через себя пакет с флагами TCP SYN/ACK от сервера кэширования к клиенту, необходимо, чтобы до этого соответствующий пакет с флагом TCP SYN от клиента к веб-сайту прошел в прямом направлении через тот же самый МЭ.В этом случае МЭ поймет, что клиент инициировал TCP-сессию, создаст соответствующие внутренние структуры и начнет правильно отслеживать состояние этой TCP-сессии.
В нашей схеме инициирующий SYN-пакет проходит через МЭ а) внутри GRE-туннеля и б) «как бы не в том направлении».
Соответственно, МЭ не заводит TCP-сессию в своей таблице соединений и не может понять, что сессия началась, и ее пакеты надо пропускать.Что в такой ситуации делать? Если подключить сервер кэширования в обход МЭ никак невозможно, остается только отключить для пакетов, приходящих со стороны DMZ, проверку на наличие открытой TCP-сессии.
В Cisco ASA функция отключения проверки называется TCP bypass. Функция имеет ограничения:
- Не работает на Cisco ASA с ПО версии младше 8.2.
- Неизвестен (по крайней мере, нам не удалось найти) способ организации на одном и том же МЭ модели Cisco ASA одновременно и клиентской зоны, и DMZ — предсказуемо не работают трансляции IP-адресов.
Итак, включаем функцию TCP bypass:
access-list l_bypass extended permit tcp any eq www host 198.51.100.150 class-map c_bypass match access-list l_bypass policy-map p_bypass class c_bypass set connection advanced-options tcp-state-bypass service-policy p_bypass interface dmzВ список доступа l_bypass надо поместить диапазон клиентских IP-адресов.
Вот теперь все должно работать. По крайней мере, у нас заработало.
Заключение
- не пренебрегайте стандартами и описаниями работы протокола;
- не понимаете, что происходит — не поленитесь, подключите сетевой анализатор.
Удачного тестирования и внедрения! И пусть отныне и всегда ваши каналы транспортируют как можно меньше лишнего трафика.