From: Dank Bagryantsev <4alt@mail.ru> To: ALT Linux sysadmin discuss <sysadmins@lists.altlinux.org> Subject: Re: [Sysadmins] PPtP: разные localip, опционально MPPE Date: Fri, 2 Jun 2006 16:08:55 +0300 Message-ID: <673878580.20060602160855@lugaport.net> (raw) In-Reply-To: <200606021116.16534.dnsmaster@yandex.ru> Здравствуйте, 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
next prev parent reply other threads:[~2006-06-02 13:08 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-05-28 13:23 ABATAPA 2006-06-01 14:40 ` ABATAPA 2006-06-01 17:43 ` Dank Bagryantsev 2006-06-02 7:16 ` ABATAPA 2006-06-02 13:08 ` Dank Bagryantsev [this message] 2006-06-02 14:13 ` ABATAPA 2006-06-02 15:34 ` Dank Bagryantsev 2006-06-02 16:33 ` ABATAPA 2006-06-02 20:59 ` Dank Bagryantsev 2006-06-03 6:06 ` Peter Volkov 2006-06-04 15:24 ` ABATAPA 2006-06-04 15:50 ` Peter Volkov 2006-06-04 15:58 ` ABATAPA 2006-09-01 18:24 ` Peter Volkov 2006-09-01 18:35 ` ABATAPA 2006-09-02 6:54 ` Ildar Mulyukov 2006-09-03 13:20 ` ABATAPA 2006-09-03 14:17 ` Peter Volkov 2006-09-04 4:38 ` Ildar Mulyukov 2006-09-03 18:21 ` Konstantin A. Lepikhov 2006-09-03 18:45 ` Peter Volkov 2006-09-03 18:58 ` Konstantin A. Lepikhov 2006-09-03 19:05 ` Хихин Руслан
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=673878580.20060602160855@lugaport.net \ --to=4alt@mail.ru \ --cc=sysadmins@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux sysadmins discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/sysadmins/0 sysadmins/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 sysadmins sysadmins/ http://lore.altlinux.org/sysadmins \ sysadmins@lists.altlinux.org sysadmins@lists.altlinux.ru sysadmins@lists.altlinux.com public-inbox-index sysadmins Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.sysadmins AGPL code for this site: git clone https://public-inbox.org/public-inbox.git