[Sysadmins] PPtP: разные localip, опционально MPPE

[Sysadmins] PPtP: разные localip, опционально MPPE

[ABATAPA]

			Доброго дня!
          Скажите, пожалуйста, у кого-нибудь работает _опциональное_ 
шифрование MPPE в pptp? Насколько я знаю, в pppd 2.4.2+ сеть только опции 
require-mppe (require-mppe requires the use of MPPE, disabling all other 
compression types, and enabling both 40-bit and 128-bit encryption), и 
require-mppe-128, require-mppe-40 (require-mppe-40 and require-mppe-128 are 
like require-mppe but use 40-bit and 128-bit encryption respectively, rather 
than allowing the server to choose.). Как мне тогда сделать возможным 
подключение клиентов, не использующих шифрование, наравне с использующими?
         И второй вопрос: как заставить pptpd выдавать localip, равный IP, на 
который получен запрос (при listen 0.0.0.0)? Есть разные интерфейсы, разные 
сети, между ними нет роутинга (хотя бы потому, что они приватные и из разных 
диапазонов). Хочется, чтобы pptpd, получив запрос, скажем, с eth0 с 
172.16.1.1, отдавал в peer именно этот IP, т.к. клиенту не будет доступен 
иной. Сейчас же  указание множества IP  в этом параметре просто 
подразумевает, что каждому клиенту будет назначен свой IP со стороны сервера.
-- 
ABATAPA

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[ABATAPA]

	Доброго дня!
Никто не ответит?
-- 
ABATAPA

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Dank Bagryantsev]

Здравствуйте, ABATAPA.

Вы писали воскресенье 28 мая 2006 г., 16:23:55:

A>           Скажите, пожалуйста, у кого-нибудь работает _опциональное_
A> шифрование MPPE в pptp? Насколько я знаю, в pppd 2.4.2+ сеть только опции
A> require-mppe (require-mppe requires the use of MPPE, disabling all other
A> compression types, and enabling both 40-bit and 128-bit encryption), и
A> require-mppe-128, require-mppe-40 (require-mppe-40 and require-mppe-128 are
A> like require-mppe but use 40-bit and 128-bit encryption respectively, rather
A> than allowing the server to choose.). Как мне тогда сделать возможным 
A> подключение клиентов, не использующих шифрование, наравне с использующими?

Если мне склероз не изменяет, то вроде этот вопрос уже обсуждался с
Вами? :)
у меня одновременно не заработало.
а точно у Вас оборудование не работает с require-mppe-40 ?
Может, то что Вы хотите можно сделать вообще по другому? Не применяя
VPN?

A>          И второй вопрос: как заставить pptpd выдавать localip, равный IP, на
A> который получен запрос (при listen 0.0.0.0)? Есть разные интерфейсы, разные
A> сети, между ними нет роутинга (хотя бы потому, что они приватные и из разных
A> диапазонов). Хочется, чтобы pptpd, получив запрос, скажем, с eth0 с 
A> 172.16.1.1, отдавал в peer именно этот IP, т.к. клиенту не будет доступен
A> иной.

Почему не будет доступен иной?
если у Вас например, IP на eth0 172.16.1.1/255.255.255.0
на eth1 172.16.2.1/255.255.255.0
и клиенты 172.16.1.0/24 в одном случае указывают VPN-сервер
172.16.1.1, в другом 172.16.2.0/24 - 172.16.2.1

например в pptpd.conf :
localip 10.0.0.1
remoteip 10.0.0.2-254

после подключения, у клиента 10.0.0.2 (например) и он видит серверную
сторону туннеля как 10.0.0.1. Если еще у него default route на VPN, то
всё на неизвестные IP будет посылать через туннель.

Или чего Вы хотите добиться вообще?

A> Сейчас же  указание множества IP  в этом параметре просто 
A> подразумевает, что каждому клиенту будет назначен свой IP со стороны сервера.

за назначение IP клиентам это ж вроде опция remoteip отвечает?
Если я не ошибаюсь, localip в pptpd.conf это адрес сервера уже _после_
подключения клиента. Он, например, виден в свойствах _уже_ подключенного
VPN-соединения.

-- 
С уважением,
 Dank

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[ABATAPA]

1 июня 2006 21:43, Dank Bagryantsev написал:
> Здравствуйте, ABATAPA.
> Если мне склероз не изменяет, то вроде этот вопрос уже обсуждался с
> Вами? :)

Но решения-то не было.

> а точно у Вас оборудование не работает с require-mppe-40 ?
У меня - PocketPC 2003, Asus MyPal A716. Ну знаю почему, но его VPN (PPtP) не 
держит MPPE, в логах сервера: "MPPE required but peer negotiation failed". 
Без MPPE - работает.

> Может, то что Вы хотите можно сделать вообще по другому? Не применяя
> VPN?
"Возможно все." (с)
Но мне нужно именно это.

> Почему не будет доступен иной?
Потому что в любом случае будет выдан IP из параметра localip.
Если это _разные изолированные_ сети, то для других сетей этот  IP может быть 
недоступен.
В данной ситуации - так и есть.
> если у Вас например, IP на eth0 172.16.1.1/255.255.255.0
> на eth1 172.16.2.1/255.255.255.0
> и клиенты 172.16.1.0/24 в одном случае указывают VPN-сервер
> 172.16.1.1, в другом 172.16.2.0/24 - 172.16.2.1
То, что указывают - это одно, а то, что передается как параметры туннеля - 
другое.
> например в pptpd.conf :
> localip 10.0.0.1
> remoteip 10.0.0.2-254
В этом случае после подключения серверная сторона туннеля будет иметь 
адрес "10.0.0.1", но адрес этот из другой сети (по отношению к клиенту), 
следовательно, на него должен быть доступен маршрут (без default route).
А если этот адрес вообще недоступен?
> после подключения, у клиента 10.0.0.2 (например) и он видит серверную
> сторону туннеля как 10.0.0.1. Если еще у него default route на VPN, то
> всё на неизвестные IP будет посылать через туннель.
Если у него default route на VPN, а у клиента 172.16.xx.xx,  то маршрут на 
10.0.0.1 не будет доступен.
Это самая частая ошибка, я даже как-то кому-то тут раза три объяснял это, и 
вписал в WiKi - VPN сервер должен быть доступен _не_ по default route, т.к. 
последний после подключения сменится, пакеты перестанут находить сервер, 
связь порвется.

> Или чего Вы хотите добиться вообще?
Я хочу, чтобы сервер смотрел в несколько различных _изолированных_ сетей (т.е. 
listen 0.0.0.0), и localip передавал клиенту тот, на который он получил 
запрос от него, и, помимо этого, _опционально_ поддерживал MPPE.
>
> за назначение IP клиентам это ж вроде опция remoteip отвечает?
> Если я не ошибаюсь, localip в pptpd.conf это адрес сервера уже _после_
> подключения клиента. Он, например, виден в свойствах _уже_ подключенного
> VPN-соединения.
О том и речь. _После_ соединения (вернее, в процессе) он передается клиенту, 
и... Если этот адрес клиенту не доступен - пакеты до сервера, разумеется, не 
доходят. Но по первоначальному-то IP сервер доступен!
Экспериментировал с КПК много. Стоит поменять localip в настройках pptpd на 
адрес из сети клиента (т.е. совпадающий с адресом сервера, прописанным в 
свойствах подключения) - все работает. Иначе - все как я описал.
-- 
ABATAPA

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Dank Bagryantsev]

Здравствуйте, ABATAPA.

Вы писали пятница 2 июня 2006 г., 10:16:15:

A> 1 июня 2006 21:43, Dank Bagryantsev написал:
>> Здравствуйте, ABATAPA.
>> Если мне склероз не изменяет, то вроде этот вопрос уже обсуждался с
>> Вами? :)

A> Но решения-то не было.

Правильного, да не было. Но был костыль: сделать два pptpd-сервера с
разными параметрами шифрования на разных IP.

>> а точно у Вас оборудование не работает с require-mppe-40 ?
A> У меня - PocketPC 2003, Asus MyPal A716. Ну знаю почему, но его VPN (PPtP) не
A> держит MPPE, в логах сервера: "MPPE required but peer negotiation failed".
A> Без MPPE - работает.

Может не поддерживает строгое шифрование (require-mppe-128), а обычное
(require-mppe-40) поддерживает?
Какое шифрование пароля применяете/доступно?

>> Может, то что Вы хотите можно сделать вообще по другому? Не применяя
>> VPN?
A> "Возможно все." (с)
A> Но мне нужно именно это.

А OpenVPN Вам не подойдет? Там кстати, очень просто можно на клиентов
"проталкивать" маршруты...

>> Почему не будет доступен иной?
A> Потому что в любом случае будет выдан IP из параметра localip.
A> Если это _разные изолированные_ сети, то для других сетей этот  IP может быть
A> недоступен.
A> В данной ситуации - так и есть.

>> если у Вас например, IP на eth0 172.16.1.1/255.255.255.0
>> на eth1 172.16.2.1/255.255.255.0
>> и клиенты 172.16.1.0/24 в одном случае указывают VPN-сервер
>> 172.16.1.1, в другом 172.16.2.0/24 - 172.16.2.1
A> То, что указывают - это одно, а то, что передается как параметры туннеля -
A> другое.
>> например в pptpd.conf :
>> localip 10.0.0.1
>> remoteip 10.0.0.2-254
A> В этом случае после подключения серверная сторона туннеля будет иметь 
A> адрес "10.0.0.1", но адрес этот из другой сети (по отношению к клиенту),
A> следовательно, на него должен быть доступен маршрут (без default route).

После подключения клиент имеет уже еще и IP 10.0.0.2/255.255.255.0 и
соответственно у него должна автоматически возникнуть в
таблице/подсистеме маршрутизации запись, что сеть 10.0.0.0/24 доступна
через туннель. 

A> А если этот адрес вообще недоступен?
>> после подключения, у клиента 10.0.0.2 (например) и он видит серверную
>> сторону туннеля как 10.0.0.1. Если еще у него default route на VPN, то
>> всё на неизвестные IP будет посылать через туннель.
A> Если у него default route на VPN, а у клиента 172.16.xx.xx,  то маршрут на
A> 10.0.0.1 не будет доступен.
A> Это самая частая ошибка, я даже как-то кому-то тут раза три объяснял это, и
A> вписал в WiKi - VPN сервер должен быть доступен _не_ по default route, т.к.
A> последний после подключения сменится, пакеты перестанут находить сервер,
A> связь порвется.

Я имел ввиду (для случая WinXP клиентов) установленную опцию
"Использовать основной шлюз в удаленной сети" 
в свойствах VPN-соедиенния, т.е. маршрут по умолчанию через
VPN-туннель.
И кстати, опять таки для WinXP-клиентов, после подключения
VPN-соединения, default route переопределяется, т.е. связь не рвется.
IMHO, меняются метрики/приоритеты маршрутов по умолчанию.
IMHO, такой же подход (разные метрики маршрутов по умолчанию) можно
применять и в linux.

>> Или чего Вы хотите добиться вообще?
A> Я хочу, чтобы сервер смотрел в несколько различных _изолированных_ сетей (т.е.
A> listen 0.0.0.0), и localip передавал клиенту тот, на который он получил
A> запрос от него, и, помимо этого, _опционально_ поддерживал MPPE.

У меня pptpd смотрит в несколько интерфейсов/изолированных сетей, на
VPN-сервере в pptpd.conf в localip один IP, в options.pptpd require-mppe-40.
Через радиус, клиентам (WinXP) выдаются IP в другой сети, чем localip.
На клиентах в опциях VPN-соедиенения стоит
"Использовать основной шлюз в удаленной сети". Все работает.
Чем такая маршрутизация Вас не устраивает? (если отбросить вопрос с
шифрованием)

>>
>> за назначение IP клиентам это ж вроде опция remoteip отвечает?
>> Если я не ошибаюсь, localip в pptpd.conf это адрес сервера уже _после_
>> подключения клиента. Он, например, виден в свойствах _уже_ подключенного
>> VPN-соединения.
A> О том и речь. _После_ соединения (вернее, в процессе) он передается клиенту,
A> и... Если этот адрес клиенту не доступен - пакеты до сервера, разумеется, не
A> доходят. Но по первоначальному-то IP сервер доступен!

Уточните, у Вас IP интерфейса КПК и IP интерфейса VPN-сервера в одной
сети? И IP интерфейса VPN-сервера доступен без записи default route в
таблице маршрутизации на КПК?

A> Экспериментировал с КПК много. Стоит поменять localip в настройках pptpd на
A> адрес из сети клиента (т.е. совпадающий с адресом сервера, прописанным в
A> свойствах подключения) - все работает. Иначе - все как я описал.

IMHO, проблема не в localip на VPN-сервере, а в маршрутизации на КПК.

Если есть возможность, прикрутите к pptpd FreeRADIUS и
поэкспериментируйте с аттрибутом:
Framed-Route (использование см. в rfc2865.txt в поставке FreeRADIUS) -
можно передавать клиенту маршрут(ы ?).
Также могут быть полезны Framed-IP-Address и Framed-IP-Netmask.

-- 
С уважением,
 Dank

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[ABATAPA]

2 июня 2006 17:08, Dank Bagryantsev написал:
> Правильного, да не было. Но был костыль: сделать два pptpd-сервера с
> разными параметрами шифрования на разных IP.
Ну, это мне и самому очевидно. 
Но это не то, чего хочется, т.к. разные сети + шифрование/без... Не много ли!?

> >> а точно у Вас оборудование не работает с require-mppe-40 ?
Пробовал. Не получилось. PocketPC 2003.
> Может не поддерживает строгое шифрование (require-mppe-128), а обычное
> (require-mppe-40) поддерживает?
См. выше.
> Какое шифрование пароля применяете/доступно?
Все. Ибо (читайте ранее) без MPPE (с теми же паролями) все работает.

> А OpenVPN Вам не подойдет? Там кстати, очень просто можно на клиентов
> "проталкивать" маршруты...
OpenVPN на PocketPC?
Не знаю.. К тому же, FreeNibs...
> После подключения клиент имеет уже еще и IP 10.0.0.2/255.255.255.0 и
> соответственно у него должна автоматически возникнуть в
> таблице/подсистеме маршрутизации запись, что сеть 10.0.0.0/24 доступна
> через туннель.
Почему?!
Вы же сами писАли:
>"на eth1 172.16.2.1/255.255.255.0 и клиенты 172.16.1.0/24 в одном случае 
>указывают VPN-сервер  172.16.1.1, в другом 172.16.2.0/24 - 172.16.2.1" 
Как будет доступен 10.0.0.1, если из сети 172.16.x.x маршрутизации нет?!
Через VPN? Но это невозможно.

> Я имел ввиду (для случая WinXP клиентов) установленную опцию
> "Использовать основной шлюз в удаленной сети"
> в свойствах VPN-соедиенния, т.е. маршрут по умолчанию через
> VPN-туннель.
Вы путаете что-то. Причем тут это? Говорится о том, что переданный PPtP 
сервером адрес своей стороны, например, 10.0.0.1, _доступен не будет_.
А именно туда станут отправляться GRE-пакеты.

> И кстати, опять таки для WinXP-клиентов, после подключения
> VPN-соединения, default route переопределяется, т.е. связь не рвется.
Связь рвется, когда сервер не доступен по указанному адресу. Из-за чего он 
может быть недоступен - см. выше.
> IMHO, меняются метрики/приоритеты маршрутов по умолчанию.
> IMHO, такой же подход (разные метрики маршрутов по умолчанию) можно
> применять и в linux.
"Такой же" подход применять нет необходимости, достаточно добавить маршрут на 
VPN-сервер отдельной строкой. И это многократно (в том числе - мной) 
говорилось.

> >> Или чего Вы хотите добиться вообще?


> У меня pptpd смотрит в несколько интерфейсов/изолированных сетей, на
> VPN-сервере в pptpd.conf в localip один IP, в options.pptpd
> require-mppe-40. Через радиус, клиентам (WinXP) выдаются IP в другой сети,
> чем localip. На клиентах в опциях VPN-соедиенения стоит
> "Использовать основной шлюз в удаленной сети". Все работает.
> Чем такая маршрутизация Вас не устраивает? (если отбросить вопрос с
> шифрованием)
У вас выдаются адреса, с которых localip доступен и так. Я прав?
Т.е. у вас есть localip (скажем, 172.16.0.1), этот же адрес указан у клиетов 
как адрес VPN-сервера, клиентам выдается, скажем, 172.16.1.xx/24, сервер 
172.16.0.1 доступен от них через маршрутизатор 172.16.1.1. Так?
Это есть у всех, и так и работает. В том числе и у меня.
Но я хочу в роутере, "смотрящем" в _уже имеющиеся_ сети  с _уже имеющейся_  
адресацией (без возможности сменить что-либо) и без маршрутизации поднять 
общий VPN сервер.
Попробуйте в приведенном выше примере закрыть доступ к 172.16.0.1, или 
отключить маршрутизацию. И что? Все.

>
> Уточните, у Вас IP интерфейса КПК и IP интерфейса VPN-сервера в одной
> сети? И IP интерфейса VPN-сервера доступен без записи default route в
> таблице маршрутизации на КПК?
Если бы все было так просто - я бы не мучился, правда?
Еще раз "уточню" - сервер смотрит в несколько различных сетей.
Скажем, у него  на одной сетевой 172.16.0.1, на другой - 172.16.30.xx 
(динамический), на третьей - 192.168.0.1, на четвертой - 81.xx.yy.zz , и т.д.
КПК, скажем, через WiFi может получить адрес только по DHCP из блока 
172.16.30.xx, и он видит ТОЛЬКО свою сеть. Да, он (разумеется!) видит адреса 
172.16.30.xx, и может начать PPtP-сессию с сервером, но у того только ОДИН 
параметр localip (можно перечислить насколько, но он выдает их как адреса из 
пула - вне связи с интерфейсом, _по одному на каждого клиента_ - так сказано 
в доке), и получив этот IP при установлении протакола, клиенты отправляют 
пакеты  на него, но они не доходят более до сервера (да и не должны!). Но 
стОит только поменять localip на 172.16.30.xx (т.е. выдавать доступный 
адрес), как все работает (без шифрования), но...
Сетей-то много, сразу проблемы возникают у других.

Теперь понятно?

> IMHO, проблема не в localip на VPN-сервере, а в маршрутизации на КПК.
Да? А по-моему, в другом. Так же себя будут вести и Windows-клиенты, и Linux.
Адрес туннеля-то передается сервером!
> Если есть возможность, прикрутите к pptpd FreeRADIUS и
> поэкспериментируйте с аттрибутом:
> Framed-Route (использование см. в rfc2865.txt в поставке FreeRADIUS) -
> можно передавать клиенту маршрут(ы ?).
Там уже все "прикручино". И что мне это даст? Причем тут выставленный ПОСЛЕ 
поднятия VPN маршрут куда-либо, если localip в той сети не будет доступен, 
какой бы маршрут не выставлялся (я не могу менять параметры той сети, 
настройки firewall, маршрутизацию, и т.д.)? 

> Также могут быть полезны Framed-IP-Address и Framed-IP-Netmask.
ЧЕМ!?
Извините, но Вы чего-то не понимаете.
VPN (в частности, PPtP) - это туннель (в нашем случае - GRE) + управляющей 
tcp-соединение, которые работают ПО ИМЕЮЩИМУСЯ IP. Чем мне помогут эти 
параметры (к тому же, ip можно менять и без Radius)?! Они позволяют назначить 
IP для УСТАНАВЛИВАЕМОГО соединения, а не изменить параметры имеющейся сети!
Вот смотрите:
1. Изолированная сеть.
2. Клиент 10.0.0.10 в настройках VPN-подключения имеет адрес сервера 10.0.0.1 
и тип - pptp.
3. Он открывает tcp-соединение на порт 1723 (pptp) сервера 10.0.0.1.
4. Сервер егр авторизует, и выдает ему IP, маску, gateway etc,  для нового 
подключения, а так же - _адрес своей стороны_ туннеля (фактически, это 
параметр для pppd). И пусть это адрес он быдал из другой сети - 192.168.0.1 
(прописан в localip, т.к. сервер смотрит и в ту сеть, и там все работает). 
5. В сети нет маршрутизации (или все закрыто файрволом), и посланные 
GRE-пакеты (src - 10.0.0.10, dst - 192.168.0.1) _не находят_ получателя.
6. Через некоторое время (короткое) клиент (или сервер) рвут соединение, при 
этом, они в управляющем соединении вполне могут уведомить другую сторону об 
этом - соединение-то установлено между 10.0.0.1 и 10.0.0.10, и оно 
по-прежнему работает.

Вот ЧЕМ бы мне помогла возможность указать на VPN-интерфейсе клиента другой 
адрес!? Помочь может смена значения адреса сервера, которое отдается клиенту.
Есть еще новая опция компиляции pptpd "--with-pppd-ip-alloc", но про нее в 
документации говорится лишь:
"if using pppd-ip-alloc, manager runs more efficiently - made pptpctrl able to 
have a none, one or both of local/remote addresses   rather than only both or 
none - great code simplicication - re-did IP parser"
Но с ней не все ясно. 8(
-- 
ABATAPA

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Dank Bagryantsev]

Здравствуйте, ABATAPA.

Вы писали пятница 2 июня 2006 г., 17:13:09:

A> 2 июня 2006 17:08, Dank Bagryantsev написал:
>> Правильного, да не было. Но был костыль: сделать два pptpd-сервера с
>> разными параметрами шифрования на разных IP.
A> Ну, это мне и самому очевидно. 
A> Но это не то, чего хочется, т.к. разные сети + шифрование/без... Не много ли!?

>> >> а точно у Вас оборудование не работает с require-mppe-40 ?
A> Пробовал. Не получилось. PocketPC 2003.
>> Может не поддерживает строгое шифрование (require-mppe-128), а обычное
>> (require-mppe-40) поддерживает?
A> См. выше.
>> Какое шифрование пароля применяете/доступно?
A> Все. Ибо (читайте ранее) без MPPE (с теми же паролями) все работает.

"Все" - это pap, chap, mschap, mschap-v2 ?
если _не_ mschap-v2 MPPE может быть недоступно, проверьте.

>> А OpenVPN Вам не подойдет? Там кстати, очень просто можно на клиентов
>> "проталкивать" маршруты...
A> OpenVPN на PocketPC?
A> Не знаю.. К тому же, FreeNibs...
>> После подключения клиент имеет уже еще и IP 10.0.0.2/255.255.255.0 и
>> соответственно у него должна автоматически возникнуть в
>> таблице/подсистеме маршрутизации запись, что сеть 10.0.0.0/24 доступна
>> через туннель.
A> Почему?!
A> Вы же сами писАли:
>>"на eth1 172.16.2.1/255.255.255.0 и клиенты 172.16.1.0/24 в одном случае 
>>указывают VPN-сервер  172.16.1.1, в другом 172.16.2.0/24 - 172.16.2.1" 
A> Как будет доступен 10.0.0.1, если из сети 172.16.x.x маршрутизации нет?!
A> Через VPN? Но это невозможно.

>> Я имел ввиду (для случая WinXP клиентов) установленную опцию
>> "Использовать основной шлюз в удаленной сети"
>> в свойствах VPN-соедиенния, т.е. маршрут по умолчанию через
>> VPN-туннель.
A> Вы путаете что-то. Причем тут это? Говорится о том, что переданный PPtP
A> сервером адрес своей стороны, например, 10.0.0.1, _доступен не будет_.
A> А именно туда станут отправляться GRE-пакеты.

Неа, неправильно. См. ниже.

>> И кстати, опять таки для WinXP-клиентов, после подключения
>> VPN-соединения, default route переопределяется, т.е. связь не рвется.
A> Связь рвется, когда сервер не доступен по указанному адресу. Из-за чего он
A> может быть недоступен - см. выше.
>> IMHO, меняются метрики/приоритеты маршрутов по умолчанию.
>> IMHO, такой же подход (разные метрики маршрутов по умолчанию) можно
>> применять и в linux.
A> "Такой же" подход применять нет необходимости, достаточно добавить маршрут на
A> VPN-сервер отдельной строкой. И это многократно (в том числе - мной) 
A> говорилось.

>> >> Или чего Вы хотите добиться вообще?


>> У меня pptpd смотрит в несколько интерфейсов/изолированных сетей, на
>> VPN-сервере в pptpd.conf в localip один IP, в options.pptpd
>> require-mppe-40. Через радиус, клиентам (WinXP) выдаются IP в другой сети,
>> чем localip. На клиентах в опциях VPN-соедиенения стоит
>> "Использовать основной шлюз в удаленной сети". Все работает.
>> Чем такая маршрутизация Вас не устраивает? (если отбросить вопрос с
>> шифрованием)
A> У вас выдаются адреса, с которых localip доступен и так. Я прав?

Нет. localip доступен _только_ через VPN-туннель.

A> Т.е. у вас есть localip (скажем, 172.16.0.1), этот же адрес указан у клиетов
A> как адрес VPN-сервера, клиентам выдается, скажем, 172.16.1.xx/24, сервер
A> 172.16.0.1 доступен от них через маршрутизатор 172.16.1.1. Так?
A> Это есть у всех, и так и работает. В том числе и у меня.
A> Но я хочу в роутере, "смотрящем" в _уже имеющиеся_ сети  с _уже имеющейся_
A> адресацией (без возможности сменить что-либо) и без маршрутизации поднять
A> общий VPN сервер.
A> Попробуйте в приведенном выше примере закрыть доступ к 172.16.0.1, или
A> отключить маршрутизацию. И что? Все.

>>
>> Уточните, у Вас IP интерфейса КПК и IP интерфейса VPN-сервера в одной
>> сети? И IP интерфейса VPN-сервера доступен без записи default route в
>> таблице маршрутизации на КПК?
A> Если бы все было так просто - я бы не мучился, правда?
A> Еще раз "уточню" - сервер смотрит в несколько различных сетей.
A> Скажем, у него  на одной сетевой 172.16.0.1, на другой - 172.16.30.xx 
A> (динамический), на третьей - 192.168.0.1, на четвертой - 81.xx.yy.zz , и т.д.
A> КПК, скажем, через WiFi может получить адрес только по DHCP из блока 
A> 172.16.30.xx, и он видит ТОЛЬКО свою сеть. Да, он (разумеется!) видит адреса
A> 172.16.30.xx, и может начать PPtP-сессию с сервером, но у того только ОДИН
A> параметр localip (можно перечислить насколько, но он выдает их как адреса из
A> пула - вне связи с интерфейсом, _по одному на каждого клиента_ - так сказано
A> в доке), и получив этот IP при установлении протакола, клиенты отправляют
A> пакеты  на него, но они не доходят более до сервера (да и не должны!). Но
A> стОит только поменять localip на 172.16.30.xx (т.е. выдавать доступный
A> адрес), как все работает (без шифрования), но...
A> Сетей-то много, сразу проблемы возникают у других.

A> Теперь понятно?

интерфейс сервера с 172.16.30.xx сделайте статичным (IMHO, лучше будет)
КПК обращается к этому интерфейсу как к VPN-серверу?
маска 255.255.255.0 ?

>> IMHO, проблема не в localip на VPN-сервере, а в маршрутизации на КПК.
A> Да? А по-моему, в другом. Так же себя будут вести и Windows-клиенты, и Linux.
A> Адрес туннеля-то передается сервером!
>> Если есть возможность, прикрутите к pptpd FreeRADIUS и
>> поэкспериментируйте с аттрибутом:
>> Framed-Route (использование см. в rfc2865.txt в поставке FreeRADIUS) -
>> можно передавать клиенту маршрут(ы ?).
A> Там уже все "прикручино". И что мне это даст? Причем тут выставленный ПОСЛЕ
A> поднятия VPN маршрут куда-либо, если localip в той сети не будет доступен,
A> какой бы маршрут не выставлялся (я не могу менять параметры той сети, 
A> настройки firewall, маршрутизацию, и т.д.)? 

>> Также могут быть полезны Framed-IP-Address и Framed-IP-Netmask.
A> ЧЕМ!?

Например, "играя" Framed-IP-Netmask можно регулировать "видимость"
подсетей.

A> Извините, но Вы чего-то не понимаете.

См. ниже.

A> VPN (в частности, PPtP) - это туннель (в нашем случае - GRE) + управляющей
A> tcp-соединение, которые работают ПО ИМЕЮЩИМУСЯ IP. Чем мне помогут эти
A> параметры (к тому же, ip можно менять и без Radius)?! Они позволяют назначить
A> IP для УСТАНАВЛИВАЕМОГО соединения, а не изменить параметры имеющейся сети!
A> Вот смотрите:
A> 1. Изолированная сеть.
A> 2. Клиент 10.0.0.10 в настройках VPN-подключения имеет адрес сервера 10.0.0.1
A> и тип - pptp.
A> 3. Он открывает tcp-соединение на порт 1723 (pptp) сервера 10.0.0.1.
A> 4. Сервер егр авторизует, и выдает ему IP, маску, gateway etc,  для нового
A> подключения, а так же - _адрес своей стороны_ туннеля (фактически, это
A> параметр для pppd). И пусть это адрес он быдал из другой сети - 192.168.0.1
A> (прописан в localip, т.к. сервер смотрит и в ту сеть, и там все работает).
A> 5. В сети нет маршрутизации (или все закрыто файрволом), и посланные 
A> GRE-пакеты (src - 10.0.0.10, dst - 192.168.0.1) _не находят_ получателя.

ВОТ ОНО!!! :)
GRE-пакеты _должны_ продолжать ходить между
10.0.0.10 <-> 10.0.0.1 (src - 10.0.0.10, dst - 10.0.0.1 и обратно)
IMHO, GRE является транспортом туннеля, т.е. VPN работает поверх
GRE-пакетов (если я правильно помню).
Если не верите, проверьте tcpdump'ом как работает рабочий туннель.

A> 6. Через некоторое время (короткое) клиент (или сервер) рвут соединение, при
A> этом, они в управляющем соединении вполне могут уведомить другую сторону об
A> этом - соединение-то установлено между 10.0.0.1 и 10.0.0.10, и оно 
A> по-прежнему работает.

Совершенно верно. Классический признак неверной маршрутизации (IMHO,
90% в этом проблема). Вам нужно выяснить, почему GRE-пакеты клиент
пытается передать "внутри" туннеля, когда должен "снаружи".
Сниффер в выяснении подобных проблем первейший инструмент :)

A> Вот ЧЕМ бы мне помогла возможность указать на VPN-интерфейсе клиента другой
A> адрес!? Помочь может смена значения адреса сервера, которое отдается клиенту.
A> Есть еще новая опция компиляции pptpd "--with-pppd-ip-alloc", но про нее в
A> документации говорится лишь:
A> "if using pppd-ip-alloc, manager runs more efficiently - made pptpctrl able to
A> have a none, one or both of local/remote addresses   rather than only both or
A> none - great code simplicication - re-did IP parser"
A> Но с ней не все ясно. 8(

-- 
С уважением,
 Dank

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[ABATAPA]

2 июня 2006 19:34, Dank Bagryantsev написал:
> "Все" - это pap, chap, mschap, mschap-v2 ?
> если _не_ mschap-v2 MPPE может быть недоступно, проверьте.
Вы читаете мои сообщения? Там же написано, что на этом сервере работает немало 
других пользователей, более того, с отключенным MPPE (без require-mppe) 
работает и PocketPC.

> Нет. localip доступен _только_ через VPN-туннель.
Бред. Как он может быть доступен _через туннель_, если GRE-пакетам нужен 
транспорт, чтобы попасть от клиента к серверу!?

> интерфейс сервера с 172.16.30.xx сделайте статичным (IMHO, лучше будет)
Читайте же внимательнее!
"в _уже имеющиеся_ сети  с _уже имеющейся_ адресацией (без возможности сменить 
что-либо)"

> КПК обращается к этому интерфейсу как к VPN-серверу?
> маска 255.255.255.0 ?
Там же все расписано. Да, обращается.
Маска - та, что выдается по DHCP.


> Например, "играя" Framed-IP-Netmask можно регулировать "видимость"
> подсетей.
Какая "видимость" здесь!? 
Вам же многократно сказано, что сети _изолированы_, и - не мной!
Нет там роутинга! Какая там может быть "видимость"?!

> ВОТ ОНО!!! :)
> GRE-пакеты _должны_ продолжать ходить между
> 10.0.0.10 <-> 10.0.0.1 (src - 10.0.0.10, dst - 10.0.0.1 и обратно)
Да вы что!? Что Вы говорите! А я-то, серый... Высшее телекоммуникационное 
образование в Бонче, 7 лет в ISP на ведущих ролях... Для чего я, по-Вашему, 
все это расписывал?!
Неужели не видно из написанного мною, что я знаю - в чем проблема, и как 
ДОЛЖНО быть, и как - есть?! Вопрос изначально был: "как заставить pptpd 
выдавать localip, равный IP, на который получен запрос".  
Так уж устроен протокол, что адрес туннеля передает сервер, а pptpd передает 
для pppd то, что прописано. Возможно, "--with-pppd-ip-alloc" поможет 
разрешить эту проблему, но... Посмотрим.

> IMHO, GRE является транспортом туннеля, т.е. VPN работает поверх
> GRE-пакетов (если я правильно помню).
Что нового Вы мне открыли? 
И не "работает поверх GRE-пакетов", а использует GRE-туннелирование.

> Если не верите, проверьте tcpdump'ом как работает рабочий туннель.
Мда...
Что Вы мне предлагаете смотреть?! Как работает PPtP?!
Или убедиться в том, что после получения неверного localip пакеты на сервер не 
доходят? Так, знаете ли, я давно уже все посмотрел...

> Совершенно верно. Классический признак неверной маршрутизации (IMHO,
> 90% в этом проблема). 
Ничего-то Вы не поняли... Где Вы какие "признаки" увидели...

> Вам нужно выяснить, почему GRE-пакеты клиент 
> пытается передать "внутри" туннеля, когда должен "снаружи".
Где вы это увидели?! ГДЕ!?
Покажите мне, где это написано!
Клиент пытается передать пакеты на  адрес сервера, переданный ему в 
управляющем соединении. А как уж пакет пойдет - от маршрутов зависит.
Но в данном случае он просто не дайдет - НЕТ из этой сети доступа "наружу".

> Сниффер в выяснении подобных проблем первейший инструмент :)
Что Вы говорите!
Знаете, инструментария у меня и помимо "снифера" хватает.


Знаете, давайте на этом и закончим.
Я вижу полное непонимание Вами как сути проблемы, так и моих изначальных 
вопросов, и вижу весьма поверхностные знания того, как же _это_ все работает.
А заниматься пустой болтавней тут - не место.
Может быть, кто-то другой поможет мне _именно_ с pptpd, в частности, просвятит 
о сути правок "--with-pppd-ip-alloc" (которые заставляют pppd не передавать 
адреса как параметр pppd, предоставляя последнему выбирать IP для одной - или 
обеих - сторон самостоятельно).
-- 
ABATAPA

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Dank Bagryantsev]

Здравствуйте, ABATAPA.

Вы писали пятница 2 июня 2006 г., 19:33:12:

>> Нет. localip доступен _только_ через VPN-туннель.
A> Бред. Как он может быть доступен _через туннель_, если GRE-пакетам нужен
A> транспорт, чтобы попасть от клиента к серверу!?

Кому "Бред", а у кого и несколько лет _стабильно_ работает.
Не знаю как у Вас, а у меня GRE-пакеты ходят между IP интерфесов
сетевых карт клиентов и сервера. И ни в src, ни в dst GRE-пакетов нет
localip pptpd сервера.

>> интерфейс сервера с 172.16.30.xx сделайте статичным (IMHO, лучше будет)
A> Читайте же внимательнее!
A> "в _уже имеющиеся_ сети  с _уже имеющейся_ адресацией (без возможности сменить
A> что-либо)"

Да откуда ж я знаю, где у Вас еще может быть проблема?
Может еще у вас default route через DHCP раздается и это играет свою
роль, вот и посоветовал статику попробовать.

>> ВОТ ОНО!!! :)
>> GRE-пакеты _должны_ продолжать ходить между
>> 10.0.0.10 <-> 10.0.0.1 (src - 10.0.0.10, dst - 10.0.0.1 и обратно)
A> Да вы что!? Что Вы говорите! А я-то, серый... Высшее телекоммуникационное
A> образование в Бонче, 7 лет в ISP на ведущих ролях... Для чего я, по-Вашему,
A> все это расписывал?!
A> Неужели не видно из написанного мною, что я знаю - в чем проблема, и как
A> ДОЛЖНО быть, и как - есть?!

Я вижу, "из написанного Вами", что Вы не понимаете почему у Вас не
работает. И, когда я Вам привожу рабочие примеры, Вы начинаете мне
доказывать, что это не работает.
Если Вы такой "профессионал", может Вы объясните мне, простому
сисадмину, почему у меня работает, а у Вас нет? А условия у нас похожи на
80-90%, только у меня не используется DHCP, но обязательно шифрование
для VPN, используются VLAN'ы, и есть OSPF для реальных IP.

>> IMHO, GRE является транспортом туннеля, т.е. VPN работает поверх
>> GRE-пакетов (если я правильно помню).
A> Что нового Вы мне открыли? 
A> И не "работает поверх GRE-пакетов", а использует GRE-туннелирование.
От того, что я по другому сказал _суть_ поменялась?

>> Если не верите, проверьте tcpdump'ом как работает рабочий туннель.
A> Мда...
A> Что Вы мне предлагаете смотреть?! Как работает PPtP?!

Да. Освежите память. Сделайте лабораторную.
Возьмите два компьютера один с WinXP (1), другой с ALM-2.4 с pptpd (2)
(2):
pptpd.conf :
localip 10.0.0.1
remoteip 10.0.0.2-254

eth0 172.16.1.1/255.255.255.0

(1):
IP сетевой карты: 172.16.1.2/255.255.255.0
свойства VPN-соединения:
VPN сервер: 172.16.1.1
"Использовать основной шлюз в удаленной сети" - Вкл

Остальные параметры детализировать или не надо?

Подключаете VPN. Подключилось? Свойства установленного соединения?
Server IP - 10.0.0.1
Client IP - 10.0.0.2

на (2): tcpdump -i eth0
на (1): ping 10.0.0.1

смотрим на (2), что видите? какие пакеты? какие src и dst у них?

на (2): tcpdump -i ppp0
   какие пакеты? какие src и dst у них?

Все понятно?
Добавьте несколько сетевых карт на (2) подсоедините к ним по
компьютеру с WinXP (3-5), сети из диапазона 172.16.x.x/24
VPN сервера: 172.16.x.1
подключайтесь с (3-5)
проделайте вышеизложенную процедуру для всех
какие были пакеты? какие src и dst у них?

Все понятно?
(Прежде чем возмущаться, действительно все это сделайте. Все равно Вам
желательно тестовый стенд сделать.)

Дальше экспериментируйте уже со своим КПК.

A> Или убедиться в том, что после получения неверного localip пакеты на сервер не
A> доходят? Так, знаете ли, я давно уже все посмотрел...

Значит не там смотрели.

>> Вам нужно выяснить, почему GRE-пакеты клиент 
>> пытается передать "внутри" туннеля, когда должен "снаружи".
A> Где вы это увидели?! ГДЕ!?
A> Покажите мне, где это написано!

Четче выражаете свои мысли. А то непонятно, то ли Вы спрашиваете о
том, как происходит "GRE-туннелирование", то ли о том, на основании
чего я сделал такой вывод.
Если о моем выводе, то вот, пожалуйста:
A> 2. Клиент 10.0.0.10 в настройках VPN-подключения имеет адрес сервера 10.0.0.1
A> и тип - pptp.
A> 3. Он открывает tcp-соединение на порт 1723 (pptp) сервера 10.0.0.1.
A> 4. Сервер егр авторизует, и выдает ему IP, маску, gateway etc,  для нового 
A> подключения, а так же - _адрес своей стороны_ туннеля (фактически, это 
A> параметр для pppd). И пусть это адрес он быдал из другой сети - 192.168.0.1 
A> (прописан в localip, т.к. сервер смотрит и в ту сеть, и там все работает). 
A> 5. В сети нет маршрутизации (или все закрыто файрволом), и посланные 
A> GRE-пакеты (src - 10.0.0.10, dst - 192.168.0.1) _не находят_ получателя.

dst в этом случае должен оставаться 10.0.0.1, в таком случае будет
работать. Разжевывать почему, я Вам не буду, Вы же "профессионал",
должны знать.

A> Клиент пытается передать пакеты на  адрес сервера, переданный ему в 
A> управляющем соединении. А как уж пакет пойдет - от маршрутов зависит.
A> Но в данном случае он просто не дайдет - НЕТ из этой сети доступа "наружу".

>> Сниффер в выяснении подобных проблем первейший инструмент :)
A> Что Вы говорите!
A> Знаете, инструментария у меня и помимо "снифера" хватает.

Значит не умете пользоваться.

A> Знаете, давайте на этом и закончим.
A> Я вижу полное непонимание Вами как сути проблемы, так и моих изначальных
A> вопросов, и вижу весьма поверхностные знания того, как же _это_ все работает.

Похоже это Вы не хотите понять как нужно настроить, чтобы у Вас
заработало.

A> А заниматься пустой болтавней тут - не место.

Да. Давайте закончим эту бесполезную дискуссию.
Если человек долбается об стену головой, игнорируя совет обойти стену
через соседнюю дверь - это его выбор.

P.S. И поменьше эмоций, этому здесь не место.

-- 
 Dank

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On Вск, 2006-05-28 at 17:23 +0400, ABATAPA wrote: 
> Скажите, пожалуйста, у кого-нибудь работает _опциональное_ 
> шифрование MPPE в pptp? 

ДА. И я вам про это уже писал!

Кроме того. Советую вам не побрезговать, и поискать по списку рассылки
poptop-server (Subject: optional encryption письмо от 23 декабря).

Peter.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[ABATAPA]

3 июня 2006 10:06, Peter Volkov написал:
> Кроме того. Советую вам не побрезговать, и поискать по списку рассылки
> poptop-server (Subject: optional encryption письмо от 23 декабря).
Где именно?
http://lists.altlinux.org/pipermail/sysadmins/2005-December/subject.html
-- 
ABATAPA

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

On Вск, 2006-06-04 at 19:24 +0400, ABATAPA wrote:
> 3 июня 2006 10:06, Peter Volkov написал:
> > Кроме того. Советую вам не побрезговать, и поискать по списку рассылки
> > poptop-server (Subject: optional encryption письмо от 23 декабря).
> Где именно?
> http://lists.altlinux.org/pipermail/sysadmins/2005-December/subject.html

Я говорил про список рассылки poptop-server. Вот сообщение, которое я
имел ввиду:
http://sourceforge.net/mailarchive/message.php?msg_id=14275938

Peter.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[ABATAPA]

4 июня 2006 19:50, Peter Volkov написал:
> Я говорил про список рассылки poptop-server. Вот сообщение, которое я
> имел ввиду:
> http://sourceforge.net/mailarchive/message.php?msg_id=14275938
Посмотрел. Ничего бОльшего, чем, скажем, man pppd, это мне не дало.
Или собирать _иной_ pppd для себя (и постоянно смотреть, как при обновлении 
все ломается), или... Или запускать их два. Или, учитывая проблему с IP, _по 
два_...
-- 
ABATAPA

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]

On Вск, 2006-05-28 at 17:23 +0400, ABATAPA wrote:
> Скажите, пожалуйста, у кого-нибудь работает _опциональное_ 
> шифрование MPPE в pptp? Как мне тогда сделать возможным 
> подключение клиентов, не использующих шифрование, наравне с
> использующими? 

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

Итак. Это работает только с mppe-mppc патчами от Jan Dubiec'а [1]. Нужно
ими  пропатчить ядро и pppd после этого в конфиге убрать всё связанное с
mppe и тогда всё заработает так, как вы хотите.

Однако есть одна заковырка. Ядра версии 2.6.15 и выше уже включают в
себя поддержку mppe [2]. Поэтому перед тем как накладывать патчи
mppe-mppc нужно выдрать "встроенную" поддержку mppe из ядра с помощью
(patch -R). После этого можно накладывать mppe-mppc патчи. На упоминание
этой возни с патчами я нактнулся на gentoo-wiki [3] но автор тамошней
доки походу сам это не делал, а ссылается... В общем можно погуглить и
вы найдёте упоминания об этом.

От себя могу добавить, что вчера сделал это на ядре 2.6.17-gentoo-r7.
mppe патч отлично выдрался (за исключением одного rejectа, но он должен
был выдрать то чего уже и так нет в ядре.) потом патч mppe-mppc лёг
почти как влитой, скомпилировал... и всё заработало!!! Чего и вам
желаю. :)


Ссылочки по теме:
[1]http://mppe-mppc.alphacron.de/
[2]http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14/2.6.14-mm1/broken-out/ppp_mppe-add-ppp-mppe-encryption-module.patch
[3]http://gentoo-wiki.com/HOWTO_PPTP_VPN_client_%28Microsoft-compatible_with_mppe%29

Peter.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[ABATAPA]

1 сентября 2006 22:24, Peter Volkov написал:
> Итак. Это работает только с mppe-mppc патчами от Jan Dubiec'а [1]. 
Да, спасибо, это я знаю. Но - я работаю с Сизифом, так что хотелось бы как-то 
тут... А тут ни этого, ни mppc...
>  и всё заработало!!! Чего и вам желаю. :)
Спасибо, но этот путь, скорее всего, не для меня... Перебирать каждый раз 
ядра... Нарушать связи... 
-- 
ABATAPA

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Ildar Mulyukov]

On 02.09.2006 00:35:03, ABATAPA wrote:
> 1 сентября 2006 22:24, Peter Volkov написал:
> > Итак. Это работает только с mppe-mppc патчами от Jan Dubiec'а [1].
> Да, спасибо, это я знаю. Но - я работаю с Сизифом, так что хотелось бы
> как-то
> тут... А тут ни этого, ни mppc...
> >  и всё заработало!!! Чего и вам желаю. :)
> Спасибо, но этот путь, скорее всего, не для меня... Перебирать каждый
> раз
> ядра... Нарушать связи...
Да, действительно. Но, думаю, в наших силах взять - проголосовать  
(прямо здесь) и попросить ядерную команду сделать это для последующих  
ядер. Если, конечно, там с интеллектуальной собственностью всё чисто...

Ильдар
--
Ildar  Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[ABATAPA]

2 сентября 2006 10:54, Ildar Mulyukov написал:
> Да, действительно. Но, думаю, в наших силах взять - проголосовать  
> (прямо здесь) и попросить ядерную команду сделать это для последующих  
> ядер. Если, конечно, там с интеллектуальной собственностью всё чисто...
На всех же не угодить. 
Вот у меня под ядрами из Сизифа живет Quagga с двумя full views, в системе - 
до 200000 записей маршрутов. Я хотел бы "серверные" ядра с BIG ROUTE TABLE...
Тот же _обциональный_ MPPE + MPPC хочу. И так далее...
-- 
ABATAPA

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

On Вск, 2006-09-03 at 17:20 +0400, ABATAPA wrote:
> 2 сентября 2006 10:54, Ildar Mulyukov написал:
> > Да, действительно. Но, думаю, в наших силах взять - проголосовать  
> > (прямо здесь) и попросить ядерную команду сделать это для последующих  
> > ядер. Если, конечно, там с интеллектуальной собственностью всё чисто...
> На всех же не угодить. 
> Вот у меня под ядрами из Сизифа живет Quagga с двумя full views, в системе - 
> до 200000 записей маршрутов. Я хотел бы "серверные" ядра с BIG ROUTE TABLE...
> Тот же _обциональный_ MPPE + MPPC хочу. И так далее...

Именно поэтому самосборное ядро бывает лучше. :P

Peter.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Ildar Mulyukov]

On 03.09.2006 20:17:01, Peter Volkov wrote:
> On Вск, 2006-09-03 at 17:20 +0400, ABATAPA wrote:
> > 2 сентября 2006 10:54, Ildar Mulyukov написал:
> > > Да, действительно. Но, думаю, в наших силах взять - проголосовать
> 
> > > (прямо здесь) и попросить ядерную команду сделать это для
> последующих
> > > ядер. Если, конечно, там с интеллектуальной собственностью всё
> чисто...
> > На всех же не угодить.
> > Вот у меня под ядрами из Сизифа живет Quagga с двумя full views, в
> системе -
> > до 200000 записей маршрутов. Я хотел бы "серверные" ядра с BIG ROUTE
> TABLE...
> > Тот же _обциональный_ MPPE + MPPC хочу. И так далее...
> 
> Именно поэтому самосборное ядро бывает лучше. :P
НО, что касается функциональности, которая _уже_ присутствует в ядре,  
если её можно "бесплатно" улучшить, то почему бы этого не сделать? Это  
ведь просто модуль, который не грузится у тех, кому это не нужно.

Ильдар
--
Ildar  Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Konstantin A. Lepikhov]

Hi Peter!

Friday 01, at 10:24:08 PM you wrote:

<skip>
> Однако есть одна заковырка. Ядра версии 2.6.15 и выше уже включают в
> себя поддержку mppe [2]. Поэтому перед тем как накладывать патчи
> mppe-mppc нужно выдрать "встроенную" поддержку mppe из ядра с помощью
> (patch -R). После этого можно накладывать mppe-mppc патчи. На упоминание
> этой возни с патчами я нактнулся на gentoo-wiki [3] но автор тамошней
> доки походу сам это не делал, а ссылается... В общем можно погуглить и
> вы найдёте упоминания об этом.
К сожалению, каждое дело можно сделать правильно, а можно через
<sensored/>. Предложенный вами путь может быть и обычен в gentoo, но в
остальном мире как-то не приживается ;) Так что за изыскания спасибо, а
вот с остальным надо сделать по-другому - найти что же не устраивает в
ядре и сделать -feat из патча.

-- 
WBR et al.

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

On 2006-09-03 at 22:21 +0400, Konstantin A. Lepikhov wrote:
> Так что за изыскания спасибо, а вот с остальным надо сделать
> по-другому - найти что же не устраивает в ядре и сделать -feat из
> патча.

Сорри за незнание, но что такое -feat?

Peter.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Konstantin A. Lepikhov]

Hi Peter!

Sunday 03, at 10:45:31 PM you wrote:

> On 2006-09-03 at 22:21 +0400, Konstantin A. Lepikhov wrote:
> > Так что за изыскания спасибо, а вот с остальным надо сделать
> > по-другому - найти что же не устраивает в ядре и сделать -feat из
> > патча.
> 
> Сорри за незнание, но что такое -feat?
> 
> Peter.
цитата из kernel-policy.txt:

1.1 Патчи.
----------

Есть два вида патчей:

kernel-feat-%{upstream_name}
kernel-fix-%{upstream_name}

Название пакетов с патчами базируется на иерархии каталогов в исходных
текстах ядра, в соответствии с местом основного приложения патча.

В пакетах feat содержатся патчи, добавляющие ядру Linux новые
возможности. Это могут быть и драйверы устройств (рекомендуется
называть такие kernel-feat-drivers-<имя_устройства>), и файловых
систем (желательно называть kernel-feat-fs-<имя_файловой
системы>), добавление новых возможностей к сетевой подсистеме
(желательно называть kernel-feat-net-<сокращённое название
улучшения>), а также добавление новых возможностей к корневой части
(kernel/*, mm/*, arch/*) ядра, (желательно называть
kernel-feat-core-<название улучшения>). При именовании патчей
рекомендуется следовать иерархии каталогов в исходных текстах ядра.

Все пакеты fix поддерживаются kernel maintainer commitee. Именуются по
именам подсистем ядра, а также существует отдельный пакет для security
патчей и build патчей:
kernel-fix-{net,drivers,fs,vm,core,security,build}.

Глубина иерархии в названии пакета может варьироваться, некоторые
уровни - пропускаться, чтобы сделать название короче, например,
kernel-net-netfilter вместо kernel-net-ipv4-netfilter и
kernel-net-ipv6-netfilter.

PS Сорри за флуд тем, кто это уже знает.

-- 
WBR et al.

Re: [Sysadmins] PPtP: разные localip, опционально MPPE

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

Здравствуйте Peter Volkov
  В сообщении от 3 сентября 2006 22:45 Peter Volkov написал(a):
 > On 2006-09-03 at 22:21 +0400, Konstantin A. Lepikhov wrote:
 > > Так что за изыскания спасибо, а вот с остальным надо сделать
 > >
 > > по-другому - найти что же не устраивает в ядре и сделать -feat из
 > >
 > > патча.
 >
 > Сорри за незнание, но что такое -feat?
 >
 >
 >
 > Peter.
http://lists.altlinux.org/pipermail/devel-kernel/2004-August/004430.html
https://faq.altlinux.ru/index.php?action=single&qid=463&aid=464
-- 
  А ещё говорят так  (fortune):
 
В потоках целей все в движение уходит...
Не остановится и тот, кто цель находит.
Так переменчивы все качества движенья,
И неустойчивы земные достиженья...
		-- Феано
________________________________________________________________________
С уважением Хихин Руслан (hihin@rambler.ru)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]