| 1.1, dima (??), 03:34, 15/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а если клиент локально имеет 192,168,0,х адрес ?
ка это в 99% случаев и есть
| | |
| |
| 2.3, Брызгалов (?), 11:42, 15/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Вот в это то как раз случае применение NETMAP позволит обойти проблему пересечения адресных пространств.
Например дома и на предприятии(удаленная сеть) сеть 192.168.0.0/24, используя NETMAP , можем дать доступ к ресурсам удаленной сети по адресам 10.50.11.0/24.
192.168.0.235 становится адресом 10.50.11.235.
В случае с openvpn кстати возникает таже проблема и обходить ее проще всего опять таки используя NETMAP
| | |
| |
| 3.4, анонимаус (?), 12:33, 15/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Например дома и на предприятии(удаленная сеть) сеть 192.168.0.0/24, используя NETMAP , можем дать доступ к ресурсам удаленной сети по адресам 10.50.11.0/24.
Правильно я понял, что поднимать сеть 10.50.11.0/24 в удаленной сети предприятия не обязательно ?
при попытке достучаться до 10.50.11.0/24 в удаленной сети проходить трансляция адресов в реальные адреса 192.168.0.0/24 ?
| | |
| |
| 4.6, Брызгалов (?), 15:15, 15/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
1. Поднимать необязательно - 10.50.11.0/24 это адрес сети параметра localip в конфиге сервиса pptpd
2. да
| | |
|
|
|
| 1.2, Аноним (-), 11:21, 15/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>Необходимо отметить, что есть еще другой путь решения проблемы
для себя нашел другой путь решения - использую не PPTP, а OpenVPN. Минус в установке софта клиенту. Зато выдает в т.ч. и маршруты. Плюс отсутствие заморочек с GRE.
| | |
| |
| 2.12, Брызгалов Константин (ok), 08:15, 16/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>Необходимо отметить, что есть еще другой путь решения проблемы
> для себя нашел другой путь решения - использую не PPTP, а OpenVPN.
> Минус в установке софта клиенту. Зато выдает в т.ч. и маршруты.
> Плюс отсутствие заморочек с GRE.
Согласен с Вами полностью, но в моей ситуации необходим был именно pptp. Так задачу поставили.
Кстати, кончилось тем, что пришлось клиенту все таки использовать openvpn. И как раз из-за заморочек с GRE. Клиент сидел на приватных адресах, с которых pptp не транслировался. Провайдер (Акадо), на соответствующий вопрос, в телефонном разговоре предложил подключиться к услуге Реальный адрес, за деньги естественно.
| | |
|
| 1.5, Аноним (-), 13:00, 15/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
хм.
что я делаю не так?
подключаюсь с галочкой - инет выпадает
подключаюсь без - сеть работает так же.
| | |
| |
| 2.7, Брызгалов (?), 15:19, 15/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> подключаюсь без - сеть работает так же.
поясни, какая сеть работает так же? Если ты имеешь ввиду, то что у тебя работает и связь с инетом и связь с ресурсами удаленной сети. То скорее всего админ твоего сервера pptp настроил отдельный dhcp для клиентов, в конфиге которого прописал раздачу статических маршрутов.
Либо сделал мап адресов, поднял днс зону для клиентов, а доступ к удаленный сети у тебя через днс
| | |
|
| 1.8, Андрей (??), 21:38, 15/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Прощё просто выделить внешним клиентам не такую популярную в домовых сетях подсеть как 192.168.0.0/24
| | |
| 1.9, Аноним (-), 03:02, 16/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Большей чуши в жизни не читал. Срочно узнаём про виртуальные туннели и преобразование сетевых адресов. И - вдогонку - про L2TP/IPsec тоже. Ещё один велосипедостроитель с "красивыми и простыми решениями"! Мне страшно за Ваших удалённых пользователей...
| | |
| |
| 2.11, Брызгалов Константин (ok), 08:01, 16/03/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Конкретней выражайся, в чем именно заключается "чушь"?
Где-то в тексте совета стоит вопрос о выборе решения? - нет, не стоит. По всему выходит, что чушь как раз написана тобой.
| | |
|
| 1.13, han (??), 09:21, 20/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Т.е., описанная проблема с маршрутами на удалённом клиенте решается тем, что на интерфейсе как бы адрес из удалённой сети, и она как бы становится connected-сетью верно?
Тогда такой вопрос: а какая маска устанавливается на клиентском ppp-интерфейсе? Обычно у ppp адреса /32, а если так, то работоспособность решения вызывает сомнения, т.к. как бы удалённая сеть уже становится не connected.
| | |
| |
| 2.14, Брызгалов Константин (ok), 13:04, 20/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Т.е., описанная проблема с маршрутами на удалённом клиенте решается тем, что на
> интерфейсе как бы адрес из удалённой сети, и она как бы
> становится connected-сетью верно?
На интерфейсе pptp клиента адрес той сети которая выдается в конфиге pptp сервера. В статье это 10.50.11.0. ПО установленной на клиенте обращается к сети которая "как будто локальная" для компа, то есть маршрут на нее прямой а не через шлюз.
> Тогда такой вопрос: а какая маска устанавливается на клиентском ppp-интерфейсе? Обычно
> у ppp адреса /32, а если так, то работоспособность решения вызывает
> сомнения, т.к. как бы удалённая сеть уже становится не connected.
Про маску хорошее замечание, я честно говоря не посмотрел. Однако, если бы у меня не заработало, я бы заметку не написал. Все что описано работает - так что сомнения напрасны.
| | |
| |
| 3.15, alex.h (??), 10:07, 21/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
В любом случае вывод ipconfig и route print с виндовс-клиента хорошо проиллюстрировал бы заметку. Мне пришлось два или три раза перечитать, для того чтобы понять как NAT решает проблему маршрута по-умолчанию.
| | |
| |
| 4.17, Брызгалов Константин (ok), 11:25, 21/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Раздел NOTES, map pptpd.conf предлагает такие примеры
NOTES
An ip-specification above (for the localip and remoteip tags) may be a
list of IP addresses (for example 192.168.0.2,192.168.0.3), a range
(for example 192.168.0.1-254 or 192.168.0-255.2) or some combination
(for example 192.168.0.2,192.168.0.5-8). For some valid pairs might be
(depending on use of the VPN):
localip 192.168.0.1
remoteip 192.168.0.2-254
or
localip 192.168.1.2-254
remoteip 192.168.0.2-254
В моем конфиге:
remoteip 10.50.11.10-254
Про использовании маски для клиентских IP в man ничего нет. Получается win сама определяет маску в соответствии со стандартом.
| | |
| |
| 5.18, alex.h (??), 13:33, 21/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Достаточно забавно, что при:
> IPv4-адрес. . . . . . . . . . . . : 10.50.11.10(Основной)
> Маска подсети . . . . . . . . . . : 255.255.255.255
она добавляет маршрут 10/8.
| | |
| |
| 6.19, Брызгалов Константин (ok), 13:54, 21/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Достаточно забавно, что при:
>> IPv4-адрес. . . . . . . . . . . . : 10.50.11.10(Основной)
>> Маска подсети . . . . . . . . . . : 255.255.255.255
> она добавляет маршрут 10/8.
ага, но закономерность есть - берет маску из RFC и вперед.
Изменил конфиг pptpd на
localip 192.168.111.1
remoteip 192.168.111.10-254
сеть класса С - /24, получаем
---- вырезка ---
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
...
192.168.111.0 255.255.255.0 192.168.111.1 192.168.111.10 26
192.168.111.10 255.255.255.255 On-link 192.168.111.10 281
...
===========================================================================
Постоянные маршруты:
Отсутствует
-----
То есть можно сузить в принципе диапазон.
pptp - костыль :)
| | |
|
|
|
|
|
| 1.20, drTr0jan (?), 17:08, 21/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 > Возможности передать маршруты в рамках соединения клиент-сервер через pptpd нет.
Собственно это и есть самая главная проблема. Говорят, есть какой-то патч, позволяющий отправлять DHCP-options. Но я сам на линуксе второй день, и разбираться с этим не стал.
Cisco кстати прекрасно выдаёт маршруты по PPTP. Из чего складывается предположение, что pptpd -костыль, нежели сам PPTP протокол.
| | |
| |
| |
| |
| 4.25, Брызгалов Константин (ok), 07:48, 22/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Возможно это поможет http://www.linux.org.ru/forum/admin/5872966
Слушай, а ты внимательно читал обсуждаемый текст? - ведь в нем написано о том, что есть другой способ решения вопроса, и вкратце описано какой. Именно тот который ты и привел по ссылке.
Кроме того, по приведенной ссылке нет ничего нового, - где-то в какой-то старой версии пакета какой-то версии gentoo есть готовое решение.
И кстати твоя ссылка еще раз утверждает в том мнении, что в рамках протокола pptp нет способа передать клиенту маршрут.
Попробую найти время и пройти до конца путь с использованием dhcp-relay.
| | |
| |
| 5.26, drTr0jan (?), 14:45, 22/03/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Я ж говорю, на Linux'е второй день. То, что в рамках протокола PPTP нельзя передавать маршруты, это известно. Известно и другое, что маршруты можно передавать через DHCP. И циска это умеет нативно. А вот Linux не умеет (видел, что народ сталкивался с трудностями). На FreeBSD таким никогда не занимался, не доводилось (а сейчас под рукой нет).
Решишь эту проблему, отлично.
| | |
|
|
| 3.31, GalaxyMaster (?), 06:59, 25/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Я сразу отвечу на пару вопросов этой ветки здесь.
1. Сам PPTP предоставляет только тунель между двумя точками и средств маршрутизации в нем не предусмотрено.
2. Существует 2 официальных способа настраивать маршрутизацию для PPTP туннелей: динамическая (RIP, OSPF) и статическая (DHCP stateless static routes).
3. L2TP - это тот же PPTP вид сбоку (использует IP/UDP вместо GRE, и может быть опционально обернут в IPsec).
Пример конфигурации статики в связке accel-ppp + dnsmasq можно увидеть здесь:
http://forum.opennet.ru/openforum/vsluhforumID10/4943.html?n=GalaxyMaster#8
В приведеном примере accel-ppp можно заменить на poptop (или любой другой), а dnsmasq на какой-нить другой DHCP сервер.
С динамикой немного более плачевно, так как для того, чтобы она работала нужна еще поддержка на стороне клиента (ну, для DHCP она тоже нужна, но DHCP чаще всего есть, чем нет).
| | |
| |
| 4.32, Брызгалов Константин (ok), 09:32, 25/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Исчерпывающий ответ по теме. Было бы здорово, если бы он был оформлен в виде заметки на этом ресурсе.
Закрыли бы тему надолго. А то в сети полно воды по этому вопросу.
>[оверквотинг удален]
> (RIP, OSPF) и статическая (DHCP stateless static routes).
> 3. L2TP - это тот же PPTP вид сбоку (использует IP/UDP вместо
> GRE, и может быть опционально обернут в IPsec).
> Пример конфигурации статики в связке accel-ppp + dnsmasq можно увидеть здесь:
> http://forum.opennet.ru/openforum/vsluhforumID10/4943.html?n=GalaxyMaster#8
> В приведеном примере accel-ppp можно заменить на poptop (или любой другой), а
> dnsmasq на какой-нить другой DHCP сервер.
> С динамикой немного более плачевно, так как для того, чтобы она работала
> нужна еще поддержка на стороне клиента (ну, для DHCP она тоже
> нужна, но DHCP чаще всего есть, чем нет).
| | |
|
|
| 2.27, alex.h (??), 10:23, 23/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Возможности передать маршруты в рамках соединения клиент-сервер через pptpd нет.
> Собственно это и есть самая главная проблема. Говорят, есть какой-то патч, позволяющий
> отправлять DHCP-options.
> Cisco кстати прекрасно выдаёт маршруты по PPTP. Из чего складывается предположение, что
> pptpd -костыль, нежели сам PPTP протокол.
Как показывает небольшое изучение вопроса, всё гораздо грустнее. Это ограничение не ПО pptpd, и даже не самого PPTP, а лежащего в его основе PPP, а ещё точнее протокола IPCP (http://ru.wikipedia.org/wiki/IPCP), который осуществляет конфигурирование IP для PPP-соединения, в общих чертах об этом написали в этом (http://www.ljpoisk.ru/archive/10048289.html) обсуждении.
Если же заглянуть поглубже (http://tools.ietf.org/html/rfc1332), оказывается что из интересующих нас параметров IPCP умеет согласовывать только локальный и удалённый IP-адреса. Маршрутов он не умеет передавать вообще никаких, даже "по умолчанию". Этот маршрут добавляется клиентской стороной самостоятельно, если выбрана такая опция (можно почитать описание опции defaultroute здесь: http://all-linux.narod.ru/contents/PPP.html)
Более того, IPCP не согласовывает даже сетевую маску для интерфейса, она на автомате она устанавливается в /32, также для pppd её можно установить руками (описание опции netmask по предыдущей ссылке). Cisco умеет передавать маску (http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/dtpppsub.pdf), но очень похоже, что это хак.
Интересный вопрос, можно ли вообще плюнуть на IPCP при установке PPP-соединения и получить его настройки через DHCP?
Чем больше про него узнаёшь, тем меньше PPTP кажется стоящим протоколом :)
| | |
| |
| 3.28, Брызгалов Константин (ok), 14:12, 23/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Как показывает небольшое изучение вопроса, всё гораздо грустнее...
> Если же заглянуть поглубже ...
Благодарю за потраченное время и силы. Отличное освещение вопроса.
> но очень похоже, что это хак.
скорее всего встроили в код своего сервера решение с dhcp. Не верится, что они с microsoft договорились и реализовали на обеих сторонах что то не входящее в стандарт.
> Интересный вопрос, можно ли вообще плюнуть на IPCP при установке PPP-соединения и
> получить его настройки через DHCP?
По словам некоторых товарищей из инета - можно.
> Чем больше про него узнаёшь, тем меньше PPTP кажется стоящим протоколом :)
Помимо всего он еще и небезопасен. Про это много написано в сети. Его уже бы и забыли, но клиентское ПО много где реализовано и предлагается как один из вариантов vpn.
| | |
| 3.29, drTr0jan (?), 09:46, 24/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
А L2TP не ковыряли?
PPTP уже умирает (учитывая открывшиеся подробности) вместе с WinXP (где оно из коробки присутствует). А в Win7 есть стоковый L2TP клиент.
| | |
| |
| 4.30, alex.h (??), 21:49, 24/03/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> А L2TP не ковыряли?
Нет, с L2TP пока общаться не приходилось. Но на моей текущей работе поднятие VPN серверов и не относится к моей деятельности, больше приходится клиентом к разным серверам цепляться. Может на домашнем подниму посмотреть.
> PPTP уже умирает (учитывая открывшиеся подробности) вместе с WinXP (где оно из коробки присутствует). А в Win7 есть стоковый L2TP клиент.
Клиент-то есть, но пока традиция ещё сильна :) По крайней мере, по моим наблюдениям.
| | |
|
|
|
| |
| 2.24, Андрей... (?), 21:00, 21/03/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
 какой-то кошмар.... а есче можно обсуждать проблемы добавления маршртов...724
| | |
| |
| 3.33, Alex (??), 16:14, 02/12/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > какой-то кошмар.... а есче можно обсуждать проблемы добавления маршртов...724
Не, это было бы конечно здорово, если бы и днс-сервер той сетки отдавал айпишники с учётом маппинга, но что-то, я дико извиняюсь, не гулиццо нифига такое, а без этого, кроме как "жутткий_костыль" - подругому не назовёшь, исчо раз извиняйте если что не так... /_\
| | |
| |
| 4.34, Dmitry (??), 16:35, 12/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> какой-то кошмар.... а есче можно обсуждать проблемы добавления маршртов...724
> Не, это было бы конечно здорово, если бы и днс-сервер той сетки
> отдавал айпишники с учётом маппинга, но что-то, я дико извиняюсь, не
> гулиццо нифига такое, а без этого, кроме как "жутткий_костыль" - подругому
> не назовёшь, исчо раз извиняйте если что не так... /_\
Есс-но это адский костыль, к тому же кривой. Об ошибках автору костыля говорить бессмысленно. Он ведь думает, что PPTP может передавать маршруты, но это не так.
Маршруты передает dnsmasq, который туп как пробка и в больших сетях практически бесполезен.
Правильнее использовать нормальный DHCP для передачи маршрутов и выдачи адресов.
| | |
| |
| 5.35, Константин Брызгалов (ok), 17:18, 12/02/2013 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>> Не, это было бы конечно здорово, если бы и днс-сервер той сетки
>> отдавал айпишники с учётом маппинга, но что-то, я дико извиняюсь, не
>> гулиццо нифига такое, а без этого, кроме как "жутткий_костыль" - подругому
>> не назовёшь, исчо раз извиняйте если что не так... /_\
> Есс-но это адский костыль, к тому же кривой. Об ошибках автору костыля
> говорить бессмысленно. Он ведь думает, что PPTP может передавать маршруты, но
> это не так.
> Маршруты передает dnsmasq, который туп как пробка и в больших сетях практически
> бесполезен.
> Правильнее использовать нормальный DHCP для передачи маршрутов и выдачи адресов.
:)
| | |
|
|
|
|
|