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

Dank Bagryantsev =?iso-8859-1?q?4alt_=CE=C1_mail=2Eru?=
Пт Июн 2 17:08:55 MSD 2006


Здравствуйте, 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




Подробная информация о списке рассылки Sysadmins