URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 83604
[ Назад ]
Исходное сообщение
"Раздел полезных советов: pptpd и решение проблемы маршрута п..."
Отправлено auto_tips , 15-Мрт-12 03:34 
Суть вопроса:
Имеем настроенный на linux pptp сервер для подключения внешних клиентов к ресурсам внутренней сети. При установлении соединения с pptp сервером на машине windows клиента поднимается маршрут по умолчанию с более высоким приоритетом, чем маршрут через основное подключение. Вследствие чего перестает работать связь с Интернет, со всеми вытекающими последствиями. Если же в свойствах pptp соединения отключить галочку с пункта  "Использовать основной шлюз в удаленной сети", то пропадает связь до ресурсов в удаленной сети. Возможности передать маршруты в рамках соединения клиент-сервер через pptpd нет.

Решение:
Используем мапирование адресных пространств сетей. Будем транслировать то пространство, которое является локальным для интерфеса windows клиента после установки соединения.

Например, имеем адресное пространство удаленной(по отношению к клиенту) сети 192.168.0.0/24, а адрес интерфейса pptpd:

   # grep localip /etc/pptpd.conf
   localip 10.50.11.1

Настраиваем трансляцию адресного пространства:

   # iptables -t nat -A PREROUTING -d 10.50.11.0/24 -j NETMAP --to 192.168.0.0/24 -m comment --comment "For_PPTPD_clients"

После чего с клиентской машины есть связь и с интернет, и с ресурсами удаленной сети через адреса 10.50.11.x. Неудобство с применением IP можно обойти через настройку dns с использованием отдельной зоны для клиентов pptpd сервера.

Необходимо отметить, что есть еще другой путь решения проблемы - через настройку отдельного dhcp на стороне сервера и использования option ms-classless-static-routes code, option rfc3442-classless-static-routes code. Встретил [[http://linuxforum.ru/viewtopic.php?id=847 здесь]]. Может быть он более правильный, но мне приведенное решение показалось более красивым и простым.

PS:  Не забудьте разрешить соединения через цепочку FORWARD, если используется политика "Запрещено все, что не разрешено".


URL:
Обсуждается: https://www.opennet.ru/tips/info/2674.shtml

Содержание
Сообщения в этом обсуждении
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено dima , 15-Мрт-12 03:34 
а если клиент локально имеет 192,168,0,х адрес ?
ка это в 99% случаев и есть
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов , 15-Мрт-12 11:42 
  Вот в это то как раз случае применение NETMAP позволит обойти проблему пересечения адресных пространств.
  Например дома и на предприятии(удаленная сеть) сеть 192.168.0.0/24, используя NETMAP , можем дать доступ к ресурсам удаленной сети по адресам 10.50.11.0/24.
192.168.0.235 становится адресом 10.50.11.235.
  В случае с openvpn кстати возникает таже проблема и обходить ее проще всего опять таки используя NETMAP
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено анонимаус , 15-Мрт-12 12:33 
  Например дома и на предприятии(удаленная сеть) сеть 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 ?

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов , 15-Мрт-12 15:15 
1. Поднимать необязательно - 10.50.11.0/24 это адрес сети параметра localip в конфиге сервиса pptpd

2. да

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Аноним , 15-Мрт-12 11:21 
>Необходимо отметить, что есть еще другой путь решения проблемы

для себя нашел другой путь решения - использую не PPTP, а OpenVPN. Минус в установке софта клиенту. Зато выдает в т.ч. и маршруты. Плюс отсутствие заморочек с GRE.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 16-Мрт-12 08:15 
>>Необходимо отметить, что есть еще другой путь решения проблемы
> для себя нашел другой путь решения - использую не PPTP, а OpenVPN.
> Минус в установке софта клиенту. Зато выдает в т.ч. и маршруты.
> Плюс отсутствие заморочек с GRE.

  Согласен с Вами полностью, но в моей ситуации необходим был именно pptp. Так задачу поставили.

Кстати, кончилось тем, что пришлось клиенту все таки использовать openvpn. И как раз из-за заморочек с GRE. Клиент сидел на приватных адресах, с которых pptp не транслировался. Провайдер (Акадо), на соответствующий вопрос, в телефонном разговоре предложил подключиться к услуге Реальный адрес, за деньги естественно.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Аноним , 15-Мрт-12 13:00 
хм.
что я делаю не так?
подключаюсь с галочкой - инет выпадает
подключаюсь без - сеть работает так же.
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов , 15-Мрт-12 15:19 

> подключаюсь без - сеть работает так же.

поясни, какая сеть работает так же? Если ты имеешь ввиду, то что у тебя работает и связь с инетом и связь с ресурсами удаленной сети. То скорее всего админ твоего сервера pptp настроил отдельный dhcp для клиентов, в конфиге которого прописал раздачу статических маршрутов.

Либо сделал мап адресов, поднял днс зону для клиентов, а доступ к удаленный сети у тебя через днс

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Андрей , 15-Мрт-12 21:38 
Прощё просто выделить внешним клиентам не такую популярную в домовых сетях подсеть как 192.168.0.0/24
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 16-Мрт-12 07:36 
Ты текст перечитай вдумчиво, поймешь что написал бред ...
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Аноним , 16-Мрт-12 03:02 
Большей чуши в жизни не читал. Срочно узнаём про виртуальные туннели и преобразование сетевых адресов. И - вдогонку - про L2TP/IPsec тоже. Ещё один велосипедостроитель с "красивыми и простыми решениями"! Мне страшно за Ваших удалённых пользователей...
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 16-Мрт-12 08:01 
Конкретней выражайся, в чем именно заключается "чушь"?

  Где-то в тексте совета стоит вопрос о выборе решения? - нет, не стоит. По всему выходит, что чушь как раз написана тобой.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено han , 20-Мрт-12 09:21 
Т.е., описанная проблема с маршрутами на удалённом клиенте решается тем, что на интерфейсе как бы адрес из удалённой сети, и она как бы становится connected-сетью верно?
Тогда такой вопрос: а какая маска устанавливается на клиентском ppp-интерфейсе? Обычно у ppp адреса /32, а если так, то работоспособность решения вызывает сомнения, т.к. как бы удалённая сеть уже становится не connected.
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 20-Мрт-12 13:04 

> Т.е., описанная проблема с маршрутами на удалённом клиенте решается тем, что на
> интерфейсе как бы адрес из удалённой сети, и она как бы
> становится connected-сетью верно?

На интерфейсе pptp клиента адрес той сети которая выдается в конфиге pptp сервера. В статье это 10.50.11.0. ПО установленной на клиенте обращается к сети которая "как будто локальная" для компа, то есть маршрут на нее прямой а не через шлюз.


> Тогда такой вопрос: а какая маска устанавливается на клиентском ppp-интерфейсе? Обычно
> у ppp адреса /32, а если так, то работоспособность решения вызывает
> сомнения, т.к. как бы удалённая сеть уже становится не connected.

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

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено alex.h , 21-Мрт-12 10:07 
В любом случае вывод ipconfig и route print с виндовс-клиента хорошо проиллюстрировал бы заметку. Мне пришлось два или три раза перечитать, для того чтобы понять как NAT решает проблему маршрута по-умолчанию.
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 21-Мрт-12 11:18 
> В любом случае вывод ipconfig и route print с виндовс-клиента хорошо проиллюстрировал
> бы заметку. Мне пришлось два или три раза перечитать, для того
> чтобы понять как NAT решает проблему маршрута по-умолчанию.
> В любом случае вывод ipconfig и route print с виндовс-клиента хорошо проиллюстрировал
> бы заметку. Мне пришлось два или три раза перечитать, для того
> чтобы понять как NAT решает проблему маршрута по-умолчанию.

Согласен и исправляюсь:
----- верезка  -----

Адаптер PPP VPN-подключение:

   DNS-суффикс подключения . . . . . :
   Описание. . . . . . . . . . . . . : VPN-подключение
   Физический адрес. . . . . . . . . :
   DHCP включен. . . . . . . . . . . : Нет
   Автонастройка включена. . . . . . : Да
   IPv4-адрес. . . . . . . . . . . . : 10.50.11.10(Основной)
   Маска подсети . . . . . . . . . . : 255.255.255.255
   Основной шлюз. . . . . . . . . :
   DNS-серверы. . . . . . . . . . . : 172.16.21.1
   NetBios через TCP/IP. . . . . . . . : Включен

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0    192.168.0.200     192.168.0.28     25
         10.0.0.0        255.0.0.0       10.50.11.1      10.50.11.10     26
      10.50.11.10  255.255.255.255         On-link       10.50.11.10    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0         On-link      192.168.0.28    281
     192.168.0.28  255.255.255.255         On-link      192.168.0.28    281
    192.168.0.200  255.255.255.255         On-link      192.168.0.28     26
    192.168.0.255  255.255.255.255         On-link      192.168.0.28    281
      192.168.1.0    255.255.255.0         On-link       192.168.1.3    276
      192.168.1.3  255.255.255.255         On-link       192.168.1.3    276
    192.168.1.255  255.255.255.255         On-link       192.168.1.3    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.1.3    276
        224.0.0.0        240.0.0.0         On-link      192.168.0.28    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.1.3    276
  255.255.255.255  255.255.255.255         On-link      192.168.0.28    281
  255.255.255.255  255.255.255.255         On-link       10.50.11.10    281
===========================================================================
Постоянные маршруты:
  Отсутствует

--- окончание вырезки -------

Что из этого следует?
То, что поднимается маршрут аж на всю 10.0.0.0/8 сеть, а это при некоторых условиях -  косяк. Можно словить пересечение с пространством локальной сети клиента.

Выход, - можно использовать сеть поэкзотичнее в настройках pptpd, например 172.16.0.0/16

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 21-Мрт-12 11:25 
Раздел 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 сама определяет маску в соответствии со стандартом.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено alex.h , 21-Мрт-12 13:33 
Достаточно забавно, что при:

>   IPv4-адрес. . . . . . . . . . . . : 10.50.11.10(Основной)
>   Маска подсети . . . . . . . . . . : 255.255.255.255

она добавляет маршрут 10/8.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 21-Мрт-12 13:54 
> Достаточно забавно, что при:
>>   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 - костыль :)

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено drTr0jan , 21-Мрт-12 17:08 
> Возможности передать маршруты в рамках соединения клиент-сервер через pptpd нет.

Собственно это и есть самая главная проблема. Говорят, есть какой-то патч, позволяющий отправлять DHCP-options. Но я сам на линуксе второй день, и разбираться с этим не стал.
Cisco кстати прекрасно выдаёт маршруты по PPTP. Из чего складывается предположение, что pptpd -костыль, нежели сам PPTP протокол.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 21-Мрт-12 18:45 
>Говорят, есть какой-то патч, позволяющий отправлять DHCP-options

ссылочку можно?

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено drTr0jan , 21-Мрт-12 18:57 
Возможно это поможет http://www.linux.org.ru/forum/admin/5872966
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 22-Мрт-12 07:48 
> Возможно это поможет http://www.linux.org.ru/forum/admin/5872966

  Слушай, а ты внимательно читал обсуждаемый текст? - ведь в нем написано о том, что есть другой способ решения вопроса, и вкратце описано какой. Именно тот который ты и привел по ссылке.
  Кроме того, по приведенной ссылке нет ничего нового, -  где-то в какой-то старой версии пакета какой-то версии gentoo есть готовое решение.
  И кстати твоя ссылка еще раз утверждает в том мнении, что в рамках протокола pptp нет способа передать клиенту маршрут.

  Попробую найти время и пройти до конца путь с использованием dhcp-relay.


"pptpd и решение проблемы маршрута по умолчанию"
Отправлено drTr0jan , 22-Мрт-12 14:45 
Я ж говорю, на Linux'е второй день. То, что в рамках протокола PPTP нельзя передавать маршруты, это известно. Известно и другое, что маршруты можно передавать через DHCP. И циска это умеет нативно. А вот Linux не умеет (видел, что народ сталкивался с трудностями). На FreeBSD таким никогда не занимался, не доводилось (а сейчас под рукой нет).

Решишь эту проблему, отлично.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено GalaxyMaster , 25-Апр-12 06:59 
Я сразу отвечу на пару вопросов этой ветки здесь.

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...

В приведеном примере accel-ppp можно заменить на poptop (или любой другой), а dnsmasq на какой-нить другой DHCP сервер.

С динамикой немного более плачевно, так как для того, чтобы она работала нужна еще поддержка на стороне клиента (ну, для DHCP она тоже нужна, но DHCP чаще всего есть, чем нет).

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 25-Апр-12 09:32 
  Исчерпывающий ответ по теме. Было бы здорово, если бы он был оформлен в виде заметки на этом ресурсе.
  Закрыли бы тему надолго. А то в сети полно воды по этому вопросу.

>[оверквотинг удален]
> (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...
> В приведеном примере accel-ppp можно заменить на poptop (или любой другой), а
> dnsmasq на какой-нить другой DHCP сервер.
> С динамикой немного более плачевно, так как для того, чтобы она работала
> нужна еще поддержка на стороне клиента (ну, для DHCP она тоже
> нужна, но DHCP чаще всего есть, чем нет).

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено alex.h , 23-Мрт-12 10:23 
>> Возможности передать маршруты в рамках соединения клиент-сервер через 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/gui...), но очень похоже, что это хак.

Интересный вопрос, можно ли вообще плюнуть на IPCP при установке PPP-соединения и получить его настройки через DHCP?

Чем больше про него узнаёшь, тем меньше PPTP кажется стоящим протоколом :)

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Брызгалов Константин , 23-Мрт-12 14:12 

> Как показывает небольшое изучение вопроса, всё гораздо грустнее...
> Если же заглянуть поглубже ...

Благодарю за потраченное время и силы. Отличное освещение вопроса.


> но очень похоже, что это хак.

скорее всего встроили в код своего сервера решение с dhcp. Не верится, что они с microsoft договорились и реализовали на обеих сторонах что то не входящее в стандарт.

> Интересный вопрос, можно ли вообще плюнуть на IPCP при установке PPP-соединения и
> получить его настройки через DHCP?

По словам некоторых товарищей из инета - можно.

> Чем больше про него узнаёшь, тем меньше PPTP кажется стоящим протоколом :)

  Помимо всего он еще и небезопасен. Про это много написано в сети. Его уже бы и забыли, но клиентское ПО много где реализовано и предлагается как один из вариантов vpn.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено drTr0jan , 24-Мрт-12 09:46 
А L2TP не ковыряли?
PPTP уже умирает (учитывая открывшиеся подробности) вместе с WinXP (где оно из коробки присутствует). А в Win7 есть стоковый L2TP клиент.
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено alex.h , 24-Мрт-12 21:49 
> А L2TP не ковыряли?

Нет, с L2TP пока общаться не приходилось. Но на моей текущей работе поднятие VPN серверов и не относится к моей деятельности, больше приходится клиентом к разным серверам цепляться. Может на домашнем подниму посмотреть.

> PPTP уже умирает (учитывая открывшиеся подробности) вместе с WinXP (где оно из коробки присутствует). А в Win7 есть стоковый L2TP клиент.

Клиент-то есть, но пока традиция ещё сильна :) По крайней мере, по моим наблюдениям.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Андрей... , 21-Мрт-12 20:57 
Чегото я не понял... о ЧЕМ ЗАМЕТКА?
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Андрей... , 21-Мрт-12 21:00 
какой-то кошмар.... а есче можно обсуждать проблемы добавления маршртов...724
"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Alex , 02-Дек-12 16:14 
> какой-то кошмар.... а есче можно обсуждать проблемы добавления маршртов...724

Не, это было бы конечно здорово, если бы и днс-сервер той сетки отдавал айпишники с учётом маппинга, но что-то, я дико извиняюсь, не гулиццо нифига такое, а без этого, кроме как "жутткий_костыль" - подругому не назовёшь, исчо раз извиняйте если что не так... /_\

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Dmitry , 12-Фев-13 16:35 
>> какой-то кошмар.... а есче можно обсуждать проблемы добавления маршртов...724
> Не, это было бы конечно здорово, если бы и днс-сервер той сетки
> отдавал айпишники с учётом маппинга, но что-то, я дико извиняюсь, не
> гулиццо нифига такое, а без этого, кроме как "жутткий_костыль" - подругому
> не назовёшь, исчо раз извиняйте если что не так... /_\

Есс-но это адский костыль, к тому же кривой. Об ошибках автору костыля говорить бессмысленно. Он ведь думает, что PPTP может передавать маршруты, но это не так.

Маршруты передает dnsmasq, который туп как пробка и в больших сетях практически бесполезен.

Правильнее использовать нормальный DHCP для передачи маршрутов и выдачи адресов.

"pptpd и решение проблемы маршрута по умолчанию"
Отправлено Константин Брызгалов , 12-Фев-13 17:18 
>[оверквотинг удален]
>> Не, это было бы конечно здорово, если бы и днс-сервер той сетки
>> отдавал айпишники с учётом маппинга, но что-то, я дико извиняюсь, не
>> гулиццо нифига такое, а без этого, кроме как "жутткий_костыль" - подругому
>> не назовёшь, исчо раз извиняйте если что не так... /_\
> Есс-но это адский костыль, к тому же кривой. Об ошибках автору костыля
> говорить бессмысленно. Он ведь думает, что PPTP может передавать маршруты, но
> это не так.
> Маршруты передает dnsmasq, который туп как пробка и в больших сетях практически
> бесполезен.
> Правильнее использовать нормальный DHCP для передачи маршрутов и выдачи адресов.

:)