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