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

Пт Июн 2 18:13:09 MSD 2006

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