https://opennet.dev/openforum/vsluhforumID6/673.html Добрый всем день.<br>Вобщем случилось так что пришлось прикручивать SQUID к маршрутизатору для фильтрации всяких нехороших страниц (по версии РосПотребНадзора).<br><br>Схема следующая: есть интерфейс смотрящий на провайдера, на нем ставлю правила:<br>interface GigabitEthernet 0/1<br>ip wccp 80 redirect out<br>ip wccp 90 redirect in<br><br>подробно описывать access-listы не имеет смысла, скажу проще 80 - это процесс который выбирает веб-трафик который идет внутрь сети и перенаправляет его на SQUID. Ну и соответственно 90 - процесс который перенаправляет на SQUID исходящий веб-трафик.<br><br>На SQUID включен режим TPROXY, который позволяет замутить полностью прозрачное проксирование трафика, т.е. не будет изменяться даже srcIP.<br><br>Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс Gi 0/2 и снова редиректится на прокси...<br><br>Короче происходит зацикливание исходящих пакетов..<br>Я пытался найти решение и в голову пришла мысль https://opennet.dev/openforum/vsluhforumID6/673.html#9 Sat, 13 Apr 2013 20:02:11 GMT &gt;[оверквотинг удален]<br>&gt; В общем не нужно ничего мудрить. Ни с роут-мапами ни PBR ни <br>&gt; VRF.<br>&gt; Механизм WCCP все умеет САМ!!!<br>&gt; Просто на интерфейсе к которому подключен SQUID нужно сделать: <br>&gt; ip wccp redirect exclude in <br>&gt; И пакеты с того интерфейса больше не будут заворачиваться на прокси. ВСЁ!!! <br>&gt; УРА!<br>&gt; Подчеркну еще раз: все это нужно только для случая с TPROXY. В <br>&gt; других случаях ситуация немного другая.<br>&gt; Блин на столько граблей наступил.. что хоть статью пиши..<br><br>напиши на habr, может инвайт получишь, другим полезно будет)<br> https://opennet.dev/openforum/vsluhforumID6/673.html#8 Fri, 12 Apr 2013 19:14:59 GMT УРРРРРРРРРРРАААААААААААААААААААААААААААААААААААААААААААААААААА!!!!!!!!!!!!!<br>у меня все получилось!<br>В общем не нужно ничего мудрить. Ни с роут-мапами ни PBR ни VRF.<br>Механизм WCCP все умеет САМ!!!<br>Просто на интерфейсе к которому подключен SQUID нужно сделать:<br> ip wccp redirect exclude in<br><br>И пакеты с того интерфейса больше не будут заворачиваться на прокси. ВСЁ!!!<br>УРА!<br><br>Подчеркну еще раз: все это нужно только для случая с TPROXY. В других случаях ситуация немного другая.<br>Блин на столько граблей наступил.. что хоть статью пиши..<br> https://opennet.dev/openforum/vsluhforumID6/673.html#7 Thu, 11 Apr 2013 12:52:19 GMT &gt;[оверквотинг удален]<br>&gt; VRF, тоже, наверно, вариант - вы можете запихнуть входящий пакет в соотв. <br>&gt; VRF на основании ACL или по интерфейсу откуда пришел пакет.<br>&gt; Еще мысль - на прокси ставите нестандартный TTL, на роутере в ACL <br>&gt; ловите пакеты с таким TTL и отправляете их в обход wccp. <br>&gt; В таком случае можете заменить wccp out на route map с <br>&gt; двумя клаузами - первая (по одной ACL) ловит пакеты, идущие на <br>&gt; порт 80 или 443 и ставит им next-hop проски, вторая (по <br>&gt; другой ACL) ловит пакеты из прокси (по TTL) и ставит им <br>&gt; next-hop провайдера. Входящий трафик при этом может остаться на wccp in. <br>&gt; WWell, <br><br>В общем попробовал я с route-map. Сделал вывод что ничего не получится. Не знаю, моет быть у меня какой нить ИОС кривой (124-24.Т5) но route-map работает только для входящих пакетов (на интерфейсе). А это говорит о том что не получится исключить трафик с прокси.<br><br>Последняя надежда - сделать отдельный VRF для провайдеров на циске. Но затык состоит в том что у меня не получается пробросить https://opennet.dev/openforum/vsluhforumID6/673.html#6 Wed, 10 Apr 2013 17:59:41 GMT &gt; Еще мысль - на прокси ставите нестандартный TTL, на роутере в ACL <br>&gt; ловите пакеты с таким TTL и отправляете их в обход wccp. <br>&gt; В таком случае можете заменить wccp out на route map с <br>&gt; двумя клаузами - первая (по одной ACL) ловит пакеты, идущие на <br>&gt; порт 80 или 443 и ставит им next-hop проски, вторая (по <br>&gt; другой ACL) ловит пакеты из прокси (по TTL) и ставит им <br>&gt; next-hop провайдера. Входящий трафик при этом может остаться на wccp in. <br>&gt; WWell, <br><br>Вот и я в итоге пришел к тому что нужно заменять ip wccp на route-map.<br>Жаль конечно, но придется.. Хотя дополнительный VRF мог бы решить эту проблему. Но не могу никак пробросить трафик из VRF в global и наоборот..<br><br>Буду пробовать. Как что - отпишусь.<br><br>Спасибо!<br> https://opennet.dev/openforum/vsluhforumID6/673.html#5 Wed, 10 Apr 2013 12:48:22 GMT Привет,<br><br>&gt; P.S. Была идея сделать VRF типа бордер-зоны, но я не совсем понял <br>&gt; как связывать два VRF (или VRF и global).<br><br>VRF, тоже, наверно, вариант - вы можете запихнуть входящий пакет в соотв. VRF на основании ACL или по интерфейсу откуда пришел пакет. <br><br>Еще мысль - на прокси ставите нестандартный TTL, на роутере в ACL ловите пакеты с таким TTL и отправляете их в обход wccp. В таком случае можете заменить wccp out на route map с двумя клаузами - первая (по одной ACL) ловит пакеты, идущие на порт 80 или 443 и ставит им next-hop проски, вторая (по другой ACL) ловит пакеты из прокси (по TTL) и ставит им next-hop провайдера. Входящий трафик при этом может остаться на wccp in. <br><br>WWell,<br><br><br><br><br><br><br><br> https://opennet.dev/openforum/vsluhforumID6/673.html#4 Tue, 09 Apr 2013 15:45:09 GMT &gt; Привет, <br>&gt;&gt; Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и <br>&gt;&gt; интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс <br>&gt;&gt; Gi 0/2 и снова редиректится на прокси...<br>&gt; А пакеты от клиента и от прокси обязательно должны приходить в один <br>&gt; и тот же VLAN? Посмотрите в сторону получения пакетов от клиентов <br>&gt; в одном VLAN-е от прокси - в другом. Может, тогда <br>&gt; через route-map сможете поставить next-hop тем, которым нужно? Это только идея, <br>&gt; конечно...<br>&gt; WWell, <br><br>Привет, хорошая идея, но практики с роут-мапами у меня не много, и поэтому сразу возникает вопрос: <br>1. Если я ставлю route-map на интерфейсе (на который из прокси прилетают пакеты) и говорю что ip nex-hop $ITSP_IP (чтоб все пакеты шли на провайдера) не будет ли пакет отфильтрован на интерфейсе смотрящем в провайдера (а там стоит ip wccp 100 out т.е. перенаправление на прокси) ?<br><br>2. Если ставить route-map на интерфейсе смотрящем в провайдера... <br> а) Какой порядок обработки будет https://opennet.dev/openforum/vsluhforumID6/673.html#3 Tue, 09 Apr 2013 14:33:41 GMT Привет,<br><br>&gt; Вот такая схема. И с ней возникает проблема: исходящий пакет заворачивается и <br>&gt; интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс <br>&gt; Gi 0/2 и снова редиректится на прокси...<br><br>А пакеты от клиента и от прокси обязательно должны приходить в один и тот же VLAN? Посмотрите в сторону получения пакетов от клиентов в одном VLAN-е от прокси - в другом. Может, тогда через route-map сможете поставить next-hop тем, которым нужно? Это только идея, конечно... <br><br>WWell,<br><br> https://opennet.dev/openforum/vsluhforumID6/673.html#2 Tue, 09 Apr 2013 08:01:24 GMT &gt; Потому что прокся внутри сети, а wccp снаружи.<br>&gt; Вроде обратный трафик с прокси идет не через gre.<br><br>Привет.<br>На самом деле и исходящий и входящий трафик заворачивается на прокси с внешнего интерфейса через gre, а с прокси обратно выплевывается уже без gre. <br><br>В принципе в данном случае это не важно, вопрос в другом, как отделить пакеты с прокси от пакетов клиентов (которые еще не проходили прокси) используя access-list.<br><br>Повторюсь - squid работает в TPROXY режиме, т.е. прокси не подменяет адрес источника свои адресом.<br><br>И еще раз про зацикливание пакета. Пакет идет от клиента и заходит в маршрутизатор (Cisco 7206), на цыско есть интерфейс который смотрит в провайдера, на этом интерфейсе стоит заворот wccp на squid. Пакет уходит на squid, выходит из него обратно в ту же циску и снова попадает в интерфейс который смотрит в провайдера. Тут пакет снова (согласно access-list) заворачивается в squid.<br>Происходит зацикливание, которое нужно разорвать, если как то дать циске понять что пакеты с прокси не нужн https://opennet.dev/openforum/vsluhforumID6/673.html#1 Mon, 08 Apr 2013 18:45:37 GMT &gt;[оверквотинг удален]<br>&gt; интерфейса на прокси, проходит прокси, выходит обратно в маршрутизатор в интерфейс <br>&gt; Gi 0/2 и снова редиректится на прокси...<br>&gt; Короче происходит зацикливание исходящих пакетов..<br>&gt; Я пытался найти решение и в голову пришла мысль что нужно как-то <br>&gt; отфильтровывать трафик с интерфейса Gi 0/2 чтобы он не редиректился снова <br>&gt; на прокси..<br>&gt; И собственно вопрос - есть ли какие нить механизмы учитывать в ACL <br>&gt; интерфейс с которого идет пакет?<br>&gt; Повторюсь: прокси НЕ подставляет свой IP адрес, адрес источника сохраняется.<br>&gt; Заранее спасибо.<br><br>Потому что прокся внутри сети, а wccp снаружи.<br>Вроде обратный трафик с прокси идет не через gre.<br><br>