Настройка VPN в Linux с ZNet/Net-by-Net в Дебиан Линукс

Не так давно пришлось заниматься настройкой VPN Linux в Debian GNU/Linux (хотя VPN в Ubuntu настраивается так же). Так как форум ZNet/Net-by-Net извне недоступен, выкладываю это здесь. Хотя настройка vpn под linux дело не хитрое, но был один секретный бубен, в который надо было стукнуть. Он таился в дебрях обсуждений на ixbt и был найден мной в процессе обдумывания сакраментального вопроса "что делать!?".

Поднимаем Интернет
Настройка VPN в Linux отдалённо напоминает настройку GPRS - копание в сторону ppp и связанных с ним утилит. Нужно установить пакеты pptp linux:

aptitude install pptp-linux
После этого создаём файл /etc/ppp/peers/Znet и правим его содержимое до следующего вида:
name мой_логин
remotename PPTP
pty "pptp vpn.znet --nolaunchpppd"
lock
noauth
mtu 1372
mru 1372
lcp-echo-failure 10
Заменяем мой_логин на нормальный логин и обращаем внимание на выделенные полужирным строки. Мне пришлось ради них ковыряться Аллах знает где на форумах iXBT - только после этого всё заработало (по умолчанию стоит 1378)!

Если оставить значение по умолчанию, будете получать такие матюги:

Jun 18 04:05:02 Resolventa pppd[3450]: sent [LCP ConfReq id=0x1 ]
Jun 18 04:05:02 Resolventa pptp[3456]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Jun 18 04:05:02 Resolventa pptp[3456]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.
Jun 18 04:05:02 Resolventa pptp[3456]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established ta pppd[3450]: rcvd [LCP ConfReq id=0x1 ]
Jun 18 04:05:02 Resolventa pppd[3450]: sent [LCP ConfAck id=0x1 ]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [LCP ConfRej id=0x1 ]
Jun 18 04:05:02 Resolventa pppd[3450]: sent [LCP ConfReq id=0x2 ]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [LCP ConfAck id=0x2 ]
Jun 18 04:05:02 Resolventa pppd[3450]: sent [LCP EchoReq id=0x0 magic=0x93be06c8]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [LCP EchoReq id=0x0 magic=0x2244c55a]
Jun 18 04:05:02 Resolventa pppd[3450]: sent [LCP EchoRep id=0x0 magic=0x93be06c8]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [CHAP Challenge id=0xa4 , name = "vpn1"]
Jun 18 04:05:02 Resolventa pppd[3450]: sent [CHAP Response id=0xa4 <0a52e6cd7d20afcd0c1861afbffae990>, name = "MZR9Kexm"]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [LCP EchoRep id=0x0 magic=0x2244c55a]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [CHAP Success id=0xa4 ""]
Jun 18 04:05:02 Resolventa pppd[3450]: CHAP authentication succeeded
Jun 18 04:05:02 Resolventa pppd[3450]: CHAP authentication succeeded
Jun 18 04:05:02 Resolventa pppd[3450]: sent [IPCP ConfReq id=0x1 ]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [IPCP ConfReq id=0x1 ]
Jun 18 04:05:02 Resolventa pppd[3450]: sent [IPCP ConfAck id=0x1 ]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [IPCP ConfRej id=0x1 ]
Jun 18 04:05:02 Resolventa pppd[3450]: sent [IPCP ConfReq id=0x2 ]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [IPCP ConfNak id=0x2 ]
Jun 18 04:05:02 Resolventa pppd[3450]: sent [IPCP ConfReq id=0x3 ]
Jun 18 04:05:02 Resolventa pppd[3450]: rcvd [IPCP ConfAck id=0x3 ]
Jun 18 04:05:02 Resolventa pppd[3450]: Cannot determine ethernet address for proxy ARP
Jun 18 04:05:02 Resolventa pppd[3450]: local IP address 10.10.252.102
Jun 18 04:05:02 Resolventa pppd[3450]: remote IP address 10.10.0.20
Jun 18 04:05:02 Resolventa pppd[3450]: Script /etc/ppp/ip-up started (pid 3457)
Jun 18 04:05:02 Resolventa pppd[3450]: Script /etc/ppp/ip-up finished (pid 3457), status = 0x0

Далее редактируете файл /etc/ppp/chap-secrets, вписав в него следущие строки:
# Secrets for authentication using CHAP
# client server secret IP addresses

мой_логин мой_пароль
Разделитель - пробел. Настройка сетевого интерфейса - присваиваем своей сетевой карте выданный провайдером IP-адрес в файле /etc/network/interfaces:
# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.ХХХ.ХХХ
netmask 255.255.255.0
gateway 192.168.ХХХ.1

Вместо ХХХ подставляем числа из договора. Теперь прописываем адреса DNS-серверов в /etc/resolv.conf (если его нет - создаём от рута touch /etc/resolv.conf):
nameserver 192.168.0.8
nameserver 192.168.0.9
Это ещё не всё: нужно прописать роутинги. Вот она, тайна Золотого Ключика:
ip r add 192.168.0.0/16 via 192.168.XX.1
ip r del default
ip r add default dev ppp0
Вместо ХХ подставить число, которое вы найдёте в договоре. После этого таблица роутинга должна выглядеть примерно так:

# route

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.0.20 * 255.255.255.255 UH 0 0 0 ppp0
192.168.157.0 * 255.255.255.0 U 0 0 0 eth0
192.168.0.0 gw-1-157.znet 255.255.0.0 UG 0 0 0 eth0
default * 0.0.0.0 U 0 0 0 ppp0
default gw-1-157.znet 0.0.0.0 UG 0 0 0 eth0

Готово - соединяемся с провайдером:
pppd call Znet
После этого всё должно работать.

Ссылки:

К сожалению, внутренний форум Znet/Net-by-Net не доступен извне, но раздел Linux там есть и местные аксакалы отвечают быстро и очень грамотно. За что им огромное спасибо.

16 комментариев: |высказаться!| RSS-лента дискуссии.|
v12aml комментирует...

нету больше знет, НЕТУ...
и я от туда тож скоро уволюсь =)

virens комментирует...

2 v12aml пишет...
нету больше знет, НЕТУ...
Оп-па... а как же так!? Пару месяцев назад ведь был. Куда делся!?

И кто теперь есть?

v12aml комментирует...

с мая месяца нет его, только нбн остался

Павел комментирует...

еще есть интересная надстройка гуишная network-manager-pptp после установки обязательно перегрузицо! Далее по значку сетевогосоединения и вперед!)))

virens комментирует...

2 v12aml пишет...
с мая месяца нет его, только нбн остался
А настройки те же? Я в августе настраивал - вроде работает.

2 Павел пишет...
еще есть интересная надстройка гуишная network-manager-pptp после установки обязательно перегрузицо!
Я у себя на блоге напишу крупными красными буквами: ЗДЕСЬ ГНОМА НЕТ!! И КДЕ ТОЖЕ НЕТ!!!!! :-)

На том компе стоит XFce - и где оно там, это нетворк-манагер-пптп!? Не убунтой же единой, друзья...

Alsvartr комментирует...

"mtu 1372
mru 1372

Заменяем мой_логин на нормальный логин и обращаем внимание на выделенные полужирным строки. Мне пришлось ради них ковыряться Аллах знает где на форумах iXBT - только после этого всё заработало (по умолчанию стоит 1378)!"
О да, из-за значений mtu часто возникают проблемы, причем с первого взгляда совершенно непонятно, куда копать. Еще распространенная проблема бывает при расшаривании vpn интернета на другие компьютеры, когда на втором выставлены неправильные значения mtu. В итоге либо ничего не грузится, но всё пингуется, либо что-то грузится, а остальное - нет :) Пакеты теряются, проще говоря.

raiontov комментирует...

ZNet был поглощен Net-by-Net, но на работе VPN это никак не сказалось, все это было формальной сменой логотипа компании и заменой билингового сервера.
За пост и, собственно, содействие в борьбе с этой виртуальной сетью автору низкий поклон.
P.S. Вдогонку сформулирую следующий вопрос: Как решается проблема аудиопотоков для IP-телефонии (например, WengoPhone)? То есть, когда входящий звук есть, а исходящий (с микрофона) теряется. Предположительно, здесь тоже причастен VPN-роутинг.

virens комментирует...

2 Alsvartr пишет...
О да, из-за значений mtu часто возникают проблемы, причем с первого взгляда совершенно непонятно, куда копать.
Ага, со мной такое тоже было: сижу и смотрю, а чего оно не пашет. И в самом деле не ясно, что делать. Ссылку на иксбитовскую конференцию не помню.

2 raiontov пишет...
ZNet был поглощен Net-by-Net, но на работе VPN это никак не сказалось, все это было формальной сменой логотипа компании и заменой билингового сервера.
Это хорошо, а то вон Центел в Кверти превратился, и такое началось - не дай бог никому.

За пост и, собственно, содействие в борьбе с этой виртуальной сетью автору низкий поклон.
Всегда пожалуйста, Игорь :-)

Вдогонку сформулирую следующий вопрос: Как решается проблема аудиопотоков для IP-телефонии (например, WengoPhone)?
Вот этого я, к сожалению, не знаю. На форуме Нет-бай-нета должны быть орлы, которые в курсе.

Yurror комментирует...

> sudo apt-get install pptpd pptp-linux
pptpd абсолютно бесполезен здесь.
вот если принимать входящие pptp тогда да.

chitatel комментирует...

Ээээ... оооо!!!... спасибо, virens. С помощью Вашей статьи настроил себе adsl, которым раньше не пользовался.

Успехов!

virens комментирует...

2 Yurror пишет...
pptpd абсолютно бесполезен здесь. вот если принимать входящие pptp тогда да.
Я решил перестраховаться :-) А вообще да, поправил.

2 Анонимный chitatel пишет...
Ээээ... оооо!!!... спасибо, virens. С помощью Вашей статьи настроил себе adsl
Пожалуйста. Просто мы с товарищем над этим знетом корпели и я решил выложить это сюда, дабы не пропадало даром.

Григорий комментирует...

остается только все route add|del добавить в /etc/ppp/ip-up.d/Znet
добавить ipparam Znet d /etc/ppp/peers/Znet
ну и сказать что-то вроде
auto ppp0
iface ppp0 inet ppp
provider Znet
в /etc/network/interfaces
P.S.: писал по старой памяти.

Анонимный комментирует...

Поздно наткнулся на статью ,к глубокому сожалению .Хотя понял вчем "ошибка" была.
Что касается "орлов" - то как попадешь , пишешь все сделал по ману и предоставляеш скрины, а они - думай головой и усмехаются =).
Сенкс за статью.

Geniot комментирует...

Подскажите, а что писать в конфиг-файлах, если в договоре нет ни выделенного ip адреса, ни днс-сервера?
При настройке в Windows в сетевом соединении указывается, что ip-адрес будет присвоен автоматически, а днс-сервер нигде не указывается. Выдаётся только ip-адрес, к которому надо коннектиться.

Анонимный комментирует...

Кроме уже упомянутой проблемы с MTU, которая возникает часто от того, что провайдер режет криво настроенным файрволом icmp-пакеты(не те, которые ping, а те что need-fragment), есть еще вторая особенность, которую можно назвать заворачиванием туннеля в самого себя:) Смысл в том, что по умолчанию таблица роутинга одна на всех, а пакеты-"носители" туннельного трафика тоже ею пользуются.
Соответственно надо быть особо внимательным в написании
строчки, указывающей default роутинг. В случае подключения к инету, он должен указывать на туннельный
интерфейс. А вот для того, чтобы пакеты-"носители" туннельного трафика могли ходить на машину, где расположен второй конец туннеля - роутинг туда надо
указать как route add -host, то есть не "вообще", а на конкретную эту машину. А то вон, у автора что-то два раза default выше упоминается, похоже просто повезло, что правильный встал раньше неправильного и поэтому второй не мешает. Хотя выглядит несколько криво.
Я много возился с туннелями, но не к провайдерам, а со своими собственными, так что мне были доступны настройки на обоих концах. Когда-то лет десять назад делал туннели
из простого "телефонного" pppd, позже использовал vtund
и openvpn. Openvpn сложнее в настройке, но позволяет подключать и виндовые машины. Но на процедуру соединения
кушает до нескольких десятков килобайтов трафика, что весьма неприятно когда туннель делает поверх GPRS для использования компрессии. vtund лишен этого недостатка и
работает совершенно безотказно,но только под юниксообразными ОС, поэтому удобен если на работе есть круглосуточно включенная линуксовая машина,
а из дома подключаешься с линуксового ноутбука через gprs - экономия трафика за счет сжатия от трети до половины в зависимости от того куда лазаешь.
А еще vtund умеет в качестве "носителей" туннельного трафика использовать не только tcp но и udp, что может
помочь обойти "злобный", но безграмотно настроенный файрвол:) А иногда помогает на каналах с потерями пакетов, например всякие экзотические радиолинки.

Владимир Леонов комментирует...

Где и как посмотреть в Debian 6.0.6 установился у меня драйвер на dvb карту SkyStar S2 или нет?

Отправить комментарий

Подписаться на RSS-ленту комментариев к этому посту.