Off: FreeBSD и VPN?

Хочется:
подключить к локалке (192.168.x.x), собраной за гейтом на FreeBSD (4.7.... рассматривается переход на 4-STABLE) клиента (ms-win) из другого города.
Чтобы тот попал в локалку (192.168.x.x) и соответственно пользовал всякие "локальные" сервисы ... в плоть до 1С-SQL (от SQL версии - трафик приемлемый ИМХО ... должно работать)

Сделано:
1. поставлен poptop (pptpd), с одного хопа - цепляется нормально, VPN устанавливается, все работает, уходим на другой конец города (9 хопов по трэйсрауту) - соединение не устанавливается ...... пол-минуты ломится- и отпадывает по 619 ошибке
(через 3 хопа - соединние устанавливается - но рвется через пару минут ...)
2. поставлен mpd, то-же самое ....

Вопросы:
1. Как заставить не падать VPN через несколько хопов и вообще соединятся "из-далека"? (настройки всяческие крутил - эффекта - не достиг .... ошибка 619 - и все)
2. какой еще софт кроме poptop и mpd можно поставить в качестве VPN-Сервера на FreeBSD?
3. возможно ли вообще "из другого города" пробросить стабильно работающий туннель (связь по ip "туда" - стабильная ... тот клиент через авторизацию получает и посылает почту с е-бургского сервака без проблем .... "до туда" канал нормальный ....)
4. что я еще забыл ..... всвязи с этим ....

Спасибо.

OpenVPN.
Использует свой клиент под винду.

Ваще надо просто смотреть настройки...
у меня сейчас порядка 7 каналог VPN работает между БСДишными машинами (7-20 хопов между ними). связь отлично держится ниче не падает - лишь бы коннект был на обоих концах. никаких ошибок.

и плюс один канал - на одном конце mpd под бсдей (закладка VPN в mpd.conf), на втором винда - но не через "создать новое подкллючение" в сетевом окружении (хотя и это тоже работает!) а через "маршрутизация и удаленный доступ" - "создать новый интерфейс". Ниче не падает... (а так сделано потому что там есть режим "всегда подключен", в отличие от создания через сетевое окружение - где надо активизировать вручную)

КСТАТИ - покопайся в настройках на стороне винды - там есть фича - "отключать через стока-то минут простоя"...

Да и еще по теме - в таком случае лучше внутри ставить машину на 2003 (или 2000 сервер) и ходиь в режиме терминала - так будет намного надежнее, быстрее. Кроме того будет неопасны отключения (в отличие от удаленного использования базы - когда обрыв связи во время проведенеия операции может повредить базу).

это не канает ...
включаю, сразу на ftp - тянуть файло .... в процессе скачивания - отрывается .... никаких простоев ...

+1... думал уже над этим ...

pptpd:

/etc/ppp > cat /etc/ppp/options.pptpd
lock
-chap
+chapms
+chapms-v2
mppe-128
mppe-stateless

/etc/ppp > cat /etc/ppp/ppp.conf
pptp:
enable chap81
enable proxy
set timeout 0
set ifaddr 195.195.195.1 195.195.195.2 255.255.255.255

/etc/ppp > cat /etc/ppp/pptpd.conf
option /etc/ppp/options.pptpd
debug

запускаю коммандой
/usr/local/sbin/pptpd -c /etc/ppp/pptpd.conf

mpd
/usr/local/etc/mpd > cat /usr/local/etc/mpd/mpd.conf
default:
load pptp0

pptp0:
new -i ng0 pptp0 pptp0
set ipcp ranges 192.168.192.1/32 192.168.192.2/32
load pptp_standart

pptp_standart:
set iface disable on-demand
set bundle enable multilink
set link yes acfcomp protocomp
set link no pap chap
set link enable chap
set link keep-alive 100 600
set ipcp yes vjcomp
set ipcp dns xxx.xxx.xxx.xxx
set iface enable proxy-arp
set bundle enable compression
set ccp yes mppc
set ccp yes mpp-e40
set ccp yes mpp-e128
set ccp yes mpp-stateless
set bundle yes crypt-reqd
set pptp self xxx.xxx.xxx.xxx
set pptp enable incoming
set pptp disable originate

/usr/local/etc/mpd > cat /usr/local/etc/mpd/mpd.links
pptp0:
set link type pptp

ЧТО КРУТИТЬ?

[Сообщение изменено пользователем 27.04.2005 13:41]

хммм... ну вроде бы должно как бы работать..
правда set pptp peer не видел... да и set ifaddr не согласуется с ipcp ranges

у меня так :
mpd.conf
vpn:
new -i ng1 vpn vpn
set iface disable on-demand
set iface addrs 10.0.16.2 10.0.16.1
set iface idle 0
set iface route 10.0.15.0/24
#set bundle disable multilink
set bundle authname ЮЗЕРНЕЙМ
set bundle password ПАССВОРД
set link yes acfcomp protocomp
set link no pap
set link yes chap
set link mtu 1460
# If remote machine is NT you need this..
set link enable no-orig-auth
set link keep-alive 10 75
set ipcp yes vjcomp
set ipcp ranges 10.0.16.2/32 10.0.16.1/32
#
# The five lines below enable Microsoft Point-to-Point encryption
# (MPPE) using the ng_mppc(8) netgraph node type.
#
set bundle enable compression
set ccp yes mppc
set ccp yes mpp-e40
set ccp yes mpp-e128
set bundle enable crypt-reqd
set ccp yes mpp-stateless
open

mpd.llinks:

vpn:
set link type pptp
set pptp self мой_ип
set pptp peer ип_на_втором_конце_тунеля
set pptp enable originate incoming outcall

ну и конечно соответственные правила ipfw которые разрешают доступ между станциями, правила маршрутизации (на втором конце висит сетка 10.0.15.)

лень сейчас искать эту ссылку, но пошукай на www.opennet.ru
по одной из статей я настраивал туннель между 2мя бсдями.. сколько хопов - хз, через инет идет...
а что уж завернуть или не завернуть в туннель - конфигуришь по усмотрению (ipsec.conf)

а как pptpd вообще согласуется с mpd? :-)
ты сравниваешь настройки от разных демонов ... :-)
я их в месте не запускаю ... по отдельности - оба работают ...
адреса - пока по барабану какие .... потом - поправлю ...
факт, что в одном хопе все (по отдельности) работает ...

это нужно ИМХО, когда mpd выступает в роли КЛИЕНТА VPN ... а у меня mpd - чистый СЕРВЕР.

firewall: allow all from any to any ... на момент настройки ... потом - попралю ...

если установится ppp-линк - то маршрутизация нужная - приедет .... ИМХО.
а Линк - не устанавливается ....

похоже, mpd у тебя - клиент ... и лопится на

я угадал?

З.Ы. а мой mpd - сам - никуда не ломится ... он принимает ... клиентов от ms-win ....

этот сайт я всегда читаю ... в этом случае - тоже читал ...

это - достаточно тривиально ...
тот-же mpd держит FreeBSD-vs-FreeBSD на раз ....
тут-же - клиент - ms-win ...

вот я и предлагаю виндового клиента поставить за туннелем и просто нужный трафик от него в туннель заворачивать...

т.е. со стороны КЛИЕНТА поставить в качестве Гейта - FreeBSD, поженить FreeBSD-vs-FreeBSD, и наслаждаться?

Гхм ... еще один комп ..... а клментов в разных городах - несколько .... на каждого клиента по дополнительному гейту - дороговато выйдет ....

подумаем ...
Но, всетаки, хочется клиента на ms-win...

читаю ... думаю, спасибо.

а чо у тя с другой то стороны в VPN всё сувать то будет, и ваще чо это за VPN, не хошь тратить машинку - ставь Kerio WF с впн и конфигурь его там. а вообще VPN это отстой - MPLS рулит. :-d

оно вроде не шифрует траффик, а просто разделяет.

неа - у меня работает mpd как и клиент и как сервер...
то есть успешно срабатывает в обоих ролях... провеорил специально...

и именно по отношению к винде он сервером выступает (т.е. я виндовой машиной когда вручную клиента запускаю - все отлично)...

а че не поставить mpd ? чем он хужее чем pptpd ?

кстати, помоему адрес пира задавать надо... так как в данном случае задается отдельный канал на каждое возможное соединение... (для них раздельные именя, пароли и гейты). Причем неважно - работает он как сервер или как клиент...

а то у тебя получается что ты задаешь адрес сервера, а клиент "кого бог пошлет"... Кроме того, что это менее секурно - ты еще подумай что получается... внутренние адреса туннеля ты прописал жесто - то есть хоть с одной точки к тебе подключатся хоть с другой - туннель должен получить те же адреса ? как так ? а если их сразу двое ? тогда че машинке делать-то ? кстати может тут и собака порылась ? может приходит второй коннект, которому по правилам должен быть присвоен тот же адрес туннеля и у pptpd крышку срывает ?

у меня вот несколько туннелей работает. Каждый из них настроен на четко определенный адрес клиента и каждому выделяется определенный туннель. Ну и конечно я забочусь о том, чтобы внутренние сетки у них разные были - чтобы всегда можно было определить в какой туннель отправить пакет для определенного ИПшника...

http://www.opennet.ru/openforum/vsluhforumID3/4980...
=================================
Например, PPTP. Стандарт, отлично. Только вот в чём проблема: если пакеты фрагментируются на входе в туннель (что типично для случая низкого MTU), а по дороге к другой стороне есть раутеры с хитрой политикой переупорядочения или load-balancing'ом, то вторые половинки фрагментов придут раньше первых. А в PPTP жёстко сказано, что при приходе пакетов
не по порядку имеющие seq (в GRE заголовке) меньше предыдущих - дропаются нафиг.
Сделано это для того чтобы управляющие пакеты PPP не путались. OK, не путаются. А пакеты данных при чём тут??
Дробить пакеты на выходе тоже сложно - заметная часть клиентов такого не понимает.
Результат - у нас есть категория клиентов у которых PPTP не работает в принципе, потому что повлиять на провайдеров по дороге нельзя.

Вообще есть три типа туннелирования, каждый со своими граблями:
- в транспорт негарантированной доставки без управления потоком с дроблением на входе. Примеры - PPTP, L2TP, UDP в OpenVPN, tunnel IPSEC. В подавляющем большинстве реализаций имеют слабоизлечимые проблемы с MTU.
- в транспорт негарантированной доставки без управления потоком с дроблением на выходе. Обычно страдают проблемой с load-balancing (см. выше).
- в транспорт типа TCP. Никаких проблем с MTU, но про изохронные потоки (multimedia всех видов, VoIP, heartbeat'ы...) можно забыть как класс.

OpenVPN по сравнению со всей этой мутной кашей смотрится _очень_ хорошо.
=================================

НЕТ второго коннекта ... НЕТУ... мониторю логи .... в момент подключания ....

пользователю выдаются IP-щники - в соответствии с mpd.secret ....
Тут проблем нет ...
один и тот-же пользователь - подключается в одном хопе ... отключается .... (по логам - все видно ... все ОК)
потом подключаемся через 9-ть хопов - в локах - кака, 619-я ошибка .... видимо не судьба .... (см. сообщение выше)

СУПЕР!
Там, где не работали poptop и mpd со всевозможными затюненами настройками - OpenVPN - поехал ...
правда, MTU тоже пришлось уменьшать .... с 1500 до 576

Итак, Мини-Отчет:
установка на FreeBSD:
cvsup до 4-STABLE, cvsup Портов
# cd /usr/ports/security/openvpn
# make
# make install
получаем
# openvpn --version
OpenVPN 2.0 i386-portbld-freebsd4.11 [SSL] [LZO] built on Apr 28 2005

Установка на Win2000 sp4
Инстольник - тут:
http://openvpn.net/download.html
http://openvpn.net/release/openvpn-2.0-install.exe...
Устанавливается, появляется еще один сетевой интерфейс на 10 мбит

Конфиги:
(использовалось http://openvpn.net/INSTALL-win32.html и пр. http://openvpn.net/ )
# cd /usr/ports/security/openvpn
детаем статический ключ на FreeBSD
# openvpn --genkey --secret fbsd-win.key
копируем fbsd-win.key на виндоус в папку C:\Program Files\OpenVPN\config
создаем конфиги
FreeBSD:
# cat /usr/local/etc/openvpn/myconfig.ovpn
remote ip.adr.win.machine
port 50000
dev tun0
tun-mtu 576
ifconfig 10.1.0.1 10.1.0.2
secret fbsd-win.key
ping 10
verb 3
mute 10

Win2000:
C:\Program Files\OpenVPN\config\myconfig.ovpn
---------
remote ip.adr.fbsd.machine
port 50000
dev tun
tun-mtu 576
ifconfig 10.1.0.2 10.1.0.1
secret "c:\\Program Files\\OpenVPN\\config\\fbsd-win.key"
ping 10
verb 3
mute 10
---------

Идем в настройки сетевого интерфейса TAP-Win32 Adapter V8, Дополнительно, Media Status - выставляем Always Connected
В настройкай TCP/IP на интерфейсе выставляем в ручную
IP 10.1.0.2
netmask 255.255.255.252

настраиваем Firewall для прохождения пакетов по порту 50000 (еслие стоит Firewall)

запускаем
FreeBSD:
openvpn --config /usr/local/etc/openvpn/myconfig.ovpn

Win2000
Файл C:\Program Files\OpenVPN\startvpn.cmd
--------------
cd bin
openvpn.exe ../config/myconfig.ovpn
cd ..
--------------

Все. Туннель - устанавливается.
Проверка:
FreeBSD
# ping 10.1.0.2

Win2000
ping 10.1.0.1

После этого, если нужно попасть в приватную сетку "за" FreeBSD,
на Win2000 настраиваем роутинг на приватную сетку - через туннель.

Занавес.

Критикуйте, поправляйте, комментируйте :-)

З.Ы. если клиентов много,
то их придется разводить по разным портам, на сколько я понял ... т.е. для каждого соединения - свой порт (50000, 50001, 50002 .... вообще любой свободный ...)
это минус ... но не критично ...

З.З.Ы Залез из дома в локалку на работу .... прикольно ... :-)
открыл doc документ с диска, расположенного за 25 км от дома ... отредактировал, сохранил на сетевой диск ...
все работает ...

[Сообщение изменено пользователем 29.04.2005 10:13]

МаладЭц!
Надо будет попробовать... а то вчера посмотрел на ту сетку.... на внешний адрес 100% пакетов идут а вот по ВПН чето потерь много...



О блин удивил :-)
Я уже не первый год пользуюсь такой фичей (из дому на нескольких "работах" шарюсь.... :-)

никто никого не удивил .... просто
когда MTU был 1500 - захадило в сетевое окружение, но при передаче больших файлов - было сообщение "диск не доступен" через некоторое время ...

мое сообщение - не открытие америки, что такое удаленный доступ - я знаю тоже, и тоже давно пользуюсь :-)

В чаестве проверки - запускал проверку CRC на архиве zip, лежащем на работе ...
так вот, когда МТУ был 1500 - проверка CRC - не проходила ... (файло - 2 МБ)
когда уменьшил МТУ - проверка CRC прошла ...

Так что это не панты и удивление - а подтверждение корректно работы системы :-)

Тема автоматически закрыта.