Gmarapet

Автоматический l2tp / xl2tpd

Рекомендованные сообщения

Подскажите, пожалуйста.

Всё сделал, как написано.

 

Логи заполнены следующим:

Apr 28 10:10:42 tvg-desktop pppd[15159]: No auth is possible

Apr 28 10:10:42 tvg-desktop pppd[15159]: sent [LCP ConfRej id=0x7 <auth chap MD5>]

Apr 28 10:10:42 tvg-desktop pppd[15159]: rcvd [LCP ConfReq id=0x8 <mru 1460> <asyncmap 0xa0000> <auth chap MD5> <magic 0xa1b99f18>]

Apr 28 10:10:42 tvg-desktop pppd[15159]: No auth is possible

Apr 28 10:10:42 tvg-desktop pppd[15159]: sent [LCP ConfRej id=0x8 <auth chap MD5>]

Apr 28 10:10:42 tvg-desktop pppd[15159]: rcvd [LCP ConfReq id=0x9 <mru 1460> <asyncmap 0xa0000> <auth chap MD5> <magic 0xa1b99f18>]

Apr 28 10:10:42 tvg-desktop pppd[15159]: No auth is possible

Apr 28 10:10:42 tvg-desktop pppd[15159]: sent [LCP ConfRej id=0x9 <auth chap MD5>]

Apr 28 10:10:42 tvg-desktop pppd[15159]: rcvd [LCP ConfReq id=0xa <mru 1460> <asyncmap 0xa0000> <auth chap MD5> <magic 0xa1b99f18>]

 

 

/etc/xl2tpd/l2tp-secrets есть, всё есть.

В чём трябла?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Видимо, всё-таки не совсем точно :-)

 

Непонятно, зачем это

/etc/xl2tpd/l2tp-secrets есть, всё есть

В процессе участвует только /etc/ppp/chap-secrets

<ИМЯ ПОЛЬЗОВАТЕЛЯ> * <ПАРОЛЬ>

также нужно проверить, чтобы в /etc/ppp/options.xl2tpd

параметр name соответствовал имени пользователя

...
name <ИМЯ ПОЛЬЗОВАТЕЛЯ>
...

imho всё дело в этом...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

[global] ; Global parameters:

auth file = /etc/xl2tpd/l2tp-secrets ; * Where our challenge secrets are

access control = yes ; * Refuse connections without IP match

 

[lac corbina]

lns = l2tp.corbina.net

redial = yes

redial timeout = 3

name = LOGIN

require chap = yes

require pap = no

require authentication = no

pppoptfile = /etc/ppp/options.xl2tp

ppp debug = yes

autodial = yes

 

 

вот так и не работает.

 

/etc/xl2tp/l2tp-secrets :

 

LOGIN * PAROL *

 

без последней звёздочки тоже пробовал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
auth file = /etc/xl2tpd/l2tp-secrets ; * Where our challenge secrets are

Читай мой предыдущий пост. ЭТО НЕ НУЖНО. Это нужно только тогда, когда мы сервер.

В режиме клиента за аутентификацию/авторизацию отвечает pppd.

 

Вообще, если нет сил/желания читать тему, зачем задавать в ней вопросы ?

Извини за резкость - я вроде по-русски написал, тебе в том числе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

внёс пароли в chap-secrets, соединилось, прописал маршрут скриптом, но связи нет.

 

route -n выдаёт 3 маршрута, 2 на eth0 и 1 на ppp0 (http://homenet.corbina.net/index.php?showtopic=69646).

 

то есть маршрут до сервера l2tp есть и, вообще говоря, он пингуется.

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

 

BuHTOKPbIJI,

откуда вообще такая резкость? видно же, что в сообщении я вас ещё не прочёл или не дописал его.

 

auth file = /etc/xl2tpd/l2tp-secrets ; * Where our challenge secrets are

 

и вообще, крайне неочевидно, что эта строчка не работает. Спасибо, что подсказали, но это полный бред (со стороны разработчиков xl2tp).

 

"В режиме клиента за аутентификацию/авторизацию отвечает pppd."

я так понял, оно передаёт параметр в pppd...

Изменено пользователем Евгенийй

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
откуда вообще такая резкость? видно же, что в сообщении я вас ещё не прочёл или не дописал его.

Был неправ. Погорячился. Еще раз прошу прощения.

Спасибо, что подсказали, но это полный бред (со стороны разработчиков xl2tp).

Документация к xl2tpd вообще очень неполная, а местами откровенно не соответствует действительности.

Массу интересного обнаружил, ковыряясь в исходниках :-)

2) Паразитный маршрут нужно удалять в ip-up сразу же после установления pptp-соединения:

Явная проблема маршрутизации. Не нужно удалять якобы "паразитный маршрут". Это вовсе не паразит. :-)

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

См. пункты 2 и 3

Изменено пользователем BuHTOKPbIJI

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

BuHTOKPbIJI,

маршрут до l2tp-сервера через ppp0 - это явно паразитарный маршрут, в чём я неправ?

 

ip route add $5 via 10.112.80.1 dev eth0 - это вы предлагаете

 

правильнее будет исключить тут VIA 1.1.1.1 вообще, оставив только интерфейс. у меня такая штука стоит в ip-up.d/, работает, только до этого я добавил ip route del $5 dev ppp0 чтобы удалять "паразитный" маршрут.

 

 

то, что вы написали, я сделал, в таком случае существуют оба маршрута до l2tp-сервера: через оба интерфейса. И тоже ничего не работает.

 

В OpenWRT, к примеру, достаточно было просто писать эти строчки.

Изменено пользователем Евгенийй

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
маршрут до l2tp-сервера через ppp0 - это явно паразитарный маршрут, в чём я неправ?

Неправ в том, что маршут scope вовсе не паразит, а неотъемлемая часть любой таблицы маршрутизации.

Подробнее

ip route add $5 via 10.112.80.1 dev eth0 - это вы предлагаете

Да в общем можно и без шлюза маршрут написать, как кому удобнее...

dns-серверы уже не пингуются, как не работает и интернет. То есть пакеты через интерфейс ppp0 не идут

Похоже на "стандартную" проблему отсутствия default route через ppp интерфейс.

Чтобы сказать точно, хочу увидеть вывод команды

ip route

на товей машине.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Неправ в том, что маршут scope вовсе не паразит, а неотъемлемая часть любой таблицы маршрутизации.

Подробнее

 

Можно вкратце? В своё время я это читал. Точнее, здесь даже ссылка не нужна, просто поясните, каким образом маршрут через сам себя может выполнять какую-то функцию и зачем он добавляется, кроме как баг в pppd?

 

Похоже на "стандартную" проблему отсутствия default route через ppp интерфейс.

Чтобы сказать точно, хочу увидеть вывод команды

ip route

на товей машине.

 

Я не с этой машины пишу. Маршрута 3: один на локальную подсеть, другой до l2tp-сервера, 3ий по умолчанию на ppp0. Вот так-то.

 

Неправ в том, что маршут scope вовсе не паразит, а неотъемлемая часть любой таблицы маршрутизации.

 

Любой таблицы под линукс? Сомневаюсь.

 

Под виндой нету такого. Вот маршрут до сервера:

 

[pppserver] 85.21.0.55 [mask]255.255.255.255 [gw] 10.gw.8.1 [iface] 10.thisis.my.ip [metric] 20

 

и больше никакого "нормального" нет.

 

чтобы пинговались DNS-ки, надо отдельный маршрут на них через шлюз или, естественно, рабочий ppp0.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Под виндой нету такого

Улыбнуло. Без комментариев ...

 

Можно вкратце? В своё время я это читал. Точнее, здесь даже ссылка не нужна, просто поясните, каким образом маршрут через сам себя может выполнять какую-то функцию и зачем он добавляется, кроме как баг в pppd?

Вот оно: IP Scope under ip address

По прочтении ясно, что это не может быть багом pppd, да и багом вообще.

pppd не отвечает за маршрутизацию. Отвечает kernel:-)

 

Любой таблицы под линукс?

Причем здесь linux ?

Маршрута 3:

три - это мало.

 

Резюме: пока не увижу, что просил, ничем помочь не могу.

Изменено пользователем BuHTOKPbIJI

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

BuHTOKPbIJI,

маршрут до l2tp-сервера через ppp0 - это явно паразитарный маршрут, в чём я неправ?

На самом деле, правы оба - каждый по-своему.

 

Прав BuHTOKPbIJI в том, что маршрут до peer'а совершенно естественен для любого юникса. pppd явно его устанавливает в любом юниксе, кроме линукса версии больше 2.1.16 - там этот маршрут создает кернел. На самом деле, этот адрес никто не использует (просто исторически сложилось, что он устанавливается). И многие провайдеры выдают в качестве peer'а 1.1.1.1 (или что-то подобное).

 

Но в случае Корбины адрес ppp-peer'а совпадает с адресом самого сервера. За такие инженерные решения я бы отрывал руки и ноги. Хотя явного запрета так делать я пока не нашел...

 

Поэтому прав Евгенийй, что этот маршрут надо удалять (либо нейтрализовать другим способом).

ip route add $5 via 10.112.80.1 dev eth0 - это вы предлагаете

 

правильнее будет исключить тут VIA 1.1.1.1 вообще, оставив только интерфейс. у меня такая штука стоит в ip-up.d/, работает, только до этого я добавил ip route del $5 dev ppp0 чтобы удалять "паразитный" маршрут.

Не понимаю, как это может работать только через интерфейс без явного gateway. Скорее всего, фактически работает другой маршрут (на подсеть - при условии удаления "паразитного").

то, что вы написали, я сделал, в таком случае существуют оба маршрута до l2tp-сервера: через оба интерфейса. И тоже ничего не работает.

Из таких двух маршрутов будет работать тот, что установлен позже.

 

Евгенийй, пара хинтов:

1. У меня на маршрутизаторе с утра работает xl2tpd с такими конфигами:

~ # cat /tmp/xl2tpd.conf
[global]
access control = yes
[lns default]
; nothing
[lac назови-как-хочешь]
lns = l2tp.corbina.net
redial = yes
redial timeout = 30
pppoptfile = /tmp/xl2tpd/options.vpn
~ # cat /tmp/xl2tpd/options.vpn
defaultroute
replacedefaultroute; не все версии pppd это поддерживают
lock
noauth
refuse-eap
lcp-echo-failure 3; не знаю, зачем это надо
lcp-echo-interval 2; см. выше
persist
usepeerdns
idle 0
ip-up-script /tmp/xl2tpd/ip-up
ip-down-script /tmp/xl2tpd/ip-down
ipparam xl2tpd

mtu 1450
mru 1450
name XXX
password YYY

 

2. Когда я экспериментировал на линуксе (SuSe 10.2, Athlon 1.4), "route del..." в /etc/ppp/ip-up.local не помогал - слишком поздно. Сработало только добавление "route del..." первой строчкой (в case...ip-up) в /etc/ppp/ip-up.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

BuHTOKPbIJI,

"pppd не отвечает за маршрутизацию. Отвечает kernel:-)"

pppd добавляет маршрут, а кто отвечает за маршрутизацию - я бы сказал, что процессор и сетевая плата, как вам такой подход?

 

Mozos,

 

"Не понимаю, как это может работать только через интерфейс без явного gateway. Скорее всего, фактически работает другой маршрут (на подсеть - при условии удаления "паразитного")."

 

gateway неявно берётся из по умолчанию для данного интерфейса и подставляется, так что маршрут получается такой же.

 

"Но в случае Корбины адрес ppp-peer'а совпадает с адресом самого сервера. За такие инженерные решения я бы отрывал руки и ноги. Хотя явного запрета так делать я пока не нашел..."

 

Тут я немного не понимаю. А как ещё peer может не совпадать с адресом сервера? Ведь протокол point-to-point, где сервр и является пойнтом (пиром). Чего я не допонимаю?

 

pppd виноват не в том, что добавляет маршрут "до пира", а в том, что осуществляет петлю.

 

А глобально я не понимаю одного: почему несложная и повседневная вещь так проста в винде и так сложна (и наполнена багами) в линуксе? В чём тут смысл, причина?

 

BuHTOKPbIJI,

"три - это мало."

а сколько должно быть? какого не хватает?

 

ip route сделаю.

 

BuHTOKPbIJI,

прочитал про scope, текст понял, но не понял, каким образом это применимо к нашему случаю. А конкретно к: маршруту до сервера, обслуживающего интерфейс, через сам этот обслуживаемый интерфейс.

возможно, моя вина.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
а кто отвечает за маршрутизацию - я бы сказал, что процессор и сетевая плата, как вам такой подход?

В таком случае за маршрутизацию отвечают электронно-дырочные пары.

 

а сколько должно быть? какого не хватает?

~ 20

Не хватает следовательно ~ 17

Изменено пользователем BuHTOKPbIJI

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

BuHTOKPbIJI,

ну, это шутка. Кто ж виноват, что dhcp-клиент или avahi не подхватывает раздаваемые маршруты.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Mozos,

"Не понимаю, как это может работать только через интерфейс без явного gateway. Скорее всего, фактически работает другой маршрут (на подсеть - при условии удаления "паразитного")."

 

gateway неявно берётся из по умолчанию для данного интерфейса и подставляется, так что маршрут получается такой же.

Теоретически, такая модель имеет право на существование, но я пока не слышал, чтобы такое было где-то реализовано - непонятно, зачем это было бы нужно.

На самом деле в линуксе можно сделать примерно такое при помощи ip route/ip rule.

"Но в случае Корбины адрес ppp-peer'а совпадает с адресом самого сервера. За такие инженерные решения я бы отрывал руки и ноги. Хотя явного запрета так делать я пока не нашел..."

 

Тут я немного не понимаю. А как ещё peer может не совпадать с адресом сервера? Ведь протокол point-to-point, где сервр и является пойнтом (пиром). Чего я не допонимаю?

Возможно, я недостаточно понятно выразился. По идеологии ppp-протокола это должен быть адрес соответствующего ppp-интерфейса сервера. Я готов согласиться, пусть этот адрес окажется "нелегальным" (10.x.x.x, 172.x.x.x, 192.168.x.x). Я готов даже смириться (это было бы некрасиво, но, по крайней мере, не создало бы мне никаких проблем), если этот адрес не будет совпадать с адресом интерфейса пира при условии, что этот фиктивный адрес никогда мне не может понадобиться.

pppd виноват не в том, что добавляет маршрут "до пира", а в том, что осуществляет петлю.

Исторически ppp-протокол создавался для соединений через COM-порт. При этом любой из концов мог иметь дефолт маршрут до другого. Совершенно естественно, что после поднятия ppp, кратчайший маршрут до пира оказывается через этот самый вновь поднятый интерфейс. По этой причине pppd явно прописывает такой маршрут (за исключением случая, когда это же за него делает ядро). Для туннелей это несправедливо, но никто не говорит pppd, что он работает через туннель. [На самом деле, идея интересная - стоит проработать...]

И проблема растет из того, что VPN-сервер сказал pppd (который не знает ни про туннель, ни про адрес этого VPN-сервера), что кратчайший маршрут до адреса x.x.x.x - это именно через ppp-интерфейс. Все бы ничего, но вот незадача - этот x.x.x.x оказывается фактически внешним адресом того самого сервера, до которого обычными маршрутами пилить и пилить, и который нам нужен именно для того, чтобы открыть туннель...

pppd сообщает ядру, что у него есть новый замечательный маршрут на x.x.x.x, а в итоге оказывается, что pptp, который должен был обеспечивать транспорт для pppd, шлет "свои" (на самом деле, pppd-шные) пакеты как раз через ppp ;) ...

А глобально я не понимаю одного: почему несложная и повседневная вещь так проста в винде и так сложна (и наполнена багами) в линуксе? В чём тут смысл, причина?

:cray: Есть много других вещей, которые в юниксе делаются за минуту, а в винде требуют полчаса насилия над мышью :) Просто в данном случае некий человек, считающий себя специалистом (поймаю - буду бить!), принял совершенно неграмотное решение, проверил его с виндой - оказалось, что работает. И вовсе не потому, что для винды надо именно так, а просто потому, что винде это решение оказалось по-барабану - другая идеология. После этого "инженер" решил, что дело сделано, а если у кого не работает, тот сам дурак...

 

Хинтую дальше: чтобы избавиться от зацикливания, можно сделать так:

В ip-up для eth0 (который вызывается DHCP-клиентом) добавить после "route add default..." строчку

"ip route add default gw $DEFAULT_GW table 100" (тот же самый гэйтвэй). И далее - "ip rule add from $ETH0_IP table 100 pri 1000". (деталей синтаксиса не помню, а ман не под рукой) Тем самым мы а) дублируем дефолт маршрут в таблице 100 (число произвольное от 1 до 252). Этот маршрут не убьется после "route add default..." от pppd. И б) создаем правило, что все пакеты с исходящим адресом нашего интерфейса eth0 должны отправляться по маршрутам из таблицы 100, независимо от того, какая маршрутизация установлена "route add/del..." - route оперирует таблицей 255 (или 254 - не помню). В результате для всех соединений, созданных до поднятия ppp, маршрутизация должна остаться прежней.

Если это не поможет, придется сильно думать...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Mozos, в результате получается, что pppd соответствует всё больше историческим реалиям, чем современным, это примерно как обработка клавиш управления в консоли *nix.

 

К сожалению, всё это в конец мне надоело и в сочетании с другими проблемами убунты её пришлось убить и заменить на винду, чем и доволен. Так что всё. Спасибо за хинты.

Изменено пользователем Евгенийй

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

May 15 20:50:18 deus pppd[20058]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x1641543c>]
May 15 20:50:18 deus pppd[20058]: rcvd [LCP ConfReq id=0x1 <mru 1460> <asyncmap 0xa0000> <auth chap MD5> <magic 0xfc2973bb> <pcomp> <accomp>]
May 15 20:50:18 deus pppd[20058]: No auth is possible

 

Хотя вроде в конфигах все правильно

 

cat /etc/xl2tpd/xl2tpd.conf

 

[global]
access control = yes

[lac corbina]
lns = l2tp.corbina.net
redial = yes
redial timeout = 1
require chap = yes
require authentication = no
name = vovax
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
require pap = no
autodial = yes

 

cat /etc/ppp/options.xl2tpd

 

name vovax
remotename l2tp
ipparam corbinal2tp
connect /bin/true
nodeflate
nobsdcomp
persist
maxfail 0
nopcomp
noaccomp
defaultroute
noauth

 

Все смог настроить :offtopic: В файле с паролем была кривизна

 

Подключение работает, интрнет работает но в лог сыпится:

 

 

May 15 22:35:51 deus pppd[21628]: Failed to open /dev/pts/4: No such file or directory
May 15 22:35:54 deus pppd[19897]: Failed to open /dev/pts/3: No such file or directory
May 15 22:35:57 deus pppd[19780]: Failed to open /dev/pts/1: No such file or directory
May 15 22:36:00 deus dhclient: DHCPREQUEST on eth2 to 83.102.233.202 port 67

 

Помогите кто нибуть, а то к вечеру от лога хард коньчится :angry:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

К сожалению, всё это в конец мне надоело и в сочетании с другими проблемами убунты её пришлось убить и заменить на винду, чем и доволен. Так что всё. Спасибо за хинты.

слабак ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Настроил всё точь в точь по мануалу, интерфейс ppp0 не поднимается при старте системы

при запуске через /etc/init.d/xl2tpd start

выдает /etc/init.d/xl2tpd: 43: Syntax error: ")" unexpected (expecting ";;")

 

 

не подскажете, где копать?

 

 

#! /bin/sh

 

### BEGIN INIT INFO

# Provides: xl2tpd l2tpd

# Required-Start: $network $syslog

# Required-Stop: $network $syslog

# Should-Start: ipsec

# Should-Stop: ipsec

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: layer 2 tunelling protocol daemon

# Description: xl2tpd is usually used in conjunction with an ipsec

# daemon (such as openswan).

### END INIT INFO

 

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

DAEMON=/usr/sbin/xl2tpd

NAME=xl2tpd

DESC=xl2tpd

 

test -x $DAEMON || exit 0

 

# Include xl2tpd defaults if available

if [ -f /etc/default/xl2tpd ] ; then

. /etc/default/xl2tpd

fi

 

set -e

 

case "$1" in

start)

if !([ -f /var/run/xl2tpd/l2tp-control ]) ; then

mkdir -p /var/run/xl2tpd

touch /var/run/xl2tpd/l2tp-control

fi

echo -n "Starting $DESC: "

start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \

--exec $DAEMON -- $DAEMON_OPTS

echo "$NAME."

route add -host 85.21.0.255 gw 10.239.40.0

route add -host 213.234.192.8 gw 10.239.40.0

route add -host 85.21.192.3 gw 10.239.40.0

stop)

echo -n "Stopping $DESC: "

start-stop-daemon --oknodo --stop --quiet --pidfile /var/run/$NAME.pid \

--exec $DAEMON

echo "$NAME."

;;

force-reload)

# check whether $DAEMON is running. If so, restart

start-stop-daemon --stop --test --quiet --pidfile \

/var/run/$NAME.pid --exec $DAEMON \

&& $0 restart \

|| exit 0

;;

restart)

echo -n "Restarting $DESC: "

start-stop-daemon --stop --quiet --pidfile \

/var/run/$NAME.pid --exec $DAEMON

sleep 1

start-stop-daemon --start --quiet --pidfile \

/var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS

echo "$NAME."

;;

*)

N=/etc/init.d/$NAME

echo "Usage: $N {start|stop|restart|force-reload}" >&2

exit 1

;;

esac

 

exit 0

Изменено пользователем Naxu1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Naxu1, попробуй перед "stop)" строкой выше поставить ;;

Подключение работает, интрнет работает но в лог сыпится:

Та же фигня. Подозреваю, что pppd не убивается при обрыве соединения, поэтому при реконнекте пишется ошибка в лог. Перед реконнектом можно подождать, пока pppd отвалится, а можно и вручную убить процесс. С dhcp не знаю как бороться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Та же фигня. Подозреваю, что pppd не убивается при обрыве соединения, поэтому при реконнекте пишется ошибка в лог. Перед реконнектом можно подождать, пока pppd отвалится, а можно и вручную убить процесс. С dhcp не знаю как бороться.

 

У меня в лог сыпится постоянно, не зависимо от реконектов

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
May 15 22:35:51 deus pppd[21628]: Failed to open /dev/pts/4: No such file or directory

May 15 22:35:54 deus pppd[19897]: Failed to open /dev/pts/3: No such file or directory

May 15 22:35:57 deus pppd[19780]: Failed to open /dev/pts/1: No such file or directory

Явно видно, что разные процессы гадят.

Подозреваю, что pppd не убивается при обрыве соединения

Почти так.

xl2tpd при остановке посылает pppd SIGKILL вместо SIGTERM.

Описание.

Реально это было нужно только для ppp-2.4.2. В данный момент в большинство дистрибутивов входит ppp-2.4.4.

Чтобы xl2tpd посылал pppd SIGTERM, нужно собрать его из исходников,

предварительно добавив в Makefile после строки

DFLAGS= -DDEBUG_PPPD

строку

DFLAGS+= -DTRUST_PPPD_TO_DIE

.

 

У кого ядро новее 2.6.23.5 может заодно раскомментировать строку

OSFLAGS+= -DUSE_KERNEL

чтобы xl2tpd поддерживал работу с kernel-модулем.

 

Вообще, с течением времени накопилось несколько уточнений и дополнений к этой теме.

Надо бы мне собраться с мыслями и отредактировать свой пост в начале темы ... :)

Изменено пользователем BuHTOKPbIJI

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Naxu1, попробуй перед "stop)" строкой выше поставить ;;

Та же фигня. Подозреваю, что pppd не убивается при обрыве соединения, поэтому при реконнекте пишется ошибка в лог. Перед реконнектом можно подождать, пока pppd отвалится, а можно и вручную убить процесс. С dhcp не знаю как бороться.

 

Спасиб, косяк исправил, но все равно соединение ppp не поднимается,

 

sudo /etc/init.d/xl2tpd start

Starting xl2tpd: balu161@balu161-desktop:~$

и тишина...

 

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

Изменено пользователем Naxu1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Naxu1, это маршрут по умолчанию. Показывай route -n до и после соединения. И назови дистриб.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

дистриб ubuntu 8.04

 

сейчас после перезагрузки локалка заработала. и при старте системы ppp не поднимался

 

вывод route -n

 

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

10.239.40.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0

169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0

0.0.0.0 10.239.40.1 0.0.0.0 UG 100 0 0 eth0

 

 

дистриб ubuntu 8.04

 

сейчас после перезагрузки локалка заработала. и при старте системы ppp не поднимался

 

вывод route -n

 

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

10.239.40.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0

169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0

0.0.0.0 10.239.40.1 0.0.0.0 UG 100 0 0 eth0

 

 

после очередного ребута опять поднялся ppp и перестала работать локалка

 

вывод route -n при поднятом ppp0

 

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

85.21.0.252 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

10.239.40.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0

169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0

0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

Изменено пользователем Naxu1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
после очередного ребута опять поднялся ppp и перестала работать локалка

Интернет работает?

Если нет, то попробуй так:

в конец файла /etc/ppp/ip-up добавить

/sbin/route del $5 dev ppp0
/sbin/route del default
/sbin/route add -host $5 gw твой шлюз
/sbin/route add default dev ppp0

/etc/ppp/ip-down

/sbin/route del $5
/sbin/route del default dev ppp0

Неработающая локалка - это потому что нет маршрутов до локальных ресурсов. Можно воспользоваться этим. помогите настроить интернет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Интернет не работает, добавил, ничего не изменилось, ppp0 поднимается на минуту и потом опять пропадает, подняты только lo и eth0. Причем при не поднятом ppp0 локалка все равно не работает. уже не знаю на что грешить

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1.

Интернет не работает, добавил, ничего не изменилось

Маршрутизация однозначно, почитай в этой же теме, на предыдущей странице

Шлюз вместо 10.112.80.1 соответственно, свой.

 

2.

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

85.21.0.252 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

10.239.40.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0

169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0

0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

Мало. Не настроен dhclient

Изменено пользователем BuHTOKPbIJI

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

СПС! Настроил! Доволен как слон

274625460.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Господа, непонятка какая-то.

Debian testing, делал все по мануалу - стартую и нифига.

Ладно, наплевал, взял пакеты из Ubuntu и прописал все, как в недавнем руководстве, итог тот же.

Нифига выражается в появлении строчек:

May 26 09:15:47 nix -- MARK --

в /var/log/messages и отсутствии каких-либо признаков жизнедеятельности. Что с модулем ядра, что без. Я ничего не понимаю, есть идеи?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас