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 18:34:00 +0300
Message-ID: <1303323366.20060602183400@lugaport.net> (raw)
In-Reply-To: <200606021813.10097.dnsmaster@yandex.ru>

Здравствуйте, ABATAPA.

Вы писали пятница 2 июня 2006 г., 17:13:09:

A> 2 июня 2006 17:08, Dank Bagryantsev написал:
>> Правильного, да не было. Но был костыль: сделать два pptpd-сервера с
>> разными параметрами шифрования на разных IP.
A> Ну, это мне и самому очевидно. 
A> Но это не то, чего хочется, т.к. разные сети + шифрование/без... Не много ли!?

>> >> а точно у Вас оборудование не работает с require-mppe-40 ?
A> Пробовал. Не получилось. PocketPC 2003.
>> Может не поддерживает строгое шифрование (require-mppe-128), а обычное
>> (require-mppe-40) поддерживает?
A> См. выше.
>> Какое шифрование пароля применяете/доступно?
A> Все. Ибо (читайте ранее) без MPPE (с теми же паролями) все работает.

"Все" - это pap, chap, mschap, mschap-v2 ?
если _не_ mschap-v2 MPPE может быть недоступно, проверьте.

>> А OpenVPN Вам не подойдет? Там кстати, очень просто можно на клиентов
>> "проталкивать" маршруты...
A> OpenVPN на PocketPC?
A> Не знаю.. К тому же, FreeNibs...
>> После подключения клиент имеет уже еще и IP 10.0.0.2/255.255.255.0 и
>> соответственно у него должна автоматически возникнуть в
>> таблице/подсистеме маршрутизации запись, что сеть 10.0.0.0/24 доступна
>> через туннель.
A> Почему?!
A> Вы же сами писАли:
>>"на 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> Как будет доступен 10.0.0.1, если из сети 172.16.x.x маршрутизации нет?!
A> Через VPN? Но это невозможно.

>> Я имел ввиду (для случая WinXP клиентов) установленную опцию
>> "Использовать основной шлюз в удаленной сети"
>> в свойствах VPN-соедиенния, т.е. маршрут по умолчанию через
>> VPN-туннель.
A> Вы путаете что-то. Причем тут это? Говорится о том, что переданный PPtP
A> сервером адрес своей стороны, например, 10.0.0.1, _доступен не будет_.
A> А именно туда станут отправляться GRE-пакеты.

Неа, неправильно. См. ниже.

>> И кстати, опять таки для WinXP-клиентов, после подключения
>> VPN-соединения, default route переопределяется, т.е. связь не рвется.
A> Связь рвется, когда сервер не доступен по указанному адресу. Из-за чего он
A> может быть недоступен - см. выше.
>> IMHO, меняются метрики/приоритеты маршрутов по умолчанию.
>> IMHO, такой же подход (разные метрики маршрутов по умолчанию) можно
>> применять и в linux.
A> "Такой же" подход применять нет необходимости, достаточно добавить маршрут на
A> VPN-сервер отдельной строкой. И это многократно (в том числе - мной) 
A> говорилось.

>> >> Или чего Вы хотите добиться вообще?


>> У меня pptpd смотрит в несколько интерфейсов/изолированных сетей, на
>> VPN-сервере в pptpd.conf в localip один IP, в options.pptpd
>> require-mppe-40. Через радиус, клиентам (WinXP) выдаются IP в другой сети,
>> чем localip. На клиентах в опциях VPN-соедиенения стоит
>> "Использовать основной шлюз в удаленной сети". Все работает.
>> Чем такая маршрутизация Вас не устраивает? (если отбросить вопрос с
>> шифрованием)
A> У вас выдаются адреса, с которых localip доступен и так. Я прав?

Нет. localip доступен _только_ через VPN-туннель.

A> Т.е. у вас есть localip (скажем, 172.16.0.1), этот же адрес указан у клиетов
A> как адрес VPN-сервера, клиентам выдается, скажем, 172.16.1.xx/24, сервер
A> 172.16.0.1 доступен от них через маршрутизатор 172.16.1.1. Так?
A> Это есть у всех, и так и работает. В том числе и у меня.
A> Но я хочу в роутере, "смотрящем" в _уже имеющиеся_ сети  с _уже имеющейся_
A> адресацией (без возможности сменить что-либо) и без маршрутизации поднять
A> общий VPN сервер.
A> Попробуйте в приведенном выше примере закрыть доступ к 172.16.0.1, или
A> отключить маршрутизацию. И что? Все.

>>
>> Уточните, у Вас IP интерфейса КПК и IP интерфейса VPN-сервера в одной
>> сети? И IP интерфейса VPN-сервера доступен без записи default route в
>> таблице маршрутизации на КПК?
A> Если бы все было так просто - я бы не мучился, правда?
A> Еще раз "уточню" - сервер смотрит в несколько различных сетей.
A> Скажем, у него  на одной сетевой 172.16.0.1, на другой - 172.16.30.xx 
A> (динамический), на третьей - 192.168.0.1, на четвертой - 81.xx.yy.zz , и т.д.
A> КПК, скажем, через WiFi может получить адрес только по DHCP из блока 
A> 172.16.30.xx, и он видит ТОЛЬКО свою сеть. Да, он (разумеется!) видит адреса
A> 172.16.30.xx, и может начать PPtP-сессию с сервером, но у того только ОДИН
A> параметр localip (можно перечислить насколько, но он выдает их как адреса из
A> пула - вне связи с интерфейсом, _по одному на каждого клиента_ - так сказано
A> в доке), и получив этот IP при установлении протакола, клиенты отправляют
A> пакеты  на него, но они не доходят более до сервера (да и не должны!). Но
A> стОит только поменять localip на 172.16.30.xx (т.е. выдавать доступный
A> адрес), как все работает (без шифрования), но...
A> Сетей-то много, сразу проблемы возникают у других.

A> Теперь понятно?

интерфейс сервера с 172.16.30.xx сделайте статичным (IMHO, лучше будет)
КПК обращается к этому интерфейсу как к VPN-серверу?
маска 255.255.255.0 ?

>> IMHO, проблема не в localip на VPN-сервере, а в маршрутизации на КПК.
A> Да? А по-моему, в другом. Так же себя будут вести и Windows-клиенты, и Linux.
A> Адрес туннеля-то передается сервером!
>> Если есть возможность, прикрутите к pptpd FreeRADIUS и
>> поэкспериментируйте с аттрибутом:
>> Framed-Route (использование см. в rfc2865.txt в поставке FreeRADIUS) -
>> можно передавать клиенту маршрут(ы ?).
A> Там уже все "прикручино". И что мне это даст? Причем тут выставленный ПОСЛЕ
A> поднятия VPN маршрут куда-либо, если localip в той сети не будет доступен,
A> какой бы маршрут не выставлялся (я не могу менять параметры той сети, 
A> настройки firewall, маршрутизацию, и т.д.)? 

>> Также могут быть полезны Framed-IP-Address и Framed-IP-Netmask.
A> ЧЕМ!?

Например, "играя" Framed-IP-Netmask можно регулировать "видимость"
подсетей.

A> Извините, но Вы чего-то не понимаете.

См. ниже.

A> VPN (в частности, PPtP) - это туннель (в нашем случае - GRE) + управляющей
A> tcp-соединение, которые работают ПО ИМЕЮЩИМУСЯ IP. Чем мне помогут эти
A> параметры (к тому же, ip можно менять и без Radius)?! Они позволяют назначить
A> IP для УСТАНАВЛИВАЕМОГО соединения, а не изменить параметры имеющейся сети!
A> Вот смотрите:
A> 1. Изолированная сеть.
A> 2. Клиент 10.0.0.10 в настройках VPN-подключения имеет адрес сервера 10.0.0.1
A> и тип - pptp.
A> 3. Он открывает tcp-соединение на порт 1723 (pptp) сервера 10.0.0.1.
A> 4. Сервер егр авторизует, и выдает ему IP, маску, gateway etc,  для нового
A> подключения, а так же - _адрес своей стороны_ туннеля (фактически, это
A> параметр для pppd). И пусть это адрес он быдал из другой сети - 192.168.0.1
A> (прописан в localip, т.к. сервер смотрит и в ту сеть, и там все работает).
A> 5. В сети нет маршрутизации (или все закрыто файрволом), и посланные 
A> GRE-пакеты (src - 10.0.0.10, dst - 192.168.0.1) _не находят_ получателя.

ВОТ ОНО!!! :)
GRE-пакеты _должны_ продолжать ходить между
10.0.0.10 <-> 10.0.0.1 (src - 10.0.0.10, dst - 10.0.0.1 и обратно)
IMHO, GRE является транспортом туннеля, т.е. VPN работает поверх
GRE-пакетов (если я правильно помню).
Если не верите, проверьте tcpdump'ом как работает рабочий туннель.

A> 6. Через некоторое время (короткое) клиент (или сервер) рвут соединение, при
A> этом, они в управляющем соединении вполне могут уведомить другую сторону об
A> этом - соединение-то установлено между 10.0.0.1 и 10.0.0.10, и оно 
A> по-прежнему работает.

Совершенно верно. Классический признак неверной маршрутизации (IMHO,
90% в этом проблема). Вам нужно выяснить, почему GRE-пакеты клиент
пытается передать "внутри" туннеля, когда должен "снаружи".
Сниффер в выяснении подобных проблем первейший инструмент :)

A> Вот ЧЕМ бы мне помогла возможность указать на VPN-интерфейсе клиента другой
A> адрес!? Помочь может смена значения адреса сервера, которое отдается клиенту.
A> Есть еще новая опция компиляции pptpd "--with-pppd-ip-alloc", но про нее в
A> документации говорится лишь:
A> "if using pppd-ip-alloc, manager runs more efficiently - made pptpctrl able to
A> have a none, one or both of local/remote addresses   rather than only both or
A> none - great code simplicication - re-did IP parser"
A> Но с ней не все ясно. 8(

-- 
С уважением,
 Dank



  reply	other threads:[~2006-06-02 15:34 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
2006-06-02 14:13       ` ABATAPA
2006-06-02 15:34         ` Dank Bagryantsev [this message]
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=1303323366.20060602183400@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