ALT Linux sysadmins discussion
 help / color / mirror / Atom feed
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



  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