The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"FreeBSD как клиент к VPN серверу"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"FreeBSD как клиент к VPN серверу"  
Сообщение от mg (??) on 04-Ноя-06, 23:37 
Доброго всем времени суток.

Имеется машина FreeBSD 5.4 (релиз)
Задача подключиться к интернету через провайдера котрый использует VPN сервер для доступа к инету. При этом первоначально адреса выдаются DHCP сервером.
Установил пакеты
libgnugetopt-1.2
pptpclient-1.5.0
mpd-3.18_2

Сначало пробовал соединиться через pptpclient-1.5.0
Вот конфигурационный файл /etc/ppp/ppp.conf
=====8<==============8<=========8<======
# ppp.conf generated by mg
default:
vpn:
set authname *******
set authkey *******
set timeout 0
set ifaddr 0 0
nat enable yes
enable lqr
disable ipv6cp
disable mppe
set ifaddr 0
add default HISADDR
=====8<==============8<=========8<======

Запускаю
#pptp 213.xxx.xxx.xxx vpn &

Смотрим что там с интерфейсами
#ifconfig
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet 172.16.52.161 netmask 0xffffe000 broadcast 172.16.63.255
        ether 00:11:95:24:08:88
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000
tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500

Смотрим что в логах /var/log/ppp.log
...
Nov  4 21:25:27 unix ppp[451]: Phase: Using interface: tun0
Nov  4 21:25:27 unix ppp[451]: Phase: deflink: Created in closed state
Nov  4 21:25:27 unix ppp[451]: Phase: PPP Started (direct mode).
Nov  4 21:25:27 unix ppp[451]: Phase: bundle: Establish
Nov  4 21:25:27 unix ppp[451]: Phase: deflink: closed -> opening
Nov  4 21:25:27 unix ppp[451]: Phase: deflink: Connected!
Nov  4 21:25:27 unix ppp[451]: Phase: deflink: opening -> carrier
Nov  4 21:25:28 unix ppp[451]: Phase: deflink: carrier -> lcp
Nov  4 21:25:28 unix ppp[451]: Phase: bundle: Authenticate
Nov  4 21:25:28 unix ppp[451]: Phase: deflink: his = CHAP 0x05, mine = none
Nov  4 21:25:28 unix ppp[451]: Phase: Chap Input: CHALLENGE (16 bytes)
Nov  4 21:25:28 unix ppp[451]: Phase: Chap Output: RESPONSE (cihn1109)
Nov  4 21:25:29 unix ppp[451]: Phase: Chap Input: SUCCESS (Welcome^M )
Nov  4 21:25:29 unix ppp[451]: Phase: deflink: lcp -> open
Nov  4 21:25:29 unix ppp[451]: Phase: bundle: Network
Nov  4 21:25:29 unix ppp[451]: Phase: deflink: open -> lcp
Nov  4 21:25:29 unix ppp[451]: Phase: bundle: Terminate
Nov  4 21:25:29 unix ppp[451]: Phase: Signal 15, terminate.
Nov  4 21:25:32 unix ppp[451]: Phase: deflink: Disconnected!
Nov  4 21:25:32 unix ppp[451]: Phase: deflink: Connect time: 5 secs: 600 octets
in, 651 octets out
Nov  4 21:25:32 unix ppp[451]: Phase: deflink: 19 packets in, 20 packets out
Nov  4 21:25:32 unix ppp[451]: Phase:  total 250 bytes/sec, peak 312 bytes/sec o
n Sat Nov  4 21:25:30 2006
Nov  4 21:25:32 unix ppp[451]: Phase: deflink: lcp -> closed
Nov  4 21:25:32 unix ppp[451]: Phase: bundle: Dead
Nov  4 21:25:32 unix ppp[451]: Phase: PPP Terminated (normal).


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

Идём дальше, помучавшись не один час с такой прелестью как pptpclient, и не удовлетворившись даже на 1% процент (собственно от чего удовлетворяться, от неработающего и глючного приложения?) решил попробовать подключиться к VPN через mpd/
Вот мои конфиги


файл /usr/local/etc/mpd/mpd.conf
=====8<==============8<=========8<======
# mpd.conf generated by mg

default:
    load client1

client1:
    new -i ng0 pptp0 pptp0
    set iface disable on-demand
    set iface idle 1800
    set bundle disable multilink
    set bundle authname "login"
    set bundle password "passwd"
    set link yes acfcomp protocomp
    set link keep-alive 10 60
    set ipcp ranges 0/0
    open

#EOF mpd.conf
=====8<==============8<=========8<======

файл /usr/local/etc/mpd/mpd.links
=====8<==============8<=========8<======
# mpd.links generated by mg

pptp0:
    set link type pptp
    set pptp peer 213.148.4.50
    set pptp enable originate outcall
=====8<==============8<=========8<======

файл /usr/local/etc/mpd/mpd.secret
=====8<==============8<=========8<======
# mpd.secret generated by mg

login        passwd        0.0.0.0
=====8<==============8<=========8<======


Запускаю mpd
#mpd
Multi-link PPP for FreeBSD, by Archie L. Cobbs.
Based on iij-ppp, by Toshiharu OHNO.
mpd: pid 932, version 3.18 (root@unix 17:31  4-Nov-2006)
[pptp0] ppp node is "mpd932-pptp0"
mpd: warning: line too long, truncated
[pptp0] using interface ng0
Usage: set ipcp ranges self/width peer/width
mpd: warning: line too long, truncated
[pptp0] IFACE: Open event
[pptp0] IPCP: Open event
[pptp0] IPCP: state change Initial --> Starting
[pptp0] IPCP: LayerStart
[pptp0:pptp0] [pptp0] bundle: OPEN event in state CLOSED
[pptp0] opening link "pptp0"...
[pptp0] link: OPEN event
[pptp0] LCP: Open event
[pptp0] LCP: state change Initial --> Starting
[pptp0] LCP: LayerStart
[pptp0] device: OPEN event in state DOWN
pptp0: connecting to 213.xxx.xxx.xxx:1723
[pptp0] device is now in state OPENING
pptp0: connected to 213.xxx.xxx.xxx:1723
pptp0: attached to connection with 213.xxx.xxx.xxx:1723
pptp0-0: outgoing call connected at 64000 bps
[pptp0] PPTP call successful
[pptp0] device: UP event in state OPENING
[pptp0] device is now in state UP
[pptp0] link: UP event
[pptp0] link: origination is local
[pptp0] LCP: Up event
[pptp0] LCP: state change Starting --> Req-Sent
[pptp0] LCP: phase shift DEAD --> ESTABLISH
[pptp0] LCP: SendConfigReq #1
ACFCOMP
PROTOCOMP
MRU 1500
MAGICNUM ******
[pptp0] LCP: rec'd Configure Request #33 link 0 (Req-Sent)
ACFCOMP
PROTOCOMP
MRU 1500
MAGICNUM *******
AUTHPROTO CHAP MD5
[pptp0] LCP: SendConfigAck #33
ACFCOMP
PROTOCOMP
MRU 1500
MAGICNUM *******
AUTHPROTO CHAP MD5
[pptp0] LCP: state change Req-Sent --> Ack-Sent
[pptp0] LCP: rec'd Configure Ack #1 link 0 (Ack-Sent)
ACFCOMP
PROTOCOMP
MRU 1500
MAGICNUM ******
[pptp0] LCP: state change Ack-Sent --> Opened
[pptp0] LCP: phase shift ESTABLISH --> AUTHENTICATE
[pptp0] LCP: auth: peer wants CHAP, I want nothing
[pptp0] LCP: LayerUp
[pptp0] CHAP: rec'd CHALLENGE #1
Name: ""
Using authname "******"
[pptp0] CHAP: sending RESPONSE
[pptp0] CHAP: rec'd SUCCESS #1
MESG: Welcome
[pptp0] LCP: authorization successful
[pptp0] LCP: phase shift AUTHENTICATE --> NETWORK
[pptp0] setting interface ng0 MTU to 1500 bytes
[pptp0] up: 1 link, total bandwidth 64000 bps
[pptp0] IPCP: Up event
[pptp0] IPCP: state change Starting --> Req-Sent
[pptp0] IPCP: SendConfigReq #1
IPADDR 172.16.52.161
COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
[pptp0] IPCP: rec'd Configure Request #17 link 0 (Req-Sent)
IPADDR 213.xxx.xxx.xxx
   213.xxx.xxx.xxx is OK
[pptp0] IPCP: SendConfigAck #17
IPADDR 213.xxx.xxx.xxx
[pptp0] IPCP: state change Req-Sent --> Ack-Sent
[pptp0] IPCP: rec'd Configure Reject #1 link 0 (Ack-Sent)
COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
[pptp0] IPCP: SendConfigReq #2
IPADDR 172.16.52.161
[pptp0] IPCP: rec'd Configure Nak #2 link 0 (Ack-Sent)
IPADDR 213.xxx.zzz.zzz
   213.xxx.zzz.zzz is OK
[pptp0] IPCP: SendConfigReq #3
IPADDR 213.xxx.zzz.zzz
[pptp0] IPCP: rec'd Configure Ack #3 link 0 (Ack-Sent)
IPADDR 213.xxx.zzz.zzz
[pptp0] IPCP: state change Ack-Sent --> Opened
[pptp0] IPCP: LayerUp
  213.xxx.zzz.zzz -> 213.xxx.xxx.xxx
[pptp0] IFACE: Up event
[pptp0] setting interface ng0 MTU to 1500 bytes
[pptp0] exec: /sbin/ifconfig ng0 213.xxx.zzz.zzz 213.xxx.xxx.xxx netmask 0xffffffff -l
ink0
[pptp0] exec: /sbin/route add 213.xxx.zzz.zzz -iface lo0
[pptp0] IFACE: Up event


Судя по этому выводу mpd писали люди менее обкуренные, так как вроде бы оно даже соединилось.  Теперь смотрим что у нас с интерфейсами
#ifconfig
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet 172.16.52.161 netmask 0xffffe000 broadcast 172.16.63.255
        ether 00:11:95:24:08:88
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
        inet 213.xxx.zzz.zzz --> 213.xxx.xxx.xxx netmask 0xffffffff

Т.е. и интерфейс вроде поднялся, однакопинг хоть куда-нибудь за пределы локальных адресов  не проходит!
Начинаем разбираться, как такое получилось? Выводим список всех роутов

#netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            172.16.32.1        UGS         0       43    rl0
127.0.0.1          127.0.0.1          UH          1        2    lo0
172.16.32/19       link#1             UC          0        0    rl0
172.16.32.1        00:e0:4d:04:a8:e2  UHLW        1        0    rl0   1188
172.16.52.161      127.0.0.1          UGHS        0        0    lo0
213.xxx.xxx.xxx    213.xxx.zzz.zzz    UH          0        0    ng0
213.xxx.zzz.zzz    lo0                UHS         0        0    lo0

И так что это значит?
А это означает что все пакеты идущие во вне пойдут ни куда-нибудь а именно на внутренний шлюз 172.16.32.1. Вопрос каким же образом нам перенаправить пакеты идущие во вне на шлюз 213.xxx.zzz.zzz ? Разумеется это можно сделать командами

#route delete default
удаляем текущий шлюз по умолчанию
#route add 0.0.0.0 213.xxx.zzz.zzz
задаём другой шлюз через котрый реально можно выйти в инет.

Однако если эти команды ввести то соединение VPN будет разорвано, что собственно логично, потому что к VPN мы подключились через шлюз 172.16.32.1 который нас NAT-ил к адресу VPN сервера 213.xxx.xxx.xxx и теперь у нас просто нету соединения до сервера VPN!

Другой вариант это назначить два шлюза с различными приоритетами. Собственно именно таки ипоступает виндовый VPN клиент ставя короткую метрику на шлюз 213.xxx.xxx.xxx и длинную метрику на шлюз 172.16.32.1

Ну а теперь у меня собственно вопрос, есть тут где нибудь хоть кто-то с руками не такими кривыми как у меня кто может мне объяснить, каким же образом в FreeBSD не включая демон routed и не занося в файл /etc/gateways список шлюзов, а используя только команду route добавить нескоолько шлюзов с разными пионритетами?  Или Вообще может кто знает каким образом можнео обойти подобную проблему при соединении к VPN серверу?

Любителям кричать RTFM, прежде чем кидать линк куда-то просьба заценить нижеследующие ссылки
http://www.opennet.me/base/net/pptp_tunnel.txt.html
http://homenet.corbina.net/index.php?showtopic=15540&st=60
http://www.tolkuchka.dsip.net/index.php?showtopic=4954
http://www.opennet.me/tips/info/662.shtml
http://forum.nag.ru/index.php?showtopic=5347
http://bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=4&m=116962
http://www.dcnet.ru/instructions/freebsd_pptp_client.htm
http://www.trigor.ru/support_vpnfbsdpptp.php
http://forum.oszone.net/showthread.php?s=f9a4304541d1e373bb465a8f3fb339f3&t=15904

Спасибо всем кто понимает...
(прошу прощение если кого из программеров обидел, но потратить 10 часов на безрезультатную разборку... тоже нужно иметь крепкие нервы)

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

 Оглавление

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


1. "FreeBSD как клиент к VPN серверу"  
Сообщение от butcher (ok) on 05-Ноя-06, 14:40 
>client1:
>    new -i ng0 pptp0 pptp0
>    set iface disable on-demand
>    set iface idle 1800
# Добавить опцию
     set iface route default

>    set bundle disable multilink
>    set bundle authname "login"
>    set bundle password "passwd"
>    set link yes acfcomp protocomp
>    set link keep-alive 10 60
>    set ipcp ranges 0/0
>    open
>=====8<==============8<=========8<======

>    set pptp peer 213.148.4.50

>Т.е. и интерфейс вроде поднялся, однакопинг хоть куда-нибудь за пределы локальных адресов
> не проходит!

>А это означает что все пакеты идущие во вне пойдут ни куда-нибудь
>а именно на внутренний шлюз 172.16.32.1. Вопрос каким же образом нам
>перенаправить пакеты идущие во вне на шлюз 213.xxx.zzz.zzz ?

Прописать статический маршрут до VPN сервера.

Т.е. что-то типа:
# cat >> /etc/rc.conf
static_routes="vpn"
route_vpn="213.148.4.50 172.16.32.1"
^C
# /etc/rc.d/routing restart
# mpd


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

2. "FreeBSD как клиент к VPN серверу"  
Сообщение от mg (??) on 07-Ноя-06, 01:01 
Спасибо за ответ, проблему я всё же решил несколько иначе.
Дело в том что если изначально указать роут
#route add 213.148.4.50 172.16.32.1
То после запуска mpd
Возникнет ошибка File Exists ...
Такая ошибка возникает потму что сам mpd пытается выполнить такое
ifconfig ng0 213.xxx.zzz.zzz 213.148.4.50 netmask 0xffffffff -l
а эта команда пытается создать роут такого вида
213.148.4.50          213.xxx.zzz.zzz          UGHS        0        1    ng0
И понятное дело она не может создать такой роут потому что мы уже до запуска mpd создали роут
213.148.4.50          172.16.32.1          UG        0        1    rl0

А так как оно не может создать такой роут то интерфейс ng0 оказывается ни к чему не привязанным, а это означает что после того как был запущен mpd если выполнить колманду
route add 0.0.0.0 213.148.4.50
то в таблицу роутов добавится строка
default          213.148.4.50          UGHS        0        1    rl0

Видите, в конце стоит не ng0, а rl0 это означает что пакеты не будут попадать в тунел, а будут напрямую через rl0 пытатьсяпройти в инет, и соответственно никуда не будут попадать вообще. Правильная строка была бы такой

default          213.148.4.50          UGHS        0        1    ng0
Но для этого надо чтоб хоть какой-то адрес был привязан к ng0

Теперь о том что я сделал
Во первых вопреки вашему совету сделать статический маршрут на 213.148.4.50 через 172.16.32.1 я категорический не рекомендую это делать. Потому что это приводит к возникновению строки
213.148.4.50          172.16.32.1          UG        0        1    rl0
и не даёт последующему запуску mpd установить првязку адреса к ng0
Поэтому я просто убедился что мой провайдер маскарадит меня до сервера впн 213.148.4.50 просто сделав пинг я уже уведел что пиги до сервера 213.148.4.50 идут , а значит ставить статический роут в самом начале - неимеет никакого смысла, хотя именно его и рекомендуют во всех доках. Поэтому я просто посмотрел что у меня default getway 172.16.32.1 и что через него я попадаю на впн сервер. Затем сразу запустил mpd (повторяю ничего не трогая запустил mpd)
в результате я получил строку в роутерах
213.148.4.50          213.xxx.zzz.zzz          UGHS        0        1    ng0
Видите на конце стоит ng0 и если просто набрать ifconfig то увидим что за ng0 привязан адрес 213.xxx.zzz.zzz -> 213.148.4.50

Далее я сделал так
#route delete default
#route add 0.0.0.0 213.148.4.50
В итоге возникла строка в роутах
default          213.148.4.50          UGHS        0        1    ng0
именно эта строка нам и была нужна! Теперь пакеты попадают в тунель, но проблема в том что теперь нету явного доступа до самого впн сервера, так как раньше он обеспечивался чере з маскарад (NAT) провайдера на моём основном шлюзе 172.16.32.1, а теперь шлюз по умолчанию сам сервер впн  но пути то к нему нету :). Поэтому теперь делаем такое
#route delete 213.148.4.50
#route add 213.148.4.50 172.16.32.1

Видите после удаления строчки
213.148.4.50          213.xxx.zzz.zzz          UGHS        0        1    ng0
сам интерфейс ng0 попрежнему остаётся привязанным к адресу 213.xxx.zzz.zzz происходит это потому что мы указали адрес 213.148.4.50 (закреплённый на интерфейсе ng0) как шлюз по умолчанию. Так как есть хоть один адрес в табличе роутов закреплённый за интерфейс то интерфейс не терят свой адрес!
Второй строчкой мы просто добавляем статический маршрут, все пакеты идущие на впн сервер (213.148.4.50) перенаправлять на наш основной шлюз (172.16.32.1)
И теперь у нас в таблице роутеров две нужные нам строчки
default          213.148.4.50          UGHS        0        1    ng0
213.148.4.50          172.16.32.1          UG        0        1    rl0

И всё! Теперь всё будет работать!

Спасибо  butcher за поддержку!

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру