From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: ABATAPA To: Dank Bagryantsev <4alt@mail.ru>, ALT Linux sysadmin discuss Date: Fri, 2 Jun 2006 18:13:09 +0400 User-Agent: KMail/1.9.1 References: <200605281723.55650.dnsmaster@yandex.ru> <200606021116.16534.dnsmaster@yandex.ru> <673878580.20060602160855@lugaport.net> In-Reply-To: <673878580.20060602160855@lugaport.net> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200606021813.10097.dnsmaster@yandex.ru> X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Sysadmins] =?koi8-r?b?UFB0UDog0sHaztnFIGxvY2FsaXAsIM/Qw8nPzsHM?= =?koi8-r?b?2M7PIE1QUEU=?= X-BeenThere: sysadmins@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: ALT Linux sysadmin discuss List-Id: ALT Linux sysadmin discuss List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 14:13:21 -0000 Archived-At: List-Archive: 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