Обсуждение статьи тематического каталога: VPN соединение из Linux (pptpclient) к FreeBSD (mpd) с шифрованием MPPE128 (vpn linux freebsd crypt pptp tunnel patch)Ссылка на текст статьи: http://www.opennet.me/base/net/pptp_mppe_crypt.txt.html
А зачем патч качать откудато, если он идет в поставке в последнеи pppd, народ читайте документацию
Не спорю, идёт, работает, но не с сервером на FreeBSD
PopTop и Windows серверы работают с pptpclient без проблем
Вот история событий:
http://linuxportal.ru/forums/index.php/t/12978/
И продолжение:
http://linuxportal.ru/forums/index.php/t/13406/
У меня таже фигня, между Linux-Linux, VPN-соединение устанавливается, но пинги не ходят, при этом загрузка проца на 100 процентов, загрузка интерфейса, то же на 100, что то передаёт, непонятно что.... Удавалось решать эту проблему удалением какого-то пути, который pptp-client дописывает сам, но, если без шифрование при удалении этого пути всё работает, то с mppe шифрованием, нужно удалить это путь как можно быстрее после создания его, обычно удаётся это сделать с 5-10 попытки.... После удалении этого пути нагрузка проца падает и сетевого интерфейса тоже... Никто с таким не сталкивался???
Видимо у тебя получается "петля" для пакетиков.
То есть пакет не уходит из ppp интерфейса из за неправильного роутинга
У меня конкретно та же ситуация, решается просто:
Прописывай путь перед началом соединения до VPN сервера через eth0
Что-то типа route add 192.168.4.1 dev eth0
А потом соединяйся.
Подробно и с картинками описано на pptpclient.sourceforge.net
Да, и посмотри (Например из windows) какой default gw после соединения,
Мой провайдер неожиданно выставляет не адрес VPN сервера, а произвольный
Типа 192.168.100.29 (eth0 у меня 192.168.4.29)
Его то же надо прописать
Типа route add default gw 192.168.100.29
Но после соединения.
Воспользуйся Ethereal для Linux чтобы посмотреть траффик
Последовательно на всех интерфейсах - Думаю на половину решишь проблему
У него есть версия и для windows - так что можно сравнивать
соединения в linux и в windows
Кстати если в винде всё ОК,
Простая команда route print даёт тебе правильные пути - такие и в линуксе делай.
Ещё дай команду ipconfig в винде - тоже информация.
Я понимаю что петля получается.... :-))
Но беда в том, что эта петля нормально убирается если нет mppe шифрования... А вот если оно с ним, то фигня...А то что путь надо перед соединением прописать, так pptp-client при соединении его почему то удаляет и ставит свой.... Ну опять же говорю, что это путь (который pptp прописал) удаляется и всё номально без mppe шифрования, с ним надо очень быстро его удалить.. :-)) Получается с 5-10 попытки..
Может посмотрим на конфиги и мессаги?
Вообще-то есть мнение что бага то во FreeBSD
вот патчик (найден весной в Инете)--- sys/netgraph/ng_ppp.c.orig Thu Nov 21 12:39:06 2002
+++ sys/netgraph/ng_ppp.c Thu Nov 21 12:39:26 2002
@@ -744,7 +744,7 @@
case HOOK_INDEX_VJC_VJIP:
if (priv->conf.enableCompression
&& priv->hooks[HOOK_INDEX_COMPRESS] != NULL) {
- if ((m = ng_ppp_addproto(m, proto, 1)) == NULL) {
+ if ((m = ng_ppp_addproto(m, proto, 0)) == NULL) {
NG_FREE_META(meta);
return (ENOBUFS);
}
Видел. Заставить администратора нашей районной локальной сети поставить патч на его сервер FreeBSD не удалось. Я то на стороне клиента.
Так что... Спасибо за участие.
Эм...
Я тут смотрю ~2002-3гг
А чё делать на FreeBSD 6.0/6.1/6.2?
У Меня на них с mpd4b4 , mpd4.1 Линух не конектится!!!
И пробывал когда-то FreeBSD тож :) ->FreeBSD6.0+mpd4.0b4
Симптом один и тот же:
За небольшой промежуток времени набегает туча трафика до 4Мб/сек...
Пинг никуда не ходит...
Я тут немного не в курсе, но вот набрел на интересный сайтец: http://vpnaccounts.info/ может через них попробывать?
Как в SuSE 9.2 настроить VPN ?
подскажите плиз
Вот чего Я достиг:
FreeBSD6.2RC1+mpd4.1mpd.conf:
pptp100:
new -i ng100 pptp100 pptp100
set ipcp ranges 192.168.11.1/32 192.168.11.101/32
load pptp_standartpptp_standart:
set pptp disable windowing
set iface route default
set iface disable on-demand
#
set iface enable tcpmssfix
#
set bundle disable multilink
set link yes acfcomp protocomp
set iface up-script "/usr/local/etc/mpd4/link-up"
set iface down-script "/usr/local/etc/mpd4/link-down"
set link no pap chap
set link enable chap
set link keep-alive 10 75
set ipcp yes vjcomp
set ipcp dns 10.11.25.1
# set link mtu 1460
# set link mru 1460
set iface enable proxy-arp
set bundle enable compression
set ccp yes mppc
set ccp yes mpp-e40
# set ccp yes mpp-e56
set ccp yes mpp-e128
set ccp yes mpp-stateless
set pptp enable incoming
set pptp disable originate
# set radius config /opt/radius.conf
set radius me 127.0.0.1
set radius retries 2
set radius server 127.0.0.1 password 1812 1813
set radius timeout 5
set auth acct-update 300
set auth enable radius-auth
set auth enable radius-acct
# set ipcp yes radius-ip
# set iface routempd.links:
pptp100:
set link type pptpКонект есть, а Инета нету :(
Всем День добрый!
При детальном анализе процесса коннекта к people.net выяснились весьма интересные моменты. А также то, что "не все хорошо в Датском.."
Итак подробно:/etc/ppp/options - пуст (размер 0 байт)
все опции pppd назначаюся индивидуально каждой линии (будь-то ttyS0,ttyS1 или ttyACM0)модем - CCU-550
___________________________________________
# /etc/ppp/peers/bsa
debug
unit 2
name 80921111111@free
password 777777
/dev/ttyACM0
115200
defaultroute
usepeerdns
nodetach
crtscts
lock
nomppe
modemconnect "/usr/sbin/chat -f /etc/ppp/chatscripts/people.net-connect-chat"
disconnect "/usr/sbin/chat -f /etc/ppp/chatscripts/people.net-disconnect-chat"
_________________________________________________________os - sles 10
ядро и pppd пропатчены для поддержки MPPE-MPPC
процесс патчения и сборки прошел на ура без запинок
запускаем>/pppd call bsa
имеем:
________________________________________________
CCU-550 modem init: press <ctrl>-C to disconnect
Serial connection established.
using channel 66
Using interface ppp2
Connect: ppp2 <--> /dev/ttyACM0
sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <magic 0x4d652909> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <mru 576> <asyncmap 0x0> <magic 0x4d652909> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <magic 0x4d652909> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <mru 576> <asyncmap 0x0> <magic 0x4d652909> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <magic 0x4d652909> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <mru 576> <asyncmap 0x0> <magic 0x4d652909> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <mru 576> <asyncmap 0x0> <magic 0x4d652909> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <mru 576> <asyncmap 0x0> <magic 0x4d652909> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0x0> <auth chap MD5> <magic 0x1316fe55> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <mru 1500> <asyncmap 0x0> <auth chap MD5> <magic 0x1316fe55> <pcomp> <accomp>]
rcvd [CHAP Challenge id=0x1 <6cebef8cd483b340e02324eec08db6b0>, name = "PDSN-Kyiv"]
sent [CHAP Response id=0x1 <ec1be3f57f46d671eede89b6e5c87598>, name = "80921111111@free"]
rcvd [CHAP Success id=0x1 "Welcome to PDSN-Kyiv."]
CHAP authentication succeeded: Welcome to PDSN-Kyiv.
sent [CCP ConfReq id=0x1 <mppe -H -M -S -L -D +C> <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.1.77> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfReq id=0x0 <addr 2.2.2.2>]
sent [IPCP ConfAck id=0x0 <addr 2.2.2.2>]
rcvd [CCP ConfReq id=0x0 <lzs 00 01 03>]
sent [CCP ConfRej id=0x0 <lzs 00 01 03>]
rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [CCP ConfReq id=0x2 <mppe -H -M -S -L -D +C>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01> <ms-dns3 0.0.0.0>]
sent [IPCP ConfReq id=0x2 <addr 192.168.1.77> <ms-dns1 0.0.0.0>]
rcvd [CCP ConfReq id=0x1 <mppe -H -M -S -L -D +C>]
sent [CCP ConfAck id=0x1 <mppe -H -M -S -L -D +C>]
rcvd [CCP ConfAck id=0x2 <mppe -H -M -S -L -D +C>]
MPPC compression enabled
rcvd [IPCP ConfNak id=0x2 <addr 172.30.224.195> <ms-dns1 77.109.1.8>]
sent [IPCP ConfReq id=0x3 <addr 172.30.224.195> <ms-dns1 77.109.1.8>]
rcvd [IPCP ConfAck id=0x3 <addr 172.30.224.195> <ms-dns1 77.109.1.8>]
local IP address 172.30.224.195
remote IP address 2.2.2.2
primary DNS address 77.109.1.8rcvd [proto=0x2145] 00 00 34 00 00 40 00 3d 06 62 40 4d 6d 01 35 ac 1e e0 c3 00 50 aa 0b 57 21 4a 25 ac e8 b7 db 80 ...
Unsupported protocol 0x2145 received
sent [LCP ProtRej id=0x2 21 45 00 00 34 00 00 40 00 3d 06 62 40 4d 6d 01 35 ac 1e e0 c3 00 50 aa 0b 57 21 4a 25 ac e8 b7 ...]
rcvd [proto=0x2145] 00 00 34 00 00 40 00 3d 06 62 40 4d 6d 01 35 ac 1e e0 c3 00 50 aa 0b 57 21 4a 25 ac e8 b7 db 80 ...
Unsupported protocol 0x2145 received
sent [LCP ProtRej id=0x3 21 45 00 00 34 00 00 40 00 3d 06 62 40 4d 6d 01 35 ac 1e e0 c3 00 50 aa 0b 57 21 4a 25 ac e8 b7 ...]
rcvd [proto=0x2145] 00 00 34 00 00 40 00 3d 06 62 40 4d 6d 01 35 ac 1e e0 c3 00 50 aa 0b 57 21 4a 25 ac e8 b7 db 80 ...
Unsupported protocol 0x2145 received
sent [LCP ProtRej id=0x4 21 45 00 00 34 00 00 40 00 3d 06 62 40 4d 6d 01 35 ac 1e e0 c3 00 50 aa 0b 57 21 4a 25 ac e8 b7 ...]
Terminating on signal 2
Connect time 0.3 minutes.
Sent 104 bytes, received 153 bytes.
restoring old default route to eth0 [192.168.7.241]
sent [LCP TermReq id=0x5 "User request"]
rcvd [LCP TermAck id=0x5]
Connection terminated.
+ sending break
Serial link disconnected
____________________________Первое, что бросается в глаза - отклонение протокола сжатия заголовков со стороны пиплов
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01> <ms-dns3 0.0.0.0>]
???!!!
Не встречал ни одного прова кто бы не поддерживал или отклонял сжатие заголовков
Самое интересно наступает после попытки прогнать через канал пакетыtelnet my.people.net.ua 80
отклика нет....
проведен детальный трейс фреймов средствами pppdumpsent 7e fd e0 00 00 21 45 10 00 34 71 59 40 00 80 03
4b 6d b2 c1 eb 04 b1 35 b4 04 d6 7a 32 00 a0 fe
11 7b 2b 00 f0 50 0a 10 b5 41 11 ec 00 00 08 10
16 68 02 02 08 04 02 06 06 04 c1 85 7e
sent fd 20 01 fd 80 00 06 80 00 1f b4 30 b8 d0 25 00
f7 35 2a 7b ed a0 00 64 30 e9 fa a6 ef 75 64 a1
c1 29 10 01 21 6a 85 48 ef f6 d4 08 35 dd 7eв ответ получаю от пиплов
rcvd 7e fd c0 00 21 45 00 00 34 00 00 40 00 3d 06 62
57 4d 6d 01 35 ac 1e e0 ac 00 50 bd 19 07 d4 ef
a6 7f 08 fb 2c 80 12 16 d0 4d ae 00 00 02 04 05
b4 01 01 04 02 01 03 03 03 f4 80 7eпотом снова
sent c0 21 08 02 00 39 21 45 00 00 34 00 00 40 00 3d
06 62 57 4d 6d 01 35 ac 1e e0 ac 00 50 bd 19 07
d4 ef a6 7f 08 fb 2c 80 12 16 d0 4d ae 00 00 02
04 05 b4 01 01 04 02 01 03 03 03 10 65 7eв журнале pppd это выглядит как:
rcvd [proto=0x2145] 00 00 34 00 00 40 00 3d 06 62 40 4d 6d 01 35 ac 1e e0 c3 00 50 aa 0b 57 21 4a 25 ac e8 b7 db 80 ...
Unsupported protocol 0x2145 receivedsent [LCP ProtRej id=0x2 21 45 00 00 34 00 00 40 00 3d 06 62 40 4d 6d 01 35 ac 1e e0 c3 00 50 aa 0b 57 21 4a 25 ac e8 b7 ...]
________________________________________Спецы PPP отзовитесь, что все это значит ?
И в заключение: С данной сборкой ядра и pppd виндовые хосты работают без проблем как dial-in так и dial-up и MPPC компрессия работает на ура. С общеизвестной проблемой 0x2145 это похоже не связано, иначе MPPC не работало бы во всех случаях. Затыкон возник именно с пиплами.
Спасибо