форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Настройка Squid и других прокси серверов (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Разные маршруты исходящих запросов"

Сообщение от Septima (ok) on 06-Ноя-06, 16:20

Есть сквид на фре, сетка предприятия, два наружних канала. Из-за некоторых особенностей географической топологии организован третий внешний канал, но далеко от маршрутизатора. Народ побит на группы и ходит по разным внешним каналам через tcp_outgoing_address. Третий шлюз организован на железке по имени Vigor-3300. Через нее ходят некие сервисы типа VoIP. Железка в одной подсети со шлюзом. Необходимо некую группу народа завернуть на третий канал. Не могу сообразить - как это сделать. В голову приходит только непростой вариант с неслабым участием ipfw или другого товарища. Трафик через сквид самый разнообразный - icq, http[s], skype и другое, что только может придумать больная фантазия пользователя. Т.е., просто выделить список портов, куда ходит народ, не получится, а затыки в сервисе крайне нежелательны. У кого есть мысли про это?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени, UBB]

1. "Разные маршруты исходящих запросов"

Сообщение от Sloboda (??) on 06-Ноя-06, 16:57

Насколько я понимаю, третью группу можно собрать в сквиде под ацл-ем? Дальше для неё либо tcp_outgoing_address (и поднять ещё один alias) либо выставить TOS (не помню точно, как директива называется, что-то аналогичное). Далее эти пакеты зароутить на третий канал. В линухе это было бы правилами iproute2, в фре, увы, не знаю.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Разные маршруты исходящих запросов"
	Сообщение от Septima (ok) on 07-Ноя-06, 17:07
	>Насколько я понимаю, третью группу можно собрать в сквиде под ацл-ем? >Дальше для неё либо tcp_outgoing_address (и поднять ещё один alias) либо выставить >TOS (не помню точно, как директива называется, что-то аналогичное). >Далее эти пакеты зароутить на третий канал. В линухе это было бы >правилами iproute2, в фре, увы, не знаю. В acl собрать народ не проблема. Проблема с алиасами - маршрут по умолчанию идет на один из внешних линков, а нужный мне роутер для группы - в моей же подсети. Через TOS не пробовал пока, а сейчас пытаюсь через два squid-а через cache-peer. На основном прокси делаю: cache_peer proxy2_IP sibling 3128 3130 default acl test src client_IP cache_peer_access proxy2_IP allow test И - ничего: не ходят запросы на peer. :( Или, если ходят (в зависимости от комбинации options для cache_peer proxy2_IP), но только проверяется наличие в кэше и затем идет опять напрямую, т.к., в кэше объекта нет. :(
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Разные маршруты исходящих запросов"
	Сообщение от Sloboda (??) on 07-Ноя-06, 18:04
	>В acl собрать народ не проблема. Проблема с алиасами - маршрут по >умолчанию идет на один из внешних линков, а нужный мне роутер >для группы - в моей же подсети. Через TOS не пробовал Ок, попробую ещё раз. Под алиасом я подразумевал ещё один ай-пи адрес на интерфейсе, который в сети с нужным (3-им) роутером. И tcp_outgoind_address с этого адреса. Либо выставить TOS. Далее, и в том, и в другом случае настроить более сложную маршрутизацию, чем шлюз по умолчанию - на основе либо ай-пи, либо TOSa. Увы, БСД-шные средства я для этого не знаю, но уверен, что они есть. >пока, а сейчас пытаюсь через два squid-а через cache-peer. На основном >прокси делаю: можно и так, но, имхо, так получиться система "Нипель" - слишком сложно и ненадежно. >cache_peer proxy2_IP sibling 3128 3130 default >acl test src client_IP >cache_peer_access proxy2_IP allow test > >И - ничего: не ходят запросы на peer. :( Или, если ходят >(в зависимости от комбинации options для cache_peer proxy2_IP), но только проверяется >наличие в кэше и затем идет опять напрямую, т.к., в кэше >объекта нет. :( Почему sibling, а не parent? Ну и cache_peer_access-ами всё разруливать. И ещё [always|never|_direct-ами подправлять. Предлагаю всё же этот вариант не развивать, а узнать как реализуется в FreeBSD advanced routing типа линухового iproute2.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Разные маршруты исходящих запросов"
	Сообщение от Trusov Sergey on 14-Ноя-06, 12:01
	>>В acl собрать народ не проблема. Проблема с алиасами - маршрут по >>умолчанию идет на один из внешних линков, а нужный мне роутер >>для группы - в моей же подсети. Через TOS не пробовал >Ок, попробую ещё раз. Под алиасом я подразумевал ещё один ай-пи адрес > >на интерфейсе, который в сети с нужным (3-им) роутером. И tcp_outgoind_address >с этого адреса. Либо выставить TOS. >Далее, и в том, и в другом случае настроить более сложную маршрутизацию, > >чем шлюз по умолчанию - на основе либо ай-пи, либо TOSa. Увы, >БСД-шные средства >я для этого не знаю, но уверен, что они есть. > >>пока, а сейчас пытаюсь через два squid-а через cache-peer. На основном >>прокси делаю: >можно и так, но, имхо, так получиться система "Нипель" - слишком сложно >и ненадежно. > >>cache_peer proxy2_IP sibling 3128 3130 default >>acl test src client_IP >>cache_peer_access proxy2_IP allow test >> >>И - ничего: не ходят запросы на peer. :( Или, если ходят >>(в зависимости от комбинации options для cache_peer proxy2_IP), но только проверяется >>наличие в кэше и затем идет опять напрямую, т.к., в кэше >>объекта нет. :( > >Почему sibling, а не parent? Ну и cache_peer_access-ами всё разруливать. >И ещё [always|never|_direct-ами подправлять. > >Предлагаю всё же этот вариант не развивать, а узнать как реализуется >в FreeBSD advanced routing типа линухового iproute2. ipfw fwd далее по ману
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]