PPTP и маршрутизация

Решил отказаться от openvpn, решать через суровый pptp.

Да вы батенька тот еще «эстет», собстно заданные вами вопросы как раз легко решаются именно openvpn

чтобы default-маршрут клиенту не добавлялся

nodefaultroute

чтобы клиенту приходили статические маршруты

емнип никак, не умеет он такого. на клиенте в /etc/ppp/ip-up пропишите поднятие маршрутов

Если я подключу isc-dhcp мне опцию remoteip убирать надо будет или нет?

вы его простите куда вешать собираетесь? :)

Да вы батенька тот еще «эстет», собстно заданные вами вопросы как раз легко решаются именно openvpn

100% согласен.

nodefaultroute

Не работает с pptp, хотя у самого pppd такая опция есть.

емнип никак, не умеет он такого.

Сам pptpd/pppd нет.

1) чтобы default-маршрут клиенту не добавлялся
2) чтобы клиенту приходили статические маршруты

Как-то так получится для isc-dhcp:

option ms-classless-routes code 249 = array of unsigned integer 8;
option rfc3442-classless-routes code 121 = array of unsigned integer 8;

shared-network PPTP {
        authoritative;
        option domain-name-servers 192.168.199.1, 8.8.8.8;
        option netbios-name-servers 192.168.199.1;
        default-lease-time 3600;
        max-lease-time 7200;

        subnet 192.168.199.0 netmask 255.255.255.0 {
                option routers 192.168.199.1;
                option ms-classless-routes 24, 192,168,0, 192.168.199.1, 24, 192,168,212, 192,168,199,1;
                option rfc3442-classless-routes 24, 192,168,0, 192.168.199.1, 24, 192,168,212, 192,168,199,1;
        }

}

Да, так вот формат для этих двух опций.

3) я вообще не понимаю, выдавать ip-адреса - это задача dhcp-сервера. А тут pptpd частично берёт на себя задачу dhcp, но привязывает ip не к mac, а к учётке. Если я подключу isc-dhcp мне опцию remoteip убирать надо будет или нет?

Не вижу смысла: пусть дальше pptpd выдает IP по учеткам. А DHCP выдаст пути роутинга.

Не работает с pptp, хотя у самого pppd такая опция есть.

Эмм, простите а у вас pptp без pppd работает?
Так что еще как работает... инфа 146%

Не вводите в заблуждение, pptpd это не умеет.

Эмм, простите а у вас pptp без pppd работает?

Разумеется с pppd, поэтому я про него и сказал.

Так что еще как работает... инфа 146%

Значит зависит от версии pppd и от клиента. pppd version 2.4.5, клиенты винды 7,8,10, маршрут по умолчанию на винде прописывается, пока галку в настройках TCP/IP на винде не снять.

Не вводите в заблуждение, pptpd это не умеет.

А причем тут pptpd, если настройки для dhcpd ?

Да, еще в /etc/pptpd.conf на всякий стоит прописать:

bcrelay ethX

Где ethX - интерфейс внутренней сети.

Ах да: раз дефолтный маршрут выдавать не надо, то

option routers 192.168.199.1;

Значит зависит от версии pppd и от клиента. pppd version 2.4.5, клиенты винды 7,8,10, маршрут по умолчанию на винде прописывается, пока галку в настройках TCP/IP на винде не снять.

Простите, недопонимание вышло. Вы правы. Я про клиента писал :)

ТС что нужно? pptp правильно? правильно.

Да вы батенька тот еще «эстет», собстно заданные вами вопросы как раз легко решаются именно openvpn

openvpn нужно, во-первых - установить, во-вторых сгенерировать штук 8 ключей, в-третьих ещё по паре ключей, если будет заводиться второй, третий клиент. Не нужен мне такой геморрой.

на клиенте в /etc/ppp/ip-up пропишите поднятие маршрутов

Во-первых вы советуете костылизм, во-вторых разве я говорил что на клиенте линукс

вы его простите куда вешать собираетесь? :)

На ppp0. Если я что-то недопонимаю - то прошу объяснить.

2) напиши скрипт изменения дефолта после подключения к ппп, делов на 3 минуты

Остальные пункты после этого отвалятся.

Во-первых вы советуете костылизм, во-вторых разве я говорил что на клиенте линукс

Если там не линукс - это что-то меняет? Напиши батник.

openvpn нужно, во-первых - установить, во-вторых сгенерировать штук 8 ключей, в-третьих ещё по паре ключей, если будет заводиться второй, третий клиент. Не нужен мне такой геморрой.

Шел 2016-й год.... акуеть проблема. (кстати открою тайну, openvpn по логину с паролем тоже умеет.) и вместо простого «секса» решили «в гамаке и стоя», ну-ну. Да, забыл добавить, «гамак» не везде есть, «стабильная» работа pptp через нат.

На ppp0. Если я что-то недопонимаю - то прошу объяснить.

1. pptp не умеет dhcp, не будет он у вас ничего от него получать.
2. для каждого клиента на сервере создается отдельный интерфейс ppp1,ppp2 и т.д. по кол-ву клиентов.

ТС что нужно? pptp правильно? правильно.

Извините, у нас с Вами опять недопонимание :) ТС написал что хочет прикрутить isc-dhcp к pptpd и я сразу выдал ему готовый конфиг для dhcpd. Идея в том, что маршруты выдавать мы поручим dhcpd. Можно попробовать и IP адреса выдавать, только не вижу смысла.

Вспомнил для чего нужен bcrelay в pptpd: dhcpd скорее всего не будет ничего выдавать на pppX интерфейсы. Поэтому делаем проброс броадкаста с интерфейса локалки на инетрфейсы pppX.

Проблема в другом, клиент ничего из выше перечисленного не умеет, ему тупо пофиг.

openvpn нужно, во-первых - установить, во-вторых сгенерировать штук 8 ключей, в-третьих ещё по паре ключей, если будет заводиться второй, третий клиент. Не нужен мне такой геморрой.

Вот это как раз совсем даже не геморрой. Вот объяснять удаленным клиентам по телефону как это установить бывает тем еще геморроем.

разве я говорил что на клиенте линукс

Вот по этой причине, еще из-за необходимости объяснения удаленным клиентам, ну и желания заказчика разумеется, мне приходится над одном из роутеров держать связку pptpd+dhcpd.

Вот объяснять удаленным клиентам по телефону как это установить бывает тем еще геморроем.

Приходилось такое делать ни раз и не два, никаких проблем. Раньше вообще инструкцию раздавал, но с разрастанием зоопарка винды, забил на это, быстрее по телефону объяснить. Да и при смене ip сервера приходилось объяснять как поправить конфиг, вот это уже посложнее.

мне приходится над одном из роутеров держать связку pptpd+dhcpd.

Шо! Я не прав? ppptp научился получать маршруты с dhcp? Во блин время летит, я то как раз еще в далекие времена на openvpn и переехал из-за этого.
ЗЫ

мне приходится над одном из роутеров держать связку pptpd+dhcpd.

когда появились не ломанные яблокофоны, я под подобную задачу ipsec поднял :)

Проблема в другом, клиент ничего из выше перечисленного не умеет, ему тупо пофиг.

Линуксовый да, не умеет :( Хотя по идее rfc3442-classless-routes как раз для него опция.

option rfc3442-classless-routes code 121 = array of unsigned integer 8;

Возможно вот в этом 121 проблема.

Виндовые клиенты подхватывают статические маршруты без проблем.

Шо! Я не прав? ppptp научился получать маршруты с dhcp?

Так я почему и влез с куском dhcpd.conf в топик про pptpd :) Года три как у меня такая связка работает, правда с виндовыми клиентами.

когда появились не ломанные яблокофоны, я под подобную задачу ipsec поднял :)

:)

Линуксовый да, не умеет :(

Спасибо за пояснение, значит все еще ничего не поменялось. Ради интереса, не в курсе как на маке, телефонах с этим?
ЗЫ Винда раньше тоже не умела.

Ради интереса, не в курсе как на маке, телефонах с этим?

Не в курсе, не доводилось тестировать.

Вот объяснять удаленным клиентам по телефону как это установить бывает тем еще геморроем.

Работал три года назад эникейщиком в отдалённом офисе фирмы. Там для подключения к файлопомойке на сервере в основном офисе использовался openvpn. На сервере использовался скрипт, который генерил ключи клиенту, помещал их в zip-архив, туда же совал конфиг, windows-версию openvpn и инструкцию в которой всё было разжёвано. Но тем не менее юзеры всё равно писали, что у них не заработало.

Шо! Я не прав? ppptp научился получать маршруты с dhcp? Во блин время летит, я то как раз еще в далекие времена на openvpn и переехал из-за этого.

То есть openvpn используют неосиляторы pptpd? Не знаю какие именно далёкие времена, провайдер к которому я был подключён в 2006 году, подключал как раз по pptp и статические маршруты выдавал для пиринга.

для каждого клиента на сервере создается отдельный интерфейс ppp1,ppp2 и т.д. по кол-ву клиентов.

То есть получается у того провайдера не сервере было >5000 ppp-интерфейсов, это ж какая нагрузка на ядро. Хотя провайдеры GNU/Linux не используют, всё это наверняка на каком-нибудь MikroTik RouterOS крутилось, на специальной железке.
Сильно не хотелось сползать в холивар, поэтому и написал в начале, что openvpn не подойдёт, ну не нужно мне в данный момент ни параноидальное шифрование, ни tap-интерфейсы, ради чего openvpn и ставят, зато pptp присутствует в оффтопике, начиная с 98, проверенная временем технология. То есть если срочно что-то понадобиться, я могу на любом компьютере, где есть Интернет, поднять pptp-тунель за 1 минуту, потом вставить флешку с портативными версиями программ и начать админить.

Хочу сделать VPN-доступ из дома на работу

корп прокси обходить? мб хватит просто ssh туннеля?

ТС написал что хочет прикрутить isc-dhcp к pptpd и я сразу выдал ему готовый конфиг для dhcpd.

Не всё с этим готовым конфигом понятно. Вот в нём есть строка

subnet 192.168.0.0 netmask 255.255.255.0

Не знаю какие именно далёкие времена, провайдер к которому я был подключён в 2006 году, подключал как раз по pptp и статические маршруты выдавал для пиринга.

Наглое 4.2, провайдер вам раздает адреса для пиринга по dhcp на eth. И в 2016-м году также все осталось. Для примера попробуйте посмотреть, если есть где, тот же пчелайн.

То есть получается у того провайдера не сервере было >5000 ppp-интерфейсов, это ж какая нагрузка на ядро.

В началах 2000-х это осиливал один сервак и не пыхтел, норм все работало.

зато pptp присутствует в оффтопике, начиная с 98, проверенная временем КОСТЫЛЬНАЯ технология.

Поправил и не благодарите

я могу на любом компьютере, где есть Интернет, поднять pptp-тунель за 1 минуту,

Тоже 4.2, курим внимательно работу pptp через нат, о чем я писал выше, а при учете того, что ната сейчас оооочень много, то Вашу формулировку скорее надо трактовать так: «я ЕСЛИ ПОВЕЗЕТ на любом компьютере, где есть Интернет, поднять pptp-тунель за 1 минуту»

Продолжим: Вас не пугает что на «любом компьютере» с которого вы собираетесь «начать админить» уйдут данные вашего подключения.... Ну-ну. Кароший такой админ.
Верите, нет, но с гораздо меньшей вероятностью ваши данные улетят куда-то, если вы заведете флеху с openvpn (запускаемую с нее, а не инсталируемую) которая, только если надо tap интерфейс воткнет (btw скрипты там в наличии), еще и для паранойи добавите запросы паролей. А вот «диалап пароли» воровать начали еще со времен win95, так что эта технология как раз отточена годами. С openvpn как я написал выше, шансов во много раз меньше.

Следующая часть «марлезонского балета». Openvpn настраивается и на смартах, и норм работает, так что в очень критичных/ленивых случаях «начать админить» можно и с телефона.

Не всё с этим готовым конфигом понятно. Вот в нём есть строка

subnet 192.168.0.0 netmask 255.255.255.0

обычно в конфиге isc-dhcp такая строка используется, чтобы указать серверу выдавать адреса из конкретной сети. Но ip-адрес был уже выдан pptpd. Конфликта тут не будет, не могут тут два сервера выдать клиенту два разных адреса?

Все верно, в моем посте и написано

subnet 192.168.199.0 netmask 255.255.255.0

К тому же напомните мне, у ppp-интерфейсов какие-то особенности есть, кажется что это соединение «точка-точка» в котором принципиально не может быть более двух узлов

Разумеется, PPP = Point to Point.

и кажется что какие-то типы трафика через эти соединения ходить не могут.

По дефолту броадкастовый трафик по нему не ходит, с остальным трафиком проблем быть не должно.

То есть openvpn используют неосиляторы pptpd?

Нет, его используют те, кто привык к проверенным и надежным решениям.

Не знаю какие именно далёкие времена, провайдер к которому я был подключён в 2006 году, подключал как раз по pptp и статические маршруты выдавал для пиринга.

Провайдеру нафиг не надо клиентам выдавать никакие статические маршруты: он для них дефолтный шлюз.

То есть получается у того провайдера не сервере было >5000 ppp-интерфейсов, это ж какая нагрузка на ядро. Хотя провайдеры GNU/Linux не используют, всё это наверняка на каком-нибудь MikroTik RouterOS крутилось, на специальной железке.

Сам лично в начале нулевых поднимал сервер pptpd+radius+mysql на GNU/Linux для небольшого провайдера , на нем же крутился биллинг, роутинг статический и динамический на OSPF, файрволл с количеством правил за тысячу (биллинг был основан на iptables). Двухголовый P3 все это прожевывал со средней нагрузкой на процы 5-10%. Клиентов было не >5000, в сотнях измерялось количество, но и железо было отнюдь не серверное.

А вообще никто не запрещает поднять столько pptpd серверов, сколько надо: выделенный сервер авторизации, лоадбалансер и вперед.

К тому же в моем конфиге речь и не идет о выдаче IP адресов, выдаются только маршруты:

                option routers 192.168.199.1;
                option ms-classless-routes 24, 192,168,0, 192.168.199.1, 24, 192,168,212, 192,168,199,1;
                option rfc3442-classless-routes 24, 192,168,0, 192.168.199.1, 24, 192,168,212, 192,168,199,1;

Провайдеру нафиг не надо клиентам выдавать никакие статические маршруты: он для них дефолтный шлюз.

Некорректно выразился: он выдает один статический маршрут, собственно дефолтный :) Для пиринга или чего-то еще статические маршруты выдавать для клиентов уже излишне.

Некорректно выразился: он выдает один статический маршрут, собственно дефолтный

Опять не корректно, он выдает адрес для p-t-p а клиент его прописывает как дефроут.

файрволл с количеством правил за тысячу (биллинг был основан на iptables)

Ой, мама, ну прямо напомнили, у меня он еще на ipchains крутился (писал сам) с конца 90-х :) Правил былоооо... нееб больше чем у вас :) И ничего, норм все работало :)

Провайдеру нафиг не надо клиентам выдавать никакие статические маршруты: он для них дефолтный шлюз.

Ну вообще-то есть живые примеры: Билайн и провайдеры из SVAO-IX, Неторн, например. Сам сейчас посмотреть не могу, у меня Ростелеком, в котором нет никакого пиринга.

Сам лично в начале нулевых поднимал сервер pptpd+radius+mysql на GNU/Linux для небольшого провайдера , на нем же крутился биллинг, роутинг статический и динамический на OSPF, файрволл с количеством правил за тысячу (биллинг был основан на iptables). Двухголовый P3 все это прожевывал со средней нагрузкой на процы 5-10%. Клиентов было не >5000, в сотнях измерялось количество, но и железо было отнюдь не серверное.

Меня мой предшественик предупреждал, чтобы я не создавал на 32-ядерном MikroTik RouterBoard много правил в filter rules, лучше решать через address lists, иначе тормозить начшёт. Выходит он меня в заблуждение ввёл?

Что-то не срослось

Not configured to listen on any interface

option ms-classless-routes 24, 192,168,0, 192,168,199,1, 24, 192,168,212, 192,168,199,1;
option rfc3442-classless-routes 24, 192,168,0, 192,168,199,1, 24, 192,168,212, 192,168,199,1;

Ну вообще-то есть живые примеры: Билайн

Читайте мой пост выше, билайн (как и все остальные) маршруты раздает на eth т.е. еще до подключения pptp. Вот вам реально что есть

ip r s | grep eth1
10.0.0.0/8 via 10.193.8.1 dev eth1  metric 203
10.193.8.0/21 dev eth1  proto kernel  scope link  src 10.193.8.30
10.193.8.0/21 dev eth1  proto kernel  scope link  src 10.193.8.30  metric 203
78.107.1.255 via 10.193.8.1 dev eth1
78.107.23.0/24 via 10.193.8.1 dev eth1  metric 203
78.107.51.0/28 via 10.193.8.1 dev eth1  metric 203
78.107.52.0/26 via 10.193.8.1 dev eth1  metric 203
78.107.196.0/22 via 10.193.8.1 dev eth1  metric 203
78.107.235.4/30 via 10.193.8.1 dev eth1  metric 203
83.102.146.96/27 via 10.193.8.1 dev eth1  metric 203
83.102.231.32/28 via 10.193.8.1 dev eth1  metric 203
85.21.72.80/28 via 10.193.8.1 dev eth1  metric 203
85.21.79.0/24 via 10.193.8.1 dev eth1  metric 203
85.21.90.0/24 via 10.193.8.1 dev eth1  metric 203
85.21.108.16/28 via 10.193.8.1 dev eth1  metric 203
85.21.138.208/28 via 10.193.8.1 dev eth1  metric 203
85.21.192.3 via 10.193.8.1 dev eth1
195.14.50.0/27 via 10.193.8.1 dev eth1  metric 203
217.118.84.213 via 10.193.8.1 dev eth1  metric 203
217.118.84.249 via 10.193.8.1 dev eth1  metric 203
233.33.210.0/24 via 10.193.8.30 dev eth1  metric 203

ip r s | grep ppp3
default via 78.107.1.255 dev ppp3
78.107.1.255 dev ppp3  proto kernel  scope link  src 78.107.x.x

Меня мой предшественик предупреждал, чтобы я не создавал на 32-ядерном MikroTik RouterBoard много правил в filter rules, лучше решать через address lists, иначе тормозить начшёт. Выходит он меня в заблуждение ввёл?

Я не работал с MikroTik RouterBoard, соответственно что такое «filter rules» и «address lists» не в курсе, так что не могу ничего сказать на счет заблуждения. Я просто конкретным примером из личного опыта показал, что pptpd, куча интерфейсов, куча правил в файрволле - это нифига не нагрузка для ядра.

Что-то не срослось
Not configured to listen on any interface

Если у Вас dhcpd сконфигурирован только для PPTP то оно и понятно: скорее всего ни один интерфейс pppX не поднят. Да даже если и будет поднят, скорее всего будет тоже самое: pppX скорее всего не имеет флага BROADCAST. У меня dhcpd еще и на локальный инерфейс раздает подсети, поэтому для устранения этой проблемы используется bcrelay.

Если у Вас dhcpd сконфигурирован только для PPTP то оно и понятно: скорее всего ни один интерфейс pppX не поднят. Да даже если и будет поднят, скорее всего будет тоже самое: pppX скорее всего не имеет флага BROADCAST. У меня dhcpd еще и на локальный инерфейс раздает подсети, поэтому для устранения этой проблемы используется bcrelay.

«bcrelay eth0» у меня прописан. Значит теперь броадкасты пробрасываются на eth0 и на него, соответственно, и нужно повесить dhcp. Только нужна ещё какая-то настройка, чтобы клиенты из локалки от dhcp ничего не хватали.

Если вы на eth0 повесите dhcpd то понятное дело что он начнет отвечать клиентам из локалки :( Как вариант создать интерфейс br0, в него не включать другие интерфейсы, и на него повесить dhcpd. Ну и прописать bcrelay br0. Костыль конечно, но зато гарантировано изолируете подсеть PPTP от локалки.

Но лучше, конечно, обойтись вообще без bcrelay, но тут вопрос как заставить dhcpd отвечать на броадкасты с ppppX интерфейсов.

br0 это хорошая мысль. Вот в вики написано http://xgu.ru/wiki/Linux_Bridge

Мосты Linux очень гибкие; можно соединять как традиционные ethernet-устройства, так и псевдоустройства такие как PPP, VPN или VLANы.

То есть можно в /etc/sysconfig/network-scripts/ifup-ppp или в /etc/ppp/ip-up вписать строчку, которая будет добавлять pppX в br0 и будет работать?

2016 год
использовать PPTP по доброй воле, а не по суровой указке legacy/продакшена

Мазохист вы, батенька. Как пить дать - мазохист.

ppp нельзя добавить в мост, это девайс более высокого, не канального уровня

tap-устройство, например от OpenVPN - можно.

Грубо говоря - если в инфе у устройства есть MAC-адрес - его можно добавить в мост. У tap-устройств(L2, канальный уровень) - он есть. У tun(L3, сетевой) - нет, хотя работают они через один драйвер.

Описание неточное, но общую суть из него ухватить я думаю можно.

Есть еще всякие трюки типа proxy arp, но не забивай ими себе голову

openvpn также как и pptpd умеет раздавать адреса сам, но в режиме tap эту роль можно отдать на откуп стороннему dhcp-серверу

bcrelay

Ооооо, сколько я ж с этим натрахался в своё время-то, а! :-)

Спасибо! Про сетевой уровень не знал. Тогда кто-нибудь, у кого есть учётка на xgu.ru может отредактировать статью, чтобы не вводила в заблуждение?
У меня всё работает. Добавил ещё маршруты и теперь могу удалённо заходить из дома на любую железку рабочей сети. Один минус есть, то что соединение перезапускать регулярно нужно, но это мелочи. Зато теперь, когда я знаю как настраивается связка pptpd+dhcpd, в следующий раз я смогу её настроить минут за 10 без всякого мазохизма. Настройка openvpn заняла бы гораздо больше времени и не нужно это параноидальное шифрование когда и клиент и сервер - твои.

Тогда кто-нибудь, у кого есть учётка на xgu.ru может отредактировать статью, чтобы не вводила в заблуждение?

Какую статью? OpenVPN? Там вообще не упоминается этот факт, официальные доки рулят

Настройка openvpn заняла бы гораздо больше времени и не нужно это параноидальное шифрование когда и клиент и сервер - твои.
параноидальное шифрование

Дай угадаю, ты используешь MPPE-128 и авторизацию MSCHAPv2? Лол, это все равно что пускать трафик нешифрованным. Хоть как-то безопасным в PPTP является только EAP, да и то - сами мелкомягкие уже давно говорят: переходи на тёмную сторону^W^W^W^W выкинь PPTP, юзай наш «кошерный» SSTP.

То есть уже разработчики протокола говорят что он - живой труп в плане безопасности.

Ты не понял, я с первого поста утверждаю, что мне вообще не нужно шифрование. Я подключаюсь по vpn к своей сети, а потом подключаюсь по ssh к отдельным элементам этой сети. Зачем мне шифрованый канал внутри шифрованого канала. К тому же шифрование скорость передачи данных снижает.
Да, и я имел в виду статью Linux_Bridge