Была задача, сделать прозрачные переброс пользователей с одного VPN (PPTPD) сервера
на другой (PPTPD), с условием, что пользователям ничего менять в настройках VPN соединения не приедеться.В итоге на несколько разных VPN серверов (Fedora 3,4,6, APSlinux 11) был установлен
прозрачный редирект туннеля на центральные сервер, с единой базой данных о клиентах.Использованное ПО:
pptpproxy-2.9.tar.bz2
Пример запуска:
#./pptpproxy -p 111.111.111.111:1723,222.222.222.222:1723 -a 10.0.0.0/255.0.0.0 -l /var/log/pptp_redirect
Параметр -p
111.111.111.111:1723 как интерфейс и порт слушать
222.222.222.222:1723 на как адрес:порт перенаправлятьПараметр -a
10.0.0.0/255.0.0.0 acl на соединение с определенное сетиПараметр -l
/var/log/pptp_redirect куда писать логТаким образом избежали множества проблем с клиентами.
В первую очередь данное ПО, как следует из названия, предназначено для проброса VPN туннелей через NAT.Использованные ОС:
APSLinux 11
CentOS 5
FedoraURL: http://www.mgix.com/pptpproxy/?about
Обсуждается: http://www.opennet.me/tips/info/1583.shtml
А возможен ли вариант - соединиться с пограничным сервером (Centos4), а потом пробросить это на 2003-й?
Я думаю ее можно использовать и для этого тоже(только acl убрать нужно будет), наверное для авторизации сразу через домен хотите??
Авторизация возможна и там, и там. Только в линуксе проще организовать доступ по дополнительным условиям - МАС, открытый ключик и т. д. Ну очень не хочется пробрасывать порт сразу на 2003-й ...
вообще говоря, переброски порта мало, нужно еще перебрасывать данные по протоколу GRE, что само по себе несколько сложнее, откуда и необходимость в возникновении проекта pptpproxy
хм. Эта софтинка позволяет релизовать механизм балансировщика нагрузки?
Т.е. у всех клиентов прописан в качестве VPN сервер на котором стоит pptpproxy, а уже сама програама перебрасывает на нормальные VPN сервера, которые и занимаются обслуживанием соединения?
Меня устроил бы даже простой механизм round robin.
Да, распределение нагрузки было бы очень интересно.
>Да, распределение нагрузки было бы очень интересно.Как вариант - маршрутизатор с несколькими линками на разных провайдеров. Иметь возможность без дополнительных проблем заходить с разных "сторон" на один внутренний сервер - уже хорошо.
Может сделать крон, пусть запускает каждый раз сервис с разным сервером назначения, на который будет перекидываться туннель =)
>Может сделать крон, пусть запускает каждый раз сервис с разным сервером назначения,Крон - это неправильно. Это балансировка по времени. А если очередной сервер мертв? Ждать, когда у крона наступит следующий момент времени?
ДНС'ом можно балансировать.
Это как? Создать несколько записей A на разные IP? И пусть он каждый раз разный сервак резолвит? Занимательно.....
>Это как? Создать несколько записей A на разные IP? И пусть он
>каждый раз разный сервак резолвит? Занимательно.....Интересно, как в таком случае с роутингом быть. Ведь адрес клиенту назначается по идее радиусом, и не зависимо от того, на каком конкретно сервере он регистрируется. И где этот адрес потом искать?
OSPF в помощь, я так думаю...
>OSPF в помощь, я так думаю...А там разве можно адреса роутить? Ну, в смысле, сетки /32.
Когда клиенту выдается адрес, он автоматически попадает в таблицу динамической маршрутизации ospf.
>Интересно, как в таком случае с роутингом быть. Ведь адрес клиенту назначается по идее >радиусом, и не зависимо от того, на каком конкретно сервере он регистрируется. И где >этот адрес потом искатьА зачем его искать? Он на том же серваке и обсчитываеться и натится. Если натить нельзя,
То роутинг прописывается по цепочке серверов ВПН, но ходить, по цепочке не будет(если впны в 1 логическом сегменте) - есть такое понятие как icmp-redirect. Ну или OSFP для гурманов :)
лучше уж xinetd
> лучше уж xinetdxinetd умеет протоколы?
зачем городить огород все делается средствами iptables
> зачем городить огород все делается средствами iptablesесть рабочие примеры?