SQUID Часто Задаваемые Вопросы (FAQ): Прозрачное проксирование/кеширование

Наши партнеры

Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

17. Прозрачное кеширование/проксирование

Как мне заставить броузеры пользователей использовать мой кеш без настройки броузеров на использование прокси?

Прежде всего, обязательно прочитайте полные комментарии в файле squid.conf! Это единственный полный источник информации о настройке. Данная инструкция верна на дату написания (Июль 1999.)

Чтобы работало прозрачное кеширование, необходимо сделать четыре следующих шага:

Откомпилирровать и запустить версию Squid, которая принимает соединения для других адресов. Для некоторых операционных систем вам потребуется отконфигурировать и собрать версию Squid, которая сможет распознать "чужие" (hijacked) соединения и различать адреса назначения. Для Linux это скорее всего будет работать автотатически. Для *BSD-систем вам возможно понадобится пересобрать squid с опцией --enable-ipf-transparent. (Не забывайте делать make clean, если прежняя конфигурация не содержала этой опции или корректные установки не будут присутствовать.)
Настроить Squid на прием и обработку соединений. Вам следует изменить параметры настройки Squid, чтобы он мог распознать "чужие" (hijacked) соединения и различать адреса назначения. Вот необходимые установки для squid.conf:
```
http_port 8080
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy  on
httpd_accel_uses_host_header on
```
Настроить ваш кеш-сервер на прием пакетов. Вам необходимо настроить ваш хост с кешем на прием перенаправленых пакетов с любого IP-адреса по порту 80 и доставляьт его вашему кеш-приложению. Это обычно делается при помощи поддержки IP filtering/forwarding, встроенной в ядро. В linux это называется iptables (kernel 2.4.x), ipchains (2.2.x) или ipfwadm (2.0.x). На FreeBSD это называется ipfw. Другие BSD-системы могут использовать ip filter или ipnat. На большинстве систем это может потребовать пересборки ядра или добавления новых подгружаемых модулей ядра.
Направить пакеты к вашему кеш-серверу. Есть несколько путей сделать это. Если ваша машина с прокси стоит на пути прохождения пакета (т.е. это маршрутизатор между пользователями вашего прокси и Интернет), то можете не беспокоиться о этом шаге. Так бывает, если вы установили Squid на машину с файерволом или на UNIX-роутер. Если кеш не является естественной частью пути соединений, то вам нужно заворачивать пакеты с нормального пути на ваш хост с кешем, используя роутер или свитч. Возможно вы сможете сделать это при помощи Cisco, используя ее "route maps" (зависит от версии вашей IOS). Вы можете также использовать свитч 4-го уровня типа Alteon ACE-director или Foundry Networks ServerIron. Наконец, вы можете использовать другой продукт типа router/load-balancer или возможности маршрутизации сервера доступа.

Замечания:

http_port 8080 в этом примере предполагает, что вы будете перенаправлять пакеты, приходящие на порт 80, на порт 8080 на вашей машине с кешем. Если ваш Squid запущен на порту 3128 (к примеру), вы можете оставить http_port 3128 без изменений и перенаправлять пакеты на этот порт, используя ваши команды IP filtering/forwarding.
В опции httpd_accel_host virtual - волшебное слово!
Параметр httpd_accel_with_proxy on требуется, чтобы включить режим прозрачного проскирования; в действительности в режиме прозрачного прокси Squid считает, что он работает и как акселератор (т.е. принимает пакеты для других IP на порту 80), и как кеширующий прокси (т.е. обслуживает файлы из кеша).
Вы обязаны использовать httpd_accel_uses_host_header on, чтобы кеш нормально работал в режиме прозрачного проксирования. Это позволит кешу индексировать сохраняемые им объекты по действительным именам хостов, как это делает обычный прокси, а не по IP-адресам. Это особенно важно, если вы хотите использовать иерархию родительских прокси или разделять данные кеша между пользователями прозрачного прокси и пользователями непрозрачного прокси, которое вы можете при помощи Squid в данной конфигурации.

17.1 Прозрачное кеширование для Solaris, SunOS, и BSD систем

ЗАМЕЧАНИЕ: Вам необязательно использовать IP Filter на FreeBSD. Используйте встроенный ipfw взамен этого. См. ниже подраздел, посвященный FreeBSD.

Установка IP Filter

Прежде всего скачайте и установите IP Filter package.

Конфигурирование ipnat

В /etc/ipnat.rules занесите такие строки:

        # Redirect direct web traffic to local web server.
        rdr de0 1.2.3.4/32 port 80 -> 1.2.3.4 port 80 tcp

        # Redirect everything else to squid on port 8080
        rdr de0 0.0.0.0/0 port 80 -> 1.2.3.4 port 8080 tcp

Отредактируйте ваши стартовые скрипты, чтобы включить ipnat. К примеру на FreeBSD это выглядит так:

        /sbin/modload /lkm/if_ipl.o
        /sbin/ipnat -f /etc/ipnat.rules
        chgrp nobody /dev/ipnat
        chmod 644 /dev/ipnat

Настройка Squid

Squid-2

Squid-2 (после версии beta25) имеет встроенную поддержку IP filter. Просто включите ее при запуске configure:

        ./configure --enable-ipf-transparent

Добавьте в ваш squid.conf строки:

        http_port 8080
        httpd_accel_host virtual
        httpd_accel_port 80
        httpd_accel_with_proxy on
        httpd_accel_uses_host_header on

Вам необязательно использовать порт 8080, но его номер должен совпадать с указанным в файле /etc/ipnat.rules.

Squid-1.1

Патчи для Squid-1.X доступны на Quinton Dolan's Squid page. Добавьте эти строк в squid.conf:

        http_port 8080
        httpd_accel virtual 80
        httpd_accel_with_proxy on
        httpd_accel_uses_host_header on

Благодарность Quinton Dolan.

17.2 Прозрачное кеширование на Linux 2.0 и ipfwadm

от Rodney van den Oever

Замечание: Прозрачное проксирование НЕ работает на Linux 2.0.30! На Linux 2.0.29 работает хорошо. Если вы используете более свежую версию ядра типа 2.2.X, то вы должны использовать ipchains при настройках, как описано ниже.

Предупреждение: this technique has some shortcomings.

Этот метод поддерживает только протокол HTTP, gopher и FTP не поддерживаются
Т.к. у броузерна не установлены настройки прокси-сервера, то он использует FTP-протокол (с портом назначения 21) и протокол HTTP не требуется. Вы не можете установить правило перенаправления на прокси-серве, если используется неверный протокол. Подобная проблема наблюдается и с gopher. Обычно все запросы к прокси транслируются клиентом в HTTP-протокол, но т.к. клиент ничего не знает о перенаправлении, то этого никогда не происходит.

Если вас не смущают побочные эффекты - вперед, компилировать ядро с поддержной файервола и пренаправления. Вот важные параметры из /usr/src/linux/.config:

        #
        # Code maturity level options
        #
        CONFIG_EXPERIMENTAL=y
        #
        # Networking options
        #
        CONFIG_FIREWALL=y
        # CONFIG_NET_ALIAS is not set
        CONFIG_INET=y
        CONFIG_IP_FORWARD=y
        # CONFIG_IP_MULTICAST is not set
        CONFIG_IP_FIREWALL=y
        # CONFIG_IP_FIREWALL_VERBOSE is not set
        CONFIG_IP_MASQUERADE=y
        CONFIG_IP_TRANSPARENT_PROXY=y
        CONFIG_IP_ALWAYS_DEFRAG=y
        # CONFIG_IP_ACCT is not set
        CONFIG_IP_ROUTER=y

Вам также необходимо включить IP Forwarding. ОДин из способов сделать это - добавить такую строку в стартовый скрипт:

        echo 1 > /proc/sys/net/ipv4/ip_forward

Сходите на страницу Linux IP Firewall and Accounting, скачайте дистрибутив ipfwadm и установите его. Старые версии ipfwadm могут не работать. Вам возможно понадобится последняя версия 2.3.0. Вы будете использовать ipfwadm для установки правил перенаправления. Я добавил такое правило в скрипт, который запускается из /etc/rc.d/rc.inet1 (Slackware) which sets up the interfaces at boot-time. Перенаправление должно идти прежде других правил Input-accept. Чтобы убедиться, что все действительно работает, я выключил форвардинг (маскарадинг), который обычно работает.

/etc/rc.d/rc.firewall:

        #!/bin/sh
        # rc.firewall   Linux kernel firewalling rules
        FW=/sbin/ipfwadm

        # Flush rules, for testing purposes
        for i in I O F # A      # If we enabled accounting too
        do
                ${FW} -$i -f
        done

        # Default policies:
        ${FW} -I -p rej         # Incoming policy: reject (quick error)
        ${FW} -O -p acc         # Output policy: accept
        ${FW} -F -p den         # Forwarding policy: deny

        # Input Rules:

        # Loopback-interface (local access, eg, to local nameserver):
        ${FW} -I -a acc -S localhost/32 -D localhost/32

        # Local Ethernet-interface:

        # Redirect to Squid proxy server:
        ${FW} -I -a acc -P tcp -D default/0 80 -r 8080

        # Accept packets from local network:
        ${FW} -I -a acc -P all -S localnet/8 -D default/0 -W eth0

        # Only required for other types of traffic (FTP, Telnet):

        # Forward localnet with masquerading (udp and tcp, no icmp!):
        ${FW} -F -a m -P tcp -S localnet/8 -D default/0
        ${FW} -F -a m -P udp -S localnet/8 -D default/0

Здесь весь трафик из локальной сети идущий куда-либо по 80-му порту перенаправляется на локальный порт 8080. Правила должны выглядеть так:

        IP firewall input rules, default policy: reject
        type  prot source               destination          ports
        acc   all  127.0.0.1            127.0.0.1            n/a
        acc/r tcp  10.0.0.0/8           0.0.0.0/0            * -> 80 => 8080
        acc   all  10.0.0.0/8           0.0.0.0/0            n/a
        acc   tcp  0.0.0.0/0            0.0.0.0/0            * -> *

Я протестировал это на Windows 95 и с Microsoft Internet Explorer 3.01 и с Netscape Communicator и работали оба броузера с выключенными настройками прокси.

Однажды squid зациклился, когда я указал броузеру на локальный порт 80. Это было исправлено добавлением правила reject для клиента этого адреса:

        ${FW} -I -a rej -P tcp -S localnet/8 -D hostname/32 80

        IP firewall input rules, default policy: reject
        type  prot source               destination          ports
        acc   all  127.0.0.1            127.0.0.1            n/a
        rej   tcp  10.0.0.0/8           10.0.0.1             * -> 80
        acc/r tcp  10.0.0.0/8           0.0.0.0/0            * -> 80 => 8080
        acc   all  10.0.0.0/8           0.0.0.0/0            n/a
        acc   tcp  0.0.0.0/0            0.0.0.0/0            * -> *

Замечание по преобразованию имен: Взамен передачи URL-лов прокси-серверу, броузер самостоятельно резолвит эти URL-лы. Убедитесь, что на рабочих станциях установлен локальный сервер имен, для минимизации исходящего трафика.

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

Дополнительные замечания от Richard Ayres

I'm using such a setup. The only issues so far have been that:

Бесполезно использовать родительсткий кеш моего провайдера (cache-?.www.demon.net), потому-что проксирующий squid видит только IP-адреса, а не имена хостов и демон вообще не asked for IP addresses by other users;

Linux kernel 2.0.30 не работает с прозрачным проксированием (я использую 2.0.29);

Клиентские броузеры должны сомостоятельно преобразовывать имена хостов, т.к. они не знают, что используют прокси;

Microsoft Network не желает авторизовывать своих польлзователей через прокси, поэтому мне пришлось специально *не* перенаправлять подобные пакеты (моя компания пользуется услугами MSN).

Несмотря на это, я имею 30-40% попаданий в кеш размером 50MB для 30-40 пользователей и вполне доволен результатом.

См. также страницу Daniel Kiracofe.

17.3 Прозрачное кеширование на Linux 2.2 и ipchains

от Martin Lyons

Вам необходимо отконфигурировать ваше ядро для работы с ipchains. Конфигурирование ядра Linux вне поля зрения этого FAQ. Один из способов сделать это:

        # cd /usr/src/linux
        # make menuconfig

Нижеследующее показывает важные функции ядра, которые необходимо включить:

        [*] Network firewalls
        [ ] Socket Filtering
        [*] Unix domain sockets
        [*] TCP/IP networking
        [ ] IP: multicasting
        [ ] IP: advanced router
        [ ] IP: kernel level autoconfiguration
        [*] IP: firewalling
        [ ] IP: firewall packet netlink device
        [*] IP: always defragment (required for masquerading)
        [*] IP: transparent proxy support

You must include the IP: always defragment, otherwise it prevents you from using the REDIRECT chain.

Можете использовать этот скрипт как шаблон для вашего собственного rc.firewall, настраивающего ipchains:

        #!/bin/sh
        # rc.firewall   Linux kernel firewalling rules
        # Leon Brooks (leon at brooks dot fdns dot net)
        FW=/sbin/ipchains
        ADD="$FW -A"

        # Flush rules, for testing purposes
        for i in I O F # A      # If we enabled accounting too
        do
                ${FW} -F $i
        done

        # Default policies:
        ${FW} -P input REJECT   # Incoming policy: reject (quick error)
        ${FW} -P output ACCEPT  # Output policy: accept
        ${FW} -P forward DENY   # Forwarding policy: deny

        # Input Rules:

        # Loopback-interface (local access, eg, to local nameserver):
        ${ADD} input -j ACCEPT -s localhost/32 -d localhost/32

        # Local Ethernet-interface:

        # Redirect to Squid proxy server:
        ${ADD} input -p tcp -d 0/0 80 -j REDIRECT 8080

        # Accept packets from local network:
        ${ADD} input -j ACCEPT -s localnet/8 -d 0/0 -i eth0

        # Only required for other types of traffic (FTP, Telnet):

        # Forward localnet with masquerading (udp and tcp, no icmp!):
        ${ADD} forward -j MASQ -p tcp -s localnet/8 -d 0/0
        ${ADD} forward -j MASQ -P udp -s localnet/8 -d 0/0

Как заметил Andrew Shipton для ядер 2.0.x вам не нужно включать форвард пакетов, но для ядер 2.1.x и 2.2.x, использующих ipchains, вам необходимо сделать это. Форвард пакетор включается следующей командой:

        echo 1 > /proc/sys/net/ipv4/ip_forward

17.4 Прозрачное кеширование на Linux 2.4 и netfilter

Замечание: эта информация взята из Daniel Kiracofe's Transparent Proxy with Squid mini-HOWTO.

Вам нужно собрать новое ядро. Убедитесь, что в ядро включены все указанные опции (а не собраны модулями):

Networking support
Sysctl support
Network packet filtering
TCP/IP networking
Connection tracking (Under ``IP: Netfilter Configuration'' in menuconfig)
IP tables support
Full NAT
REDIRECT target support
/proc filesystem support

Вы должны сказать NO для ``Fast switching''

После сборки ядра установите его и перегрузитесь.

Вам необходимо включить форвард пакетов (в вашем стартовом скрипте):

echo 1 > /proc/sys/net/ipv4/ip_forward

Используйте команду iptables, чтобы заставить ваше ядро перехватывать HTTP-соединения и направлять их на Squid:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

17.5 Прозрачное кеширование и маршуртизаторы Cisco

от John Saunders

Это должно работать с IOS 11.1 и более поздних, как я полагаюs. Возможно работает и на более ранних, но я не эксперт по CISCO и не могу утверждать точно. Если ваш маршрутизатор делает нечто более сложное, чем перераспределение пакетов между интерфейсом ethernet и соследовательным потом или портом BRI, то и это будет работать.

Прежде всего опишите route map с именем proxy-redirect (имя не имеет значения) и укажите машину на которой запущен Squid как next-hop.

        !
        route-map proxy-redirect permit 10
         match ip address 110
         set ip next-hop 203.24.133.2
        !

Объявите список доступа для захвата HTTP-запросов. The second line allows the Squid host direct access so an routing loop is not formed. Будте внимательны, описывая списки доступа как показано ниже, чаще всего они срабатывают быстро, что позваляет существенно уменьшить нагрузку на процессов вашего маршрутизатора.

        !
        access-list 110 deny   tcp any any neq www
        access-list 110 deny   tcp host 203.24.133.2 any
        access-list 110 permit tcp any any
        !

Привяжите route map к ethernet-интерфейсу.

        !
        interface Ethernet0
         ip policy route-map proxy-redirect
        !

возможные ошибки

Bruce Morgan заметил, что есть в Cisco есть ошибка, касающаяся прозрачного проксирования с использованием IP policy route maps, что не дает NFS и другим приложениям нормально работать. Изсестно, что есть два релиза от Cisco посвященные этой ошибке, но они не доступны для всеобщего обозрения.

Проблеме подвержены o/s-пакеты длиной более чем 1472 байт. Если сделать пинг на хост размером пакета более 1472 байт через ваш интерфейс на Cisco,а котором установлен access-lists и ip policy route map, то icmp-запрос завершится неудачно. Пакет будет фрагментирован, первый фрагмент пройдет через access-list и будет отброшен - it goes the "normal path" as it is an icmp packet - однако, когда второй фрагмент пройдет через access-list и будет принят (не расценено как icmp-пакет) и происходит действие, определенное в policy route map!

John отмечает, что проблему можно обойти, если внимательно составлять ваши списки доступа. Если последним (по умолчанию) идет разрешающее правило, то баг станет проблемой, но если последним (по умолчанию) будет правило deny, то проблемы не будет. I guess fragments, other than the first, don't have the information available to properly policy route them. Обыкновенно TCP-пакеты не должны фрагментироваться, по карйней мере в моей сети все работает с MTU равным 1500, чтобы избежать фрагментации. Т.е. это имеет значение только для UDP- и ICMP-трафика.

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

        access-list 110 deny   tcp any any neq www
        access-list 110 deny   tcp host 10.1.2.3 any
        access-list 110 permit tcp any any

И наоборот, в указанном случае производительность будет хуже, но зато будут работать все протоколы:

        access-list 110 deny   tcp host 10.1.2.3 any
        access-list 110 permit tcp any any eq www
        access-list 110 deny   tcp any any

17.6 Прозрачное кеширование на LINUX 2.0.29 и CISCO IOS 11.1

Это письмо, отправленное пользователям списка рассылки squid-users, с описанием того, как заставить работать прозрачный с маршрутизатором Cisco и Squid-ом запущенным на Linux.

от Brian Feeny

Здесь представлена информация о том, как я настроил прозрачное проксирование, используя мой маршрутизатор Cisco 2501, работающий под IOS 11.1, и Squid, запущенный на машине с Linux 2.0.33.

Большое спасибо нижеперечисленным людям и пользователям списка рассылки squid-users за помощь в настройке пренаправления и прозрачного проксирования, работающей на моей связке Cisco/Linux.

Lincoln Dale
Riccardo Vratogna
Mark White
Henrik Nordstrom

Прежде всего, вот что я добавил на моей Cisco, запущенной под IOS 11.1. В IOS 11.1 команда route-map использует "process switched" а не более быструю "fast-switched" route-map, которая применяется в IOS 11.2 и более поздних. Вы возможно пожелаете использовать IOS 11.2. У меня работает 11.1 и я не имел проблем при моей текущей нагрузке более чем 150 соединений к Squid.:

        !
        interface Ethernet0
         description To Office Ethernet
         ip address 208.206.76.1 255.255.255.0
         no ip directed-broadcast
         no ip mroute-cache
         ip policy route-map proxy-redir
        !
        access-list 110 deny   tcp host 208.206.76.44 any eq www
        access-list 110 permit tcp any any eq www
        route-map proxy-redir permit 10
         match ip address 110
         set ip next-hop 208.206.76.44

В представленном выше вы можете заметить, что я добавил описание "route-map" и access-list и потом привязал route-map через int e0 "ip policy route-map proxy-redir"

отлично, теперь Cisco позаботится об этом. Хост, указанный выше, 208.206.76.44 - это ip-адрес моей машини со squid.

Машина со squid работает под Linux, поэтому на ней я сделал следующее:

конфиг моего ядра (2.0.33) выглядит так:

        #
        # Networking options
        #
        CONFIG_FIREWALL=y
        # CONFIG_NET_ALIAS is not set
        CONFIG_INET=y
        CONFIG_IP_FORWARD=y
        CONFIG_IP_MULTICAST=y
        CONFIG_SYN_COOKIES=y
        # CONFIG_RST_COOKIES is not set
        CONFIG_IP_FIREWALL=y
        # CONFIG_IP_FIREWALL_VERBOSE is not set
        CONFIG_IP_MASQUERADE=y
        # CONFIG_IP_MASQUERADE_IPAUTOFW is not set
        CONFIG_IP_MASQUERADE_ICMP=y
        CONFIG_IP_TRANSPARENT_PROXY=y
        CONFIG_IP_ALWAYS_DEFRAG=y
        # CONFIG_IP_ACCT is not set
        CONFIG_IP_ROUTER=y

Вам необходимо будет включить как минимум Firewalling и Transparent Proxy.

Теперь кое-что о настройках ipfwadm:

        # Accept all on loopback
        ipfwadm -I -a accept -W lo
        # Accept my own IP, to prevent loops (repeat for each interface/alias)
        ipfwadm -I -a accept -P tcp -D 208.206.76.44 80
        # Send all traffic destined to port 80 to Squid on port 3128
        ipfwadm -I -a accept -P tcp -D 0/0 80 -r 3128

это позволит принимать пакеты на порту 80 (перенаправленные Cisco) и заворачивать их на порт 3128, на котором работает мой процесс Squid. Все это я поместил в /etc/rc.d/rc.local

Я использую Squid версии v1.1.20 с установленным Henrik's patch. Вы возможно захотите уатсновить этот же патч, если используете установки похожие на мои.

17.7 Кеш пытается соеденится сам с собой ...

от Henrik Nordstrom

Я думаю, что каждый, кто пытался настроить прозрачное проксирование, сталкивались с этим.

Вы можете предпринять следующее:

Запретить Squid-у забирать объекты у себя самого (используя ACL).
Наложить небольшой патч, кторый предотвращает бесконечное зацикливание Squid (доступен на Henrik's Squid Patches)
Не запускайте Squid на 80-м порту и не перенаправляйте Squid-у пакеты по 80-му порту, не предназначенные для локальной машины (перенаправление == ipfilter/ipfw/ipfadm). Это предотвращает большинство случаем зацикливания.
Если вы используете ipfilter, то должны также использовать transproxyd прежде, чем Squid. Squid пока еще не знает как работать с ipfilter (патчи принимаются на: squid-bugs@squid-cache.org).

17.8 Прозрачное кеширование с FreeBSD

от Duane Wessels

Я вчера заставил работать прозрачное проксирование со Squid и FreeBSD. Это было прикольно.

Это было достаточно просто - настроить cisco на заворачивание пакетов по 80-му порту на пою машину с FreeBSD. Настройки выглядели примерно так:

access-list 110 deny   tcp host 10.0.3.22 any eq www
access-list 110 permit tcp any any eq www
route-map proxy-redirect permit 10
match ip address 110
set ip next-hop 10.0.3.22
int eth2/0
ip policy route-map proxy-redirect

Где 10.0.3.22 - IP-адрес машины с FreeBSD, на которой работает кеш.

Как только я получаю пакеты на моей машине с FreeBSD, необходимо, что бы ядро доставило эти Squid. Я запустил FreeBSD-2.2.7 и загрузил IPFilter. Это был конец для меня. Дистрибутив IPFilter включает патчи для исходников ядра FreeBSD, но многие из них конфликтовали. Потом я заметил, что на странице IPFilter сказано ``Это составная часть [FreeBSD-2.2 и более поздних].'' Хватит об этом. К сожалению, вы не можете перехватывать соединения при помощи кода FreeBSD-2.2.X IPFIREWALL (ipfw), и при помощи natd вам не удастся сделать это тоже (по крайней мере мне не удалось).

FreeBSD-3.0 намного лучше поддерживает перехват "чужих" соединений (hijacking), я полагаю, что вы используете ее. Вам необходимо пересобрать ядро со следующими опциями:

        options         IPFIREWALL
        options         IPFIREWALL_FORWARD

Теперь пришло время настроить правила IP firewall при помощи ipfw. По умолчанию правило "allow" отсутствует и прохождение любых пакетов запрещено. Я добавил эту команду в файл /etc/rc.local, чтобы иметь возможность использовать машину в моей сети:

        ipfw add 60000 allow all from any to any

Но это еще не перехват соединений. Чтобы покончить с этим, добавьте такие строки:

        ipfw add 49  allow tcp from 10.0.3.22 to any
        ipfw add 50  fwd 127.0.0.1 tcp from any to any 80

Вторая строка (правило 50) - единственная, которая отвечает за перехват чужих соединений (hijack). Первое правило указано для того, чтобы трафик, посланный локальной машиной никогда не попал под правило 50. Это предотвращает зацикливание.

Заметьте, что я не менял номер порта в данном примере. Посему, пакет, пришедший на порт 80, просто заворачивается на 80-й порт Squid. Моя конфигурация Squid:

        http_port 80
        httpd_accel_host virtual
        httpd_accel_port 80
        httpd_accel_with_proxy on
        httpd_accel_uses_host_header on

Если вы не хотите, чтобы Squid слушал порт 80 (т.к. это требует привилегий root), вы можете использовать другой порт. В этом случае правило перенаправления для ipfw выглядит так:

        ipfw add 50 fwd 127.0.0.1,3128 tcp from any to any 80

а строки из squid.conf так:

        http_port 3128
        httpd_accel_host virtual
        httpd_accel_port 80
        httpd_accel_with_proxy on
        httpd_accel_uses_host_header on

17.9 Прозрачное кеширование с сервером доступа ACC Tigris digital

от John Saunders

Здесь описана настройка прозрачного проксирования при помощи сервера доступа ACC Tigris (типа CISCO 5200/5300 или Ascend MAX 4000). Мной обнаружено, что если сделать это в NAS, то уменьшается трафик в локаьлной сети и уменьшается нагрузка на CISCO. Мощности CPU Tigris-у для фильтрования хватит.

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

        ADD PROFILE IP FILTER ENTRY local1 INPUT  10.0.3.0 255.255.255.0 0.0.0.0 0.0.0.0 NORMAL
        ADD PROFILE IP FILTER ENTRY local2 INPUT  10.0.4.0 255.255.255.0 0.0.0.0 0.0.0.0 NORMAL

Шаг 2 - создание фильтра для захвата трафика по 80-му порту.

        ADD PROFILE IP FILTER ENTRY http INPUT  0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 = 0x6 D= 80 NORMAL

Шаг 3 - установить "APPLICATION_ID" для трафика по порту 80 равное 80. Это значит, что все пакеты попавшие под этот фильтр будут иметь ID 80, взамен принятого по умолчанию ID 0.

        SET PROFILE IP FILTER APPLICATION_ID http 80

Шаг 4 - создание специального маршрута, который используется для пакетов с "APPLICATION_ID" установленным в 80. Маршрутизатор использует ID, для выбора необходимого маршрута.

        ADD IP ROUTE ENTRY 0.0.0.0 0.0.0.0 PROXY-IP 1
        SET IP ROUTE APPLICATION_ID 0.0.0.0 0.0.0.0 PROXY-IP 80

Шаг 5 - привязать все к фильтру с ID по имени transproxy. Расположите все локальные фильтры первыми, а http-фильтр последним.

        ADD PROFILE ENTRY transproxy local1 local2 http

В этом месте используйте ваш RADIUS-сервер чтобы вернуть ``Framed-Filter-Id = transproxy'' пару ключ/значение для NAS.

Вы можете проверить привязку фильтра к логинам при помощи команды:

        display profile port table

17.10 ``Connection reset by peer'' и Cisco policy routing

Fyodor проследил причину появления сообщений ``connection reset by peer'', когда Cisco policy routing используется для перехвата HTTP-запросов.

Когда линк между маршрутизатором и кешем ненадолго пропадает, то пакет, который должен быть перенарпавлен, вместо этого попадает на шлюз по умолчанию. Если это произошло, то TCP ACK от клиентского хоста может быть послан напрямую к запрашиваемому серверу, взамен того, чтобы принудительно быть завернутым к кешу. Запрашиваемый сервер, получивший непонятный пакет ACK, посылает TCP RESET клиенту, чем и завершает клиентский запрос.

Чтобы обойти эту проблему, укажите статический маршрут к интерфейсу null0 для адреса вашего кеша с более высокой метрикой (lower precedence), типа 250. После этого, если линк "упал", то пакет от клиента просто будет убит взамен того, чтобы уйти на шлюз по умолчанию. К примеру, если 1.2.3.4 - это IP-адрес вашего кеша Squid cache, можете добавить:

        ip route 1.2.3.4 255.255.255.255 Null0 250

Это должно поправить ситцацию.

17.11 WCCP - Web Cache Coordination Protocol

Contributors: Glenn Chisholm и Lincoln Dale.

Поддерживает ли Squid протокол WCCP?

CISCO's Web Cache Coordination Protocol V1.0 поддерживается squid версий 2.3 и более поздних. В настоящее всемя WCCP V2 - это открытый протокол, Squid возможно будет поддерживате его в будущем.

Настройка вашего маршутизатора

Есть два различных метода настройке WCCP на роутере CISCO. Первый метод для которые поддерживают только версию 1.0 протокола. Второй - для роутеров, поддерживающих обе версии.

IOS Version 11.x

Возможно более поздние версии IOS 11.x будут поддерживать V2.0 протокола. Если это произойдет, то следуйте инструкциям для 12.x. Некоторые люди сообщили нам о том, что реализация поддержки WCCP в Squid не работает с их маршуритизаторами под IOS 11.x. Если вы имели подобный опыт, пошлите отладочную информацию вашего роутера в список рассылки squid-bugs.

        conf t

        wccp enable
        !
        interface [Interface Carrying Outgoing Traffic]x/x
        !
        ip wccp web-cache redirect
        !
        CTRL Z
        write mem

IOS Version 12.x

Некоторые ранние версии 12.x не имеют команды 'ip wccp version'. Вам необходимо обновить вашу версию IOS, чтобы использовать V1.0.

Вы должны иметь хотя бы IOS Software Release 12.0(5)T, если вы используете 12.0 T-train. IOS Software Releases 12.0(3)T и 12.0(4)T не имеют поддержки WCCPv1, а в 12.0(5)T она есть.

        conf t

        ip wccp version 1
        ip wccp web-cache
        !
        interface [Interface Carrying Outgoing/Incomming Traffic]x/x
        ip wccp web-cache redirect out|in
        !
        CTRL Z
        write mem

Проблемы с IOS 12.3

Некоторые люди сообщают о проблемах работы WCCP в IOS 12.3. Они наблюдают битые или фрагментированные GRE-пакеты, приходящие к кешу. Очевидно это происходит из-за того, что вы отключаете Cisco Express Forwarding для интерфейса:

conf t
ip cep          # some systems may need 'ip cep global'
int Ethernet0/0
no ip route-cache cef
CTRL Z

Настройка FreeBSD

FreeBSD прежде всего должна быть настроена на прием и распознавание GRE-инкапсулации пакетов идущих от маршрутизатора. Для этого вам необходимо про патчить и пересобрать ваше ядро.

Прежде всего наложите патч для поддержки GRE вашим ядром. Наложите патч gre.patch для ядер FreeBSD-3.x или патч gre.patch для ядер FreeBSD-4.x по необходимости.

Далее вам нужно загрузить gre.c для FreeBSD-3.x или gre.c для FreeBSD-4.x и скопируйте его в /usr/src/sys/netinet/gre.c.

Наконец, добавьте "OPTION GRE" в файл конфигурации вашего ядра и пересоберите его. Заметьте, что файл opt_gre.h будет создан, когда вы запустите config. Когда ваше ядро будет установлено, вам потребуется настроить FreeBSD для прозрачного проксирования.

Настройка Linux 2.2

Al Blake написал Поваренная кнмга по установке прозрачного WCCP и использованием Squid на RedHat Linux и сервере доступ Cisco.

В настоящее время есть два метода поддержки WCCP на Linux 2.2. При помощи специального модуля либо с использованием стандартного драйвера Linux GRE-тунелирования. Многие сообщают о трудностях связанных с использованием стандартного драйвера GRE-тунелирования, однако он позволяет использовать GRE fне только для WCCP. Вы должны выбрать метод, который удовлетворяет вашим требованиям.

Стандартный Linux GRE Tunnel

Ядра Linux 2.2 сразу поддерживают GRE, равно как есть и подгружаемый в ядро модуль GRE.

Вам необходимо пропатчить код ip_gre.c, идущий с вашим ядром Linux при помощи этого патча, написанного Jan Haluza.

Включите поддержку кода GRE в вашем ядре или соберите ее модулем, используя соответсвующие опции в настройках вашего ядра. Пересоберите ядро. Если это модуль, то вам необходимо сделать:

        modprobe ip_gre

Следующий шаг - установить IP-тунель между роуеторм и вашим хостом. Daniele Orlandi сообщает reports that you have to give the gre1 interface an address, but any old address seems to work.

        iptunnel add gre1 mode gre remote <Router-IP> local <Host-IP> dev <interface>
        ifconfig gre1 127.0.0.2 up

<Router-IP> - это IP-адрес вашего маршрутизатора, который перехватывает HTTP-пакеты. <Host-IP> - IP-адрес вашего кеша и <interface> - это сетевой интерфейс, который принимает эти пакеты (к примеру eth0).

Joe Cooper's Patch

У Joe Cooper есть патч для ядра Linux 2.2.18, доступен на его Squid page.

Специальный модуль WCCP

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

Загрузите модуль Linux WCCP (ip_wccp.c) и откомпилируйте его как обычный сетевой модуль Linux.

Скопируйте модуль в /lib/modules/kernel-version/ipv4/ip_wccp.o. Отредактируйте /lib/modules/kernel-version/modules.dep, добавив:

        /lib/modules/kernel-version/ipv4/ip_wccp.o:

Теперь вы можете загрузить модуль:

        modprobe ip_wccp

Общий порядок

Машина должна разпознавать GRE-инкапсуляцию для любых получаемых пакетов и их обработку. Система также должна быть настроена на прозрачное проксирование с использованием ipfwadm или ipchains.

Настройка остального

Если вы сумели настроить вашу ОС на поддержку WCCP для Squid, свяжитесь с нами и поделитесь подробностями, чтобы мы могли рассказать это другим.

17.12 Кто-нибудь может мне сказать какая версия cisco IOS поддерживают WCCP?

IOS releases:

11.1(19?)CA/CC или более поздние
11.2(14)P или более поздние
12.0(любые) or later

17.13 А как насчет WCCPv2?

Cisco опубликовало WCCPv2 как Internet Draft (expired Jan 2001). Поэтому Squid не поддерживает WCCP версии 2, но желающие приглашаются к написанию кода для его поддержки в Squid project.

17.14 Прозрачное проксирование с свитчами Foundry L4

by Brian Feeny.

Прежде всего настройте Squid на прозрачное кеширование как детально описано в начале этого раздела.

Далее настройте свитч Foundry layer 4 на преренаправление трафика на ваш хост/хосты со Squid. По умолчанию Foundry перенаправляет трафик на порт 80 вашей машины со Squid-ом. Порт может быть изменен по необходмости, но это здесь рассматриваться не будет.

В добавок, свитч делает "проверку работоспособности" порта, чтобы убедиться, что ваш Squid отвечает. Если ваш squid не отвечает, то свитч по умолчанию посылает трафик напрямую взамен его перенаправления. Когда Squid снова поднимается, трафик снова начинает перенаправляться.

Пример предполагает, что вы имеете два кеша Squid:

squid1.foo.com  192.168.1.10
squid2.foo.com  192.168.1.11

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

Этот пример предполагает, что ваш роутер включен в интерфейс 17 на свитче. Если нет - измените следующие команды соответственно.

Включите режим настройки:
```
telnet@ServerIron#conf t
```

Настройте каждый squid на Foundry:

telnet@ServerIron(config)# server cache-name squid1 192.168.1.10
telnet@ServerIron(config)# server cache-name squid2 192.168.1.11

Добавьте squid-ы к cache-group:

telnet@ServerIron(config)#server cache-group 1
telnet@ServerIron(config-tc-1)#cache-name squid1
telnet@ServerIron(config-tc-1)#cache-name squid2

Создайте политику для кеширования http на локальном порту
```
telnet@ServerIron(config)# ip policy 1 cache tcp http local
```
Включите эту политику на порту вашего роутера
```
telnet@ServerIron(config)#int e 17
telnet@ServerIron(config-if-17)# ip-policy 1 
```

Весь исходящий в Internet трафик проходит через интерфейс 17 (маршрутизатор), для интерфейса 17 описана политика кеширования, поэтому HTTP-трафик проходящий через него перехватывается и перенарпавляется на указанные вами кеши.

Порт, указаный по умолчанию для перенаправления, может быть изменен. Используемый алгоритм распределния нагрузки может быть изменен (Least Used, Round Robin и т.п.). Ports can be exempted from caching if needed. Списки доступа для перенарпавления могут указываться только для опеределенного IP-адреса источника и т.п.. Эта информация была опущена в данном документе, т.к. это просто краткая инструкция по быстрой настройке, которой должно хватить для большинства людей. not meant to be a comprehensive руководство по настройке свитча Foundry. I can however revise this with any information necessary if people feel it should be included.

17.15 Могу ли я использовать proxy_auth с прозрачным проксированием?

Нет, не можете. При прозрачном проксировании ПО клиента считает, что обращается напрямую к серверу и никогда не посылает заголовок Proxy-authorization.

Вперед Назад Содержание