From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <4alt@mail.ru> Date: Fri, 2 Jun 2006 16:08:55 +0300 From: Dank Bagryantsev <4alt@mail.ru> X-Priority: 3 (Normal) Message-ID: <673878580.20060602160855@lugaport.net> To: ALT Linux sysadmin discuss In-Reply-To: <200606021116.16534.dnsmaster@yandex.ru> References: <200605281723.55650.dnsmaster@yandex.ru> <812222069.20060601204339@lugaport.net> <200606021116.16534.dnsmaster@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit 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: Dank Bagryantsev <4alt@mail.ru>, 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 13:09:28 -0000 Archived-At: List-Archive: Здравствуйте, 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