forum.opennet.ru

Форум Оптимизация и Промышленные системы (Увеличение масштабируемости)
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

увеличения масштабируемости VPN-сервера?, Luxor (??), 21-Июл-09, (0) [смотреть все]

code Я вообще не зациклен на кластере code ну и правильно что не зацикленыбери, shadow_alone (ok), 21:26 , 21-Июл-09, (1) //

Не совсем понял идею, у меня HP DL380 G5 2 двухядерных Xeon-а 3 GHz серии 5160, , Luxor (??), 00:15 , 22-Июл-09, (2) //

Я и подсказываю именно в этом направлении Был когда-то П4 2,2 1Г памяти, на нем , shadow_alone (ok), 00:28 , 22-Июл-09, (3) //

Нашему пограничному маршрутизатору Cisco 7206VXR NPE-G2 и так немного осталось , Luxor (??), 10:20 , 22-Июл-09, (4)

gt оверквотинг удален Мне кажется, Вы правильно шли в нужном направлении Вам , Refresh (?), 12:03 , 22-Июл-09, (5)

gt оверквотинг удален ух ты, с помощью ipfw можно перенапрвить установку vpn-с, егерь (?), 12:25 , 22-Июл-09, (6)

gt оверквотинг удален Refresh не томите расскажите как перенаправить устано, Luxor (??), 15:52 , 22-Июл-09, (7)

gt оверквотинг удален http www opennet ru base net ipfw_balance txt htmlЯ бы, Refresh (?), 17:52 , 23-Июл-09, (8)

gt оверквотинг удален В качестве 10 0 1 1 и 10 1 1 1 вы рассматриваете IP-адре, Monty (??), 22:47 , 23-Июл-09, (9)

gt оверквотинг удален То где это делается - назовем интернет-сервер На нем f, Refresh (?), 17:54 , 24-Июл-09, (10)

pptp нормально можно раскидывать только slbу циски есть ширпотребные железки для, chocholl (??), 15:47 , 04-Авг-09, (11)

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

1. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от shadow_alone (ok), 21-Июл-09, 21:26

>Здравствуйте!
>VPN-сервер (пользователи подключаются к нему по протоколу pptp) очень загружен, обратил взор
>на кластерную технологию.
Я вообще не зациклен на кластере

ну и правильно что не зациклены
берите нормальный рутер, и на серваке радиус+DB (mysql, postgresql - не суть важно)
если очень нагружен, то советую 72 или 73 серию, если средненько, то и 28 серия пойдет.

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

2. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от Luxor (??), 22-Июл-09, 00:15

>>Здравствуйте!
>>VPN-сервер (пользователи подключаются к нему по протоколу pptp) очень загружен, обратил взор
>>на кластерную технологию.
>
>
Я вообще не зациклен на кластере

>ну и правильно что не зациклены
>берите нормальный рутер, и на серваке радиус+DB (mysql, postgresql - не суть
>важно)
>если очень нагружен, то советую 72 или 73 серию, если средненько, то
>и 28 серия пойдет.
Не совсем понял идею, у меня HP DL380 G5 2 двухядерных Xeon-а 3 GHz серии 5160, 4 гига   фирменной оперативки от HP, на нем уже все поднято и работает. Конкретно на нем поднят mpd, ОС FreeBSD 7.0. Сервер вянет когда количество тунелей переваливает за 1200.
Решить проблему можно купив более мощный сервер, а потом когди он не будет справляться опять более мощный сервер. Мне бы хотелось решить эту задачу поднятие дополнительных серверов... так экономически выгоднее :) подскажите пожалуйста что-нибудь в этом направлении.

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

3. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от shadow_alone (ok), 22-Июл-09, 00:28

Я и подсказываю именно в этом направлении.
Был когда-то П4 2,2 1Г памяти, на нем были подключены порядка 140-150 юзеров(pptp - mschap2) (Linux)
Стал загибаться, решил тож делать кластер - слава Богу, умные люди подсказали в свое время не париться и взять 2811 с крипто модулем. Мискл и радиус оставил на серваке, со временем, поменял её на 7306, сейчас порядка 1000 юзеров +12 туннелей ipsec
всё работает без проблем - зачем изобретать велосипед, когда уже есть ДВС :)

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

4. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от Luxor (??), 22-Июл-09, 10:20

>Я и подсказываю именно в этом направлении.
>Был когда-то П4 2,2 1Г памяти, на нем были подключены порядка 140-150
>юзеров(pptp - mschap2) (Linux)
>Стал загибаться, решил тож делать кластер - слава Богу, умные люди подсказали
>в свое время не париться и взять 2811 с крипто модулем.
>Мискл и радиус оставил на серваке, со временем, поменял её на
>7306, сейчас порядка 1000 юзеров +12 туннелей ipsec
>всё работает без проблем - зачем изобретать велосипед, когда уже есть ДВС
>:)
Нашему пограничному маршрутизатору Cisco 7206VXR NPE-G2 и так немного осталось (по вечерам загрузка 70%), перенести на него VPN это подписать ему смертный приговор. Вообще раньше когда пользователей было немного 7206 выполняла функции и VPN-а и NAT, с увеличением числа пользователей пришлось перекинуть на отдельный сервер VPN и NAT, и вот сейчас опять же из-за увеличения числа пользователей необходимо как-то решить проблему с повышенной загрузкой сервера терминирующего VPN, денег купить супермощный сервер сейчас нет, но купить сервер такой же по мощности как существующий возможность есть... есть ли все-таки варианты с распредлением нагрузки между двумя серверами работающими под одним ip

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

5. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от Refresh (?), 22-Июл-09, 12:03

>[оверквотинг удален]
>
>Нашему пограничному маршрутизатору Cisco 7206VXR NPE-G2 и так немного осталось (по вечерам
>загрузка 70%), перенести на него VPN это подписать ему смертный приговор.
>Вообще раньше когда пользователей было немного 7206 выполняла функции и VPN-а
>и NAT, с увеличением числа пользователей пришлось перекинуть на отдельный сервер
>VPN и NAT, и вот сейчас опять же из-за увеличения числа
>пользователей необходимо как-то решить проблему с повышенной загрузкой сервера терминирующего VPN,
>денег купить супермощный сервер сейчас нет, но купить сервер такой же
>по мощности как существующий возможность есть... есть ли все-таки варианты с
>распредлением нагрузки между двумя серверами работающими под одним ip
Мне кажется, Вы правильно шли в нужном направлении. Вам нужно N внешних IP и несколько A-записей в DNS. Если нужно будет распределить нагрузку не поровну м/у серверами... Скажем Вам нехватает чуть-чуть мощности, вы покупаете сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50|35|15). Для оптимизации производительности БД юзеров и RADIUS лучше вынести на выделенный сервер.

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

6. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от егерь (?), 22-Июл-09, 12:25

>[оверквотинг удален]
>>денег купить супермощный сервер сейчас нет, но купить сервер такой же
>>по мощности как существующий возможность есть... есть ли все-таки варианты с
>>распредлением нагрузки между двумя серверами работающими под одним ip
>
>Мне кажется, Вы правильно шли в нужном направлении. Вам нужно N внешних
>IP и несколько A-записей в DNS. Если нужно будет распределить нагрузку
>не поровну м/у серверами... Скажем Вам нехватает чуть-чуть мощности, вы покупаете
>сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете
>входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50|35|15). Для оптимизации производительности
>БД юзеров и RADIUS лучше вынести на выделенный сервер.
ух ты, с помощью ipfw можно перенапрвить установку vpn-соединения на сервер с другим ip ? даже не знал что так можно, а можете примерчик  примерный показать ?

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

7. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от Luxor (??), 22-Июл-09, 15:52

>[оверквотинг удален]
>>Мне кажется, Вы правильно шли в нужном направлении. Вам нужно N внешних
>>IP и несколько A-записей в DNS. Если нужно будет распределить нагрузку
>>не поровну м/у серверами... Скажем Вам нехватает чуть-чуть мощности, вы покупаете
>>сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете
>>входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50|35|15). Для оптимизации производительности
>>БД юзеров и RADIUS лучше вынести на выделенный сервер.
>
>ух ты, с помощью ipfw можно перенапрвить установку vpn-соединения на сервер с
>другим ip ? даже не знал что так можно, а можете
>примерчик  примерный показать ?
Refresh не томите :) расскажите как перенаправить установку соединения с другим VPN-сервером с помощью ipfw

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

8. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от Refresh (?), 23-Июл-09, 17:52

>[оверквотинг удален]
>>>сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете
>>>входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50|35|15). Для оптимизации производительности
>>>БД юзеров и RADIUS лучше вынести на выделенный сервер.
>>
>>ух ты, с помощью ipfw можно перенапрвить установку vpn-соединения на сервер с
>>другим ip ? даже не знал что так можно, а можете
>>примерчик  примерный показать ?
>
>Refresh не томите :) расскажите как перенаправить установку соединения с другим VPN-сервером
>с помощью ipfw
http://www.opennet.dev/base/net/ipfw_balance.txt.html
Я бы попробовал вот отсюда кусок:
В  ipfw тоже есть возможность реализовать нечто подобное, но на другом
   принципе.  Здесь  в правило можно включить опцию prob N, где N - число
   от   0   до  1,  указывающее  вероятность,  с  которой  правило  будет
   применяться  к  пакетам,  подходящим  по остальным критериям. В паре с
   действием skipto можно попробовать реализовать нечто подобное:
           ipfw add 500 check-state
           ipfw add 1000 prob 0.4 skipto 2000 ip from any to any in via ed0
           ipfw  add  1500  fwd  10.0.1.1  ip  from  192.168.0.0/24  to  any out keep-state
           ipfw  add  2000  fwd  10.1.1.1  ip  from  192.168.0.0/24  to  any out keep-state

   Правило  1000,  имея в своём составе опцию prob 0.4, будет выполняться
   для   всех  исходящих  пакетов  (с  точки  зрения  пользователей;  для
   FreeBSD-шлюза  это будут входящие пакеты на внутреннем интерфейсе, что
   и  отражается  опциями  in  via  ed0)  с  вероятностью  40%.  Эти  40%
   "счастливчиков" будут перебрасываться на правило 2000, которым будут
   отправляться  в  шлюз  интерфейса  rl1  (хотя,  поскольку  это шлюз по
   умолчанию, можно было бы ограничиться действием allow). Оставшиеся 60%
   пакетов  продолжат свой путь и правилом 1500 будут переброшены на шлюз
   интерфейса  rl0.  Важной  особенностью  здесь  является  наличие опций
   keep-state  -  благодаря им под "пробу" будет попадать только первый
   пакет устанавливаемого соединения, а все остальные пакеты подпадут под
   действие  правила  check-state, которое должно быть указано до правила
   skipto, чтобы избежать "разрыва" уже установленной сессии. Поскольку
   динамические  правила  сохраняют  первоначальное  действие  (в  данном
   случае  forward),  то  все  пакеты соединения будут отправляться через
   указанный шлюз.

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

9. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от Monty (??), 23-Июл-09, 22:47

>[оверквотинг удален]
>add 500 check-state
>           ipfw
>add 1000 prob 0.4 skipto 2000 ip from any to any
>in via ed0
>           ipfw
> add  1500  fwd  10.0.1.1  ip
>from  192.168.0.0/24  to  any out keep-state
>           ipfw
> add  2000  fwd  10.1.1.1  ip
>from  192.168.0.0/24  to  any out keep-state
В качестве 10.0.1.1 и 10.1.1.1 вы рассматриваете IP-адреса VPN-серверов. Если так, то так не молочится, имхо. Ибо тут должны рассматриваться адреса маршрутизаторов или иже с ними.
К каком адресу должен по вашему клиент подключаться?

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

10. "увеличения масштабируемости VPN-сервера?" +/–

Сообщение от Refresh (?), 24-Июл-09, 17:54

>[оверквотинг удален]
>> add  1500  fwd  10.0.1.1  ip
>>from  192.168.0.0/24  to  any out keep-state
>>           ipfw
>> add  2000  fwd  10.1.1.1  ip
>>from  192.168.0.0/24  to  any out keep-state
>
>В качестве 10.0.1.1 и 10.1.1.1 вы рассматриваете IP-адреса VPN-серверов. Если так, то
>так не молочится, имхо. Ибо тут должны рассматриваться адреса маршрутизаторов или
>иже с ними.
>К каком адресу должен по вашему клиент подключаться?
То где это делается - назовем интернет-сервер.. На нем fwd может перенаправить ЛЮБЫЕ подключения, в том числе и внешние, на ЛЮБОЙ интерфейс, в том числе и на внутренний (при настроенном NAT-е). Если мне не изменяет память fwd тупо перезаписывает заголовок пакета в цепочке.. Поэтому разместив данную конструкцию выше NAT, Вы сможете разрулировать с вероятностью prob ЛЮБЫЕ пакеты м/у любыми внутренними серверами. Если я ошибаюсь, поправьте меня.

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

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

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

Партнёры:

Хостинг:

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

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

1. "увеличения масштабируемости VPN-сервера?"	+/–
Сообщение от shadow_alone (ok), 21-Июл-09, 21:26
>Здравствуйте! >VPN-сервер (пользователи подключаются к нему по протоколу pptp) очень загружен, обратил взор >на кластерную технологию. Я вообще не зациклен на кластере ну и правильно что не зациклены берите нормальный рутер, и на серваке радиус+DB (mysql, postgresql - не суть важно) если очень нагружен, то советую 72 или 73 серию, если средненько, то и 28 серия пойдет.
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "увеличения масштабируемости VPN-сервера?"	+/–
	Сообщение от Luxor (??), 22-Июл-09, 00:15
	>>Здравствуйте! >>VPN-сервер (пользователи подключаются к нему по протоколу pptp) очень загружен, обратил взор >>на кластерную технологию. > > Я вообще не зациклен на кластере >ну и правильно что не зациклены >берите нормальный рутер, и на серваке радиус+DB (mysql, postgresql - не суть >важно) >если очень нагружен, то советую 72 или 73 серию, если средненько, то >и 28 серия пойдет. Не совсем понял идею, у меня HP DL380 G5 2 двухядерных Xeon-а 3 GHz серии 5160, 4 гига фирменной оперативки от HP, на нем уже все поднято и работает. Конкретно на нем поднят mpd, ОС FreeBSD 7.0. Сервер вянет когда количество тунелей переваливает за 1200. Решить проблему можно купив более мощный сервер, а потом когди он не будет справляться опять более мощный сервер. Мне бы хотелось решить эту задачу поднятие дополнительных серверов... так экономически выгоднее :) подскажите пожалуйста что-нибудь в этом направлении.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "увеличения масштабируемости VPN-сервера?"	+/–
	Сообщение от shadow_alone (ok), 22-Июл-09, 00:28
	Я и подсказываю именно в этом направлении. Был когда-то П4 2,2 1Г памяти, на нем были подключены порядка 140-150 юзеров(pptp - mschap2) (Linux) Стал загибаться, решил тож делать кластер - слава Богу, умные люди подсказали в свое время не париться и взять 2811 с крипто модулем. Мискл и радиус оставил на серваке, со временем, поменял её на 7306, сейчас порядка 1000 юзеров +12 туннелей ipsec всё работает без проблем - зачем изобретать велосипед, когда уже есть ДВС :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "увеличения масштабируемости VPN-сервера?"	+/–
	Сообщение от Luxor (??), 22-Июл-09, 10:20
	>Я и подсказываю именно в этом направлении. >Был когда-то П4 2,2 1Г памяти, на нем были подключены порядка 140-150 >юзеров(pptp - mschap2) (Linux) >Стал загибаться, решил тож делать кластер - слава Богу, умные люди подсказали >в свое время не париться и взять 2811 с крипто модулем. >Мискл и радиус оставил на серваке, со временем, поменял её на >7306, сейчас порядка 1000 юзеров +12 туннелей ipsec >всё работает без проблем - зачем изобретать велосипед, когда уже есть ДВС >:) Нашему пограничному маршрутизатору Cisco 7206VXR NPE-G2 и так немного осталось (по вечерам загрузка 70%), перенести на него VPN это подписать ему смертный приговор. Вообще раньше когда пользователей было немного 7206 выполняла функции и VPN-а и NAT, с увеличением числа пользователей пришлось перекинуть на отдельный сервер VPN и NAT, и вот сейчас опять же из-за увеличения числа пользователей необходимо как-то решить проблему с повышенной загрузкой сервера терминирующего VPN, денег купить супермощный сервер сейчас нет, но купить сервер такой же по мощности как существующий возможность есть... есть ли все-таки варианты с распредлением нагрузки между двумя серверами работающими под одним ip
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "увеличения масштабируемости VPN-сервера?"	+/–
	Сообщение от Refresh (?), 22-Июл-09, 12:03
	>[оверквотинг удален] > >Нашему пограничному маршрутизатору Cisco 7206VXR NPE-G2 и так немного осталось (по вечерам >загрузка 70%), перенести на него VPN это подписать ему смертный приговор. >Вообще раньше когда пользователей было немного 7206 выполняла функции и VPN-а >и NAT, с увеличением числа пользователей пришлось перекинуть на отдельный сервер >VPN и NAT, и вот сейчас опять же из-за увеличения числа >пользователей необходимо как-то решить проблему с повышенной загрузкой сервера терминирующего VPN, >денег купить супермощный сервер сейчас нет, но купить сервер такой же >по мощности как существующий возможность есть... есть ли все-таки варианты с >распредлением нагрузки между двумя серверами работающими под одним ip Мне кажется, Вы правильно шли в нужном направлении. Вам нужно N внешних IP и несколько A-записей в DNS. Если нужно будет распределить нагрузку не поровну м/у серверами... Скажем Вам нехватает чуть-чуть мощности, вы покупаете сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50\|35\|15). Для оптимизации производительности БД юзеров и RADIUS лучше вынести на выделенный сервер.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "увеличения масштабируемости VPN-сервера?"	+/–
	Сообщение от егерь (?), 22-Июл-09, 12:25
	>[оверквотинг удален] >>денег купить супермощный сервер сейчас нет, но купить сервер такой же >>по мощности как существующий возможность есть... есть ли все-таки варианты с >>распредлением нагрузки между двумя серверами работающими под одним ip > >Мне кажется, Вы правильно шли в нужном направлении. Вам нужно N внешних >IP и несколько A-записей в DNS. Если нужно будет распределить нагрузку >не поровну м/у серверами... Скажем Вам нехватает чуть-чуть мощности, вы покупаете >сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете >входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50\|35\|15). Для оптимизации производительности >БД юзеров и RADIUS лучше вынести на выделенный сервер. ух ты, с помощью ipfw можно перенапрвить установку vpn-соединения на сервер с другим ip ? даже не знал что так можно, а можете примерчик примерный показать ?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "увеличения масштабируемости VPN-сервера?"	+/–
	Сообщение от Luxor (??), 22-Июл-09, 15:52
	>[оверквотинг удален] >>Мне кажется, Вы правильно шли в нужном направлении. Вам нужно N внешних >>IP и несколько A-записей в DNS. Если нужно будет распределить нагрузку >>не поровну м/у серверами... Скажем Вам нехватает чуть-чуть мощности, вы покупаете >>сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете >>входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50\|35\|15). Для оптимизации производительности >>БД юзеров и RADIUS лучше вынести на выделенный сервер. > >ух ты, с помощью ipfw можно перенапрвить установку vpn-соединения на сервер с >другим ip ? даже не знал что так можно, а можете >примерчик примерный показать ? Refresh не томите :) расскажите как перенаправить установку соединения с другим VPN-сервером с помощью ipfw
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "увеличения масштабируемости VPN-сервера?"	+/–
	Сообщение от Refresh (?), 23-Июл-09, 17:52
	>[оверквотинг удален] >>>сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете >>>входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50\|35\|15). Для оптимизации производительности >>>БД юзеров и RADIUS лучше вынести на выделенный сервер. >> >>ух ты, с помощью ipfw можно перенапрвить установку vpn-соединения на сервер с >>другим ip ? даже не знал что так можно, а можете >>примерчик примерный показать ? > >Refresh не томите :) расскажите как перенаправить установку соединения с другим VPN-сервером >с помощью ipfw http://www.opennet.dev/base/net/ipfw_balance.txt.html Я бы попробовал вот отсюда кусок: В ipfw тоже есть возможность реализовать нечто подобное, но на другом принципе. Здесь в правило можно включить опцию prob N, где N - число от 0 до 1, указывающее вероятность, с которой правило будет применяться к пакетам, подходящим по остальным критериям. В паре с действием skipto можно попробовать реализовать нечто подобное: ipfw add 500 check-state ipfw add 1000 prob 0.4 skipto 2000 ip from any to any in via ed0 ipfw add 1500 fwd 10.0.1.1 ip from 192.168.0.0/24 to any out keep-state ipfw add 2000 fwd 10.1.1.1 ip from 192.168.0.0/24 to any out keep-state Правило 1000, имея в своём составе опцию prob 0.4, будет выполняться для всех исходящих пакетов (с точки зрения пользователей; для FreeBSD-шлюза это будут входящие пакеты на внутреннем интерфейсе, что и отражается опциями in via ed0) с вероятностью 40%. Эти 40% "счастливчиков" будут перебрасываться на правило 2000, которым будут отправляться в шлюз интерфейса rl1 (хотя, поскольку это шлюз по умолчанию, можно было бы ограничиться действием allow). Оставшиеся 60% пакетов продолжат свой путь и правилом 1500 будут переброшены на шлюз интерфейса rl0. Важной особенностью здесь является наличие опций keep-state - благодаря им под "пробу" будет попадать только первый пакет устанавливаемого соединения, а все остальные пакеты подпадут под действие правила check-state, которое должно быть указано до правила skipto, чтобы избежать "разрыва" уже установленной сессии. Поскольку динамические правила сохраняют первоначальное действие (в данном случае forward), то все пакеты соединения будут отправляться через указанный шлюз.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "увеличения масштабируемости VPN-сервера?"	+/–
	Сообщение от Monty (??), 23-Июл-09, 22:47
	>[оверквотинг удален] >add 500 check-state > ipfw >add 1000 prob 0.4 skipto 2000 ip from any to any >in via ed0 > ipfw > add 1500 fwd 10.0.1.1 ip >from 192.168.0.0/24 to any out keep-state > ipfw > add 2000 fwd 10.1.1.1 ip >from 192.168.0.0/24 to any out keep-state В качестве 10.0.1.1 и 10.1.1.1 вы рассматриваете IP-адреса VPN-серверов. Если так, то так не молочится, имхо. Ибо тут должны рассматриваться адреса маршрутизаторов или иже с ними. К каком адресу должен по вашему клиент подключаться?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "увеличения масштабируемости VPN-сервера?"	+/–
	Сообщение от Refresh (?), 24-Июл-09, 17:54
	>[оверквотинг удален] >> add 1500 fwd 10.0.1.1 ip >>from 192.168.0.0/24 to any out keep-state >> ipfw >> add 2000 fwd 10.1.1.1 ip >>from 192.168.0.0/24 to any out keep-state > >В качестве 10.0.1.1 и 10.1.1.1 вы рассматриваете IP-адреса VPN-серверов. Если так, то >так не молочится, имхо. Ибо тут должны рассматриваться адреса маршрутизаторов или >иже с ними. >К каком адресу должен по вашему клиент подключаться? То где это делается - назовем интернет-сервер.. На нем fwd может перенаправить ЛЮБЫЕ подключения, в том числе и внешние, на ЛЮБОЙ интерфейс, в том числе и на внутренний (при настроенном NAT-е). Если мне не изменяет память fwd тупо перезаписывает заголовок пакета в цепочке.. Поэтому разместив данную конструкцию выше NAT, Вы сможете разрулировать с вероятностью prob ЛЮБЫЕ пакеты м/у любыми внутренними серверами. Если я ошибаюсь, поправьте меня.
	Ответить \| Правка \| Наверх \| Cообщить модератору