Исходное сообщение
"увеличения масштабируемости VPN-сервера?" Отправлено Refresh, 23-Июл-09 17:52
>[оверквотинг удален] >>>сервер в 2-е менее производительный, чем основной. Далее средствами ipfw разруливаете >>>входящие VPN-соединения с необходимой вероятностью м/у VPN-серверами (50|35|15). Для оптимизации производительности >>>БД юзеров и RADIUS лучше вынести на выделенный сервер. >> >>ух ты, с помощью ipfw можно перенапрвить установку vpn-соединения на сервер с >>другим ip ? даже не знал что так можно, а можете >>примерчик  примерный показать ? > >Refresh не томите :) расскажите как перенаправить установку соединения с другим VPN-сервером >с помощью ipfw http://www.opennet.ru/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),  то  все  пакеты соединения будут отправляться через    указанный шлюз.