forum.opennet.ru - "Cisco wccp, Linux TPROXY и access-list" (9)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Cisco wccp, Linux TPROXY и access-list"

Форум Маршрутизаторы CISCO и др. оборудование. (ACL, фильтрация и ограничение трафика)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Cisco wccp, Linux TPROXY и access-list"	+/–
Сообщение от lyl8000 (ok) on 07-Апр-13, 10:36
Добрый всем день. Вобщем случилось так что пришлось прикручивать SQUID к маршрутизатору для фильтрации всяких нехороших страниц (по версии РосПотребНадзора). Схема следующая: есть интерфейс смотрящий на провайдера, на нем ставлю правила: interface GigabitEthernet 0/1 ip wccp 80 redirect out ip wccp 90 redirect in подробно описывать access-listы не имеет смысла, скажу проще 80 - это процесс который выбирает веб-трафик который идет внутрь сети и перенаправляет его на SQUID. Ну и соответственно 90 - процесс который перенаправляет на SQUID исходящий веб-трафик. На SQUID включен режим TPROXY, который позволяет замутить полностью прозрачное проксирование трафика, т.е. не будет изменяться даже srcIP. Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс Gi 0/2 и снова редиректится на прокси... Короче происходит зацикливание исходящих пакетов.. Я пытался найти решение и в голову пришла мысль что нужно как-то отфильтровывать трафик с интерфейса Gi 0/2 чтобы он не редиректился снова на прокси.. И собственно вопрос - есть ли какие нить механизмы учитывать в ACL интерфейс с которого идет пакет? Повторюсь: прокси НЕ подставляет свой IP адрес, адрес источника сохраняется. Заранее спасибо.
Ответить \| Правка \| Cообщить модератору

Оглавление

Cisco wccp, Linux TPROXY и access-list, Merridius, 22:45 , 08-Апр-13, (1)

Cisco wccp, Linux TPROXY и access-list, lyl8000, 12:01 , 09-Апр-13, (2)

Cisco wccp, Linux TPROXY и access-list, Mr. Mistoffelees, 18:33 , 09-Апр-13, (3)

Cisco wccp, Linux TPROXY и access-list, lyl8000, 19:45 , 09-Апр-13, (4)

Cisco wccp, Linux TPROXY и access-list, Mr. Mistoffelees, 16:48 , 10-Апр-13, (5)

Cisco wccp, Linux TPROXY и access-list, lyl8000, 21:59 , 10-Апр-13, (6)
Cisco wccp, Linux TPROXY и access-list, lyl8000, 16:52 , 11-Апр-13, (7)

Cisco wccp, Linux TPROXY и access-list, lyl8000, 23:14 , 12-Апр-13, (8)

Cisco wccp, Linux TPROXY и access-list, Aleks305, 00:02 , 14-Апр-13, (9)

Сообщения по теме [Сортировка по времени | RSS]

1. "Cisco wccp, Linux TPROXY и access-list" +/–

Сообщение от Merridius (ok) on 08-Апр-13, 22:45

>[оверквотинг удален]
> интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс
> Gi 0/2 и снова редиректится на прокси...
> Короче происходит зацикливание исходящих пакетов..
> Я пытался найти решение и в голову пришла мысль что нужно как-то
> отфильтровывать трафик с интерфейса Gi 0/2 чтобы он не редиректился снова
> на прокси..
> И собственно вопрос - есть ли какие нить механизмы учитывать в ACL
> интерфейс с которого идет пакет?
> Повторюсь: прокси НЕ подставляет свой IP адрес, адрес источника сохраняется.
> Заранее спасибо.
Потому что прокся внутри сети, а wccp снаружи.
Вроде обратный трафик с прокси идет не через gre.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Cisco wccp, Linux TPROXY и access-list" +/–

Сообщение от lyl8000 (ok) on 09-Апр-13, 12:01

> Потому что прокся внутри сети, а wccp снаружи.
> Вроде обратный трафик с прокси идет не через gre.
Привет.
На самом деле и исходящий и входящий трафик заворачивается на прокси с внешнего интерфейса через gre, а с прокси обратно выплевывается уже без gre.
В принципе в данном случае это не важно, вопрос в другом, как отделить пакеты с прокси от пакетов клиентов (которые еще не проходили прокси) используя access-list.
Повторюсь - squid работает в TPROXY режиме, т.е. прокси не подменяет адрес источника свои адресом.
И еще раз про зацикливание пакета. Пакет идет от клиента и заходит в маршрутизатор (Cisco 7206), на цыско есть интерфейс который смотрит в провайдера, на этом интерфейсе стоит заворот wccp на squid. Пакет уходит на squid, выходит из него обратно в ту же циску и снова попадает в интерфейс который смотрит в провайдера. Тут пакет снова (согласно access-list) заворачивается в squid.
Происходит зацикливание, которое нужно разорвать, если как то дать циске понять что пакеты с прокси не нужно снова заворачивать на squid...
вот как то так..

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Cisco wccp, Linux TPROXY и access-list" +/–

Сообщение от Mr. Mistoffelees on 09-Апр-13, 18:33

Привет,
> Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и
> интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс
> Gi 0/2 и снова редиректится на прокси...
А пакеты от клиента и от прокси обязательно должны приходить в один и тот же VLAN? Посмотрите в сторону получения пакетов от клиентов в одном VLAN-е  от прокси - в другом. Может, тогда через route-map сможете поставить next-hop тем, которым нужно? Это только идея, конечно...
WWell,

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Cisco wccp, Linux TPROXY и access-list" +/–

Сообщение от lyl8000 (ok) on 09-Апр-13, 19:45

> Привет,
>> Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и
>> интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс
>> 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 то я бы мог разделить перенаправление на прокси, что могло решить проблему..

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Cisco wccp, Linux TPROXY и access-list" +/–

Сообщение от Mr. Mistoffelees on 10-Апр-13, 16:48

Привет,
> 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,

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Cisco wccp, Linux TPROXY и access-list" +/–

Сообщение от lyl8000 (ok) on 10-Апр-13, 21:59

> Еще мысль - на прокси ставите нестандартный 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 и наоборот..
Буду пробовать. Как что - отпишусь.
Спасибо!

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Cisco wccp, Linux TPROXY и access-list" +/–

Сообщение от lyl8000 (ok) on 11-Апр-13, 16:52

>[оверквотинг удален]
> 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 и наоборот. Может кто подскажет как это сделать?
Спасибо!

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Cisco wccp, Linux TPROXY и access-list" +/–

Сообщение от lyl8000 (ok) on 12-Апр-13, 23:14

УРРРРРРРРРРРАААААААААААААААААААААААААААААААААААААААААААААААААА!!!!!!!!!!!!!
у меня все получилось!
В общем не нужно ничего мудрить. Ни с роут-мапами ни PBR ни VRF.
Механизм WCCP все умеет САМ!!!
Просто на интерфейсе к которому подключен SQUID нужно сделать:
ip wccp redirect exclude in
И пакеты с того интерфейса больше не будут заворачиваться на прокси. ВСЁ!!!
УРА!
Подчеркну еще раз: все это нужно только для случая с TPROXY. В других случаях ситуация немного другая.
Блин на столько граблей наступил.. что хоть статью пиши..

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Cisco wccp, Linux TPROXY и access-list" +/–

Сообщение от Aleks305 (ok) on 14-Апр-13, 00:02

>[оверквотинг удален]
> В общем не нужно ничего мудрить. Ни с роут-мапами ни PBR ни
> VRF.
> Механизм WCCP все умеет САМ!!!
> Просто на интерфейсе к которому подключен SQUID нужно сделать:
>  ip wccp redirect exclude in
> И пакеты с того интерфейса больше не будут заворачиваться на прокси. ВСЁ!!!
> УРА!
> Подчеркну еще раз: все это нужно только для случая с TPROXY. В
> других случаях ситуация немного другая.
> Блин на столько граблей наступил.. что хоть статью пиши..
напиши на habr, может инвайт получишь, другим полезно будет)

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Cisco wccp, Linux TPROXY и access-list"	+/–
Сообщение от Merridius (ok) on 08-Апр-13, 22:45
>[оверквотинг удален] > интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс > Gi 0/2 и снова редиректится на прокси... > Короче происходит зацикливание исходящих пакетов.. > Я пытался найти решение и в голову пришла мысль что нужно как-то > отфильтровывать трафик с интерфейса Gi 0/2 чтобы он не редиректился снова > на прокси.. > И собственно вопрос - есть ли какие нить механизмы учитывать в ACL > интерфейс с которого идет пакет? > Повторюсь: прокси НЕ подставляет свой IP адрес, адрес источника сохраняется. > Заранее спасибо. Потому что прокся внутри сети, а wccp снаружи. Вроде обратный трафик с прокси идет не через gre.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Cisco wccp, Linux TPROXY и access-list"	+/–
	Сообщение от lyl8000 (ok) on 09-Апр-13, 12:01
	> Потому что прокся внутри сети, а wccp снаружи. > Вроде обратный трафик с прокси идет не через gre. Привет. На самом деле и исходящий и входящий трафик заворачивается на прокси с внешнего интерфейса через gre, а с прокси обратно выплевывается уже без gre. В принципе в данном случае это не важно, вопрос в другом, как отделить пакеты с прокси от пакетов клиентов (которые еще не проходили прокси) используя access-list. Повторюсь - squid работает в TPROXY режиме, т.е. прокси не подменяет адрес источника свои адресом. И еще раз про зацикливание пакета. Пакет идет от клиента и заходит в маршрутизатор (Cisco 7206), на цыско есть интерфейс который смотрит в провайдера, на этом интерфейсе стоит заворот wccp на squid. Пакет уходит на squid, выходит из него обратно в ту же циску и снова попадает в интерфейс который смотрит в провайдера. Тут пакет снова (согласно access-list) заворачивается в squid. Происходит зацикливание, которое нужно разорвать, если как то дать циске понять что пакеты с прокси не нужно снова заворачивать на squid... вот как то так..
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

3. "Cisco wccp, Linux TPROXY и access-list"	+/–
Сообщение от Mr. Mistoffelees on 09-Апр-13, 18:33
Привет, > Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и > интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс > Gi 0/2 и снова редиректится на прокси... А пакеты от клиента и от прокси обязательно должны приходить в один и тот же VLAN? Посмотрите в сторону получения пакетов от клиентов в одном VLAN-е от прокси - в другом. Может, тогда через route-map сможете поставить next-hop тем, которым нужно? Это только идея, конечно... WWell,
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "Cisco wccp, Linux TPROXY и access-list"	+/–
	Сообщение от lyl8000 (ok) on 09-Апр-13, 19:45
	> Привет, >> Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и >> интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс >> 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 то я бы мог разделить перенаправление на прокси, что могло решить проблему..
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "Cisco wccp, Linux TPROXY и access-list"	+/–
	Сообщение от Mr. Mistoffelees on 10-Апр-13, 16:48
	Привет, > 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,
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "Cisco wccp, Linux TPROXY и access-list"	+/–
	Сообщение от lyl8000 (ok) on 10-Апр-13, 21:59
	> Еще мысль - на прокси ставите нестандартный 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 и наоборот.. Буду пробовать. Как что - отпишусь. Спасибо!
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "Cisco wccp, Linux TPROXY и access-list"	+/–
	Сообщение от lyl8000 (ok) on 11-Апр-13, 16:52
	>[оверквотинг удален] > 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 и наоборот. Может кто подскажет как это сделать? Спасибо!
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	8. "Cisco wccp, Linux TPROXY и access-list"	+/–
	Сообщение от lyl8000 (ok) on 12-Апр-13, 23:14
	УРРРРРРРРРРРАААААААААААААААААААААААААААААААААААААААААААААААААА!!!!!!!!!!!!! у меня все получилось! В общем не нужно ничего мудрить. Ни с роут-мапами ни PBR ни VRF. Механизм WCCP все умеет САМ!!! Просто на интерфейсе к которому подключен SQUID нужно сделать: ip wccp redirect exclude in И пакеты с того интерфейса больше не будут заворачиваться на прокси. ВСЁ!!! УРА! Подчеркну еще раз: все это нужно только для случая с TPROXY. В других случаях ситуация немного другая. Блин на столько граблей наступил.. что хоть статью пиши..
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "Cisco wccp, Linux TPROXY и access-list"	+/–
	Сообщение от Aleks305 (ok) on 14-Апр-13, 00:02
	>[оверквотинг удален] > В общем не нужно ничего мудрить. Ни с роут-мапами ни PBR ни > VRF. > Механизм WCCP все умеет САМ!!! > Просто на интерфейсе к которому подключен SQUID нужно сделать: > ip wccp redirect exclude in > И пакеты с того интерфейса больше не будут заворачиваться на прокси. ВСЁ!!! > УРА! > Подчеркну еще раз: все это нужно только для случая с TPROXY. В > других случаях ситуация немного другая. > Блин на столько граблей наступил.. что хоть статью пиши.. напиши на habr, может инвайт получишь, другим полезно будет)
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору