- Cisco wccp, Linux TPROXY и access-list,
 Merridius, 22:45 , 08-Апр-13 (1)>[оверквотинг удален]
> интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс
> Gi 0/2 и снова редиректится на прокси...
> Короче происходит зацикливание исходящих пакетов..
> Я пытался найти решение и в голову пришла мысль что нужно как-то
> отфильтровывать трафик с интерфейса Gi 0/2 чтобы он не редиректился снова
> на прокси..
> И собственно вопрос - есть ли какие нить механизмы учитывать в ACL
> интерфейс с которого идет пакет?
> Повторюсь: прокси НЕ подставляет свой IP адрес, адрес источника сохраняется.
> Заранее спасибо.Потому что прокся внутри сети, а wccp снаружи.
Вроде обратный трафик с прокси идет не через gre.
- Cisco wccp, Linux TPROXY и access-list, lyl8000, 12:01 , 09-Апр-13 (2)
> Потому что прокся внутри сети, а wccp снаружи.
> Вроде обратный трафик с прокси идет не через gre.Привет.
На самом деле и исходящий и входящий трафик заворачивается на прокси с внешнего интерфейса через gre, а с прокси обратно выплевывается уже без gre. В принципе в данном случае это не важно, вопрос в другом, как отделить пакеты с прокси от пакетов клиентов (которые еще не проходили прокси) используя access-list. Повторюсь - squid работает в TPROXY режиме, т.е. прокси не подменяет адрес источника свои адресом. И еще раз про зацикливание пакета. Пакет идет от клиента и заходит в маршрутизатор (Cisco 7206), на цыско есть интерфейс который смотрит в провайдера, на этом интерфейсе стоит заворот wccp на squid. Пакет уходит на squid, выходит из него обратно в ту же циску и снова попадает в интерфейс который смотрит в провайдера. Тут пакет снова (согласно access-list) заворачивается в squid.
Происходит зацикливание, которое нужно разорвать, если как то дать циске понять что пакеты с прокси не нужно снова заворачивать на squid... вот как то так..
- Cisco wccp, Linux TPROXY и access-list, Mr. Mistoffelees, 18:33 , 09-Апр-13 (3)
Привет,> Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и
> интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс
> Gi 0/2 и снова редиректится на прокси... А пакеты от клиента и от прокси обязательно должны приходить в один и тот же VLAN? Посмотрите в сторону получения пакетов от клиентов в одном VLAN-е от прокси - в другом. Может, тогда через route-map сможете поставить next-hop тем, которым нужно? Это только идея, конечно... WWell,
- Cisco wccp, Linux TPROXY и access-list, lyl8000, 19:45 , 09-Апр-13 (4)
> Привет,
>> Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и
>> интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс
>> Gi 0/2 и снова редиректится на прокси...
> А пакеты от клиента и от прокси обязательно должны приходить в один
> и тот же VLAN? Посмотрите в сторону получения пакетов от клиентов
> в одном VLAN-е от прокси - в другом. Может, тогда
> через route-map сможете поставить next-hop тем, которым нужно? Это только идея,
> конечно...
> WWell, Привет, хорошая идея, но практики с роут-мапами у меня не много, и поэтому сразу возникает вопрос:
1. Если я ставлю route-map на интерфейсе (на который из прокси прилетают пакеты) и говорю что ip nex-hop $ITSP_IP (чтоб все пакеты шли на провайдера) не будет ли пакет отфильтрован на интерфейсе смотрящем в провайдера (а там стоит ip wccp 100 out т.е. перенаправление на прокси) ? 2. Если ставить route-map на интерфейсе смотрящем в провайдера...
а) Какой порядок обработки будет? Сначала wccp потом route-map или наоборот?
б) Можно ли матчить пакеты по приходящему интерфейсу? И если да то ткните в пример.. Спасибо!!! P.S. Была идея сделать VRF типа бордер-зоны, но я не совсем понял как связывать два VRF или (VRF и global). Если есть такая инфа - буду очень признателен.
Честно - пробовал сделать VRF и туннель между ними - не получилось - пакеты не ходят..
Если бы был отдельный VRF то я бы мог разделить перенаправление на прокси, что могло решить проблему..
- Cisco wccp, Linux TPROXY и access-list, Mr. Mistoffelees, 16:48 , 10-Апр-13 (5)
Привет,> P.S. Была идея сделать VRF типа бордер-зоны, но я не совсем понял
> как связывать два VRF (или VRF и global). VRF, тоже, наверно, вариант - вы можете запихнуть входящий пакет в соотв. VRF на основании ACL или по интерфейсу откуда пришел пакет. Еще мысль - на прокси ставите нестандартный TTL, на роутере в ACL ловите пакеты с таким TTL и отправляете их в обход wccp. В таком случае можете заменить wccp out на route map с двумя клаузами - первая (по одной ACL) ловит пакеты, идущие на порт 80 или 443 и ставит им next-hop проски, вторая (по другой ACL) ловит пакеты из прокси (по TTL) и ставит им next-hop провайдера. Входящий трафик при этом может остаться на wccp in. WWell,
- Cisco wccp, Linux TPROXY и access-list, lyl8000, 21:59 , 10-Апр-13 (6)
> Еще мысль - на прокси ставите нестандартный TTL, на роутере в ACL
> ловите пакеты с таким TTL и отправляете их в обход wccp.
> В таком случае можете заменить wccp out на route map с
> двумя клаузами - первая (по одной ACL) ловит пакеты, идущие на
> порт 80 или 443 и ставит им next-hop проски, вторая (по
> другой ACL) ловит пакеты из прокси (по TTL) и ставит им
> next-hop провайдера. Входящий трафик при этом может остаться на wccp in.
> WWell, Вот и я в итоге пришел к тому что нужно заменять ip wccp на route-map.
Жаль конечно, но придется.. Хотя дополнительный VRF мог бы решить эту проблему. Но не могу никак пробросить трафик из VRF в global и наоборот.. Буду пробовать. Как что - отпишусь. Спасибо!
- Cisco wccp, Linux TPROXY и access-list, lyl8000, 16:52 , 11-Апр-13 (7)
>[оверквотинг удален]
> VRF, тоже, наверно, вариант - вы можете запихнуть входящий пакет в соотв.
> VRF на основании ACL или по интерфейсу откуда пришел пакет.
> Еще мысль - на прокси ставите нестандартный TTL, на роутере в ACL
> ловите пакеты с таким TTL и отправляете их в обход wccp.
> В таком случае можете заменить wccp out на route map с
> двумя клаузами - первая (по одной ACL) ловит пакеты, идущие на
> порт 80 или 443 и ставит им next-hop проски, вторая (по
> другой ACL) ловит пакеты из прокси (по TTL) и ставит им
> next-hop провайдера. Входящий трафик при этом может остаться на wccp in.
> WWell, В общем попробовал я с route-map. Сделал вывод что ничего не получится. Не знаю, моет быть у меня какой нить ИОС кривой (124-24.Т5) но route-map работает только для входящих пакетов (на интерфейсе). А это говорит о том что не получится исключить трафик с прокси. Последняя надежда - сделать отдельный VRF для провайдеров на циске. Но затык состоит в том что у меня не получается пробросить трафик из global в VRF и наоборот. Может кто подскажет как это сделать? Спасибо!
- Cisco wccp, Linux TPROXY и access-list, lyl8000, 23:14 , 12-Апр-13 (8)
УРРРРРРРРРРРАААААААААААААААААААААААААААААААААААААААААААААААААА!!!!!!!!!!!!!
у меня все получилось!
В общем не нужно ничего мудрить. Ни с роут-мапами ни PBR ни VRF.
Механизм WCCP все умеет САМ!!!
Просто на интерфейсе к которому подключен SQUID нужно сделать:
ip wccp redirect exclude inИ пакеты с того интерфейса больше не будут заворачиваться на прокси. ВСЁ!!!
УРА! Подчеркну еще раз: все это нужно только для случая с TPROXY. В других случаях ситуация немного другая.
Блин на столько граблей наступил.. что хоть статью пиши..
- Cisco wccp, Linux TPROXY и access-list, Aleks305, 00:02 , 14-Апр-13 (9)
>[оверквотинг удален]
> В общем не нужно ничего мудрить. Ни с роут-мапами ни PBR ни
> VRF.
> Механизм WCCP все умеет САМ!!!
> Просто на интерфейсе к которому подключен SQUID нужно сделать:
> ip wccp redirect exclude in
> И пакеты с того интерфейса больше не будут заворачиваться на прокси. ВСЁ!!!
> УРА!
> Подчеркну еще раз: все это нужно только для случая с TPROXY. В
> других случаях ситуация немного другая.
> Блин на столько граблей наступил.. что хоть статью пиши..напиши на habr, может инвайт получишь, другим полезно будет)
|
Версия для распечатки
Cisco wccp, Linux TPROXY и access-list, 
