The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

pptpd и решение проблемы маршрута по умолчанию
Суть вопроса: 
Имеем настроенный на 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. Встретил
здесь. Может быть он более
правильный, но мне приведенное решение показалось более красивым и простым.

PS:  Не забудьте разрешить соединения через цепочку FORWARD, если используется
политика "Запрещено все, что не разрешено".
 
14.03.2012 , Автор: Брызгалов Константин
Ключи: pptp, route, dhcp, linux / Лицензия: CC-BY
Раздел:    Корень / Администратору / Сетевая подсистема, маршрутизация / PPP, PPTP, PPPOE

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 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
     
     
  • 2.10, Брызгалов Константин (ok), 07:36, 16/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ты текст перечитай вдумчиво, поймешь что написал бред ...
     

  • 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.16, Брызгалов Константин (ok), 11:18, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Согласен и исправляюсь ----- верезка ----- Адаптер PPP VPN-подключение DNS... большой текст свёрнут, показать
     
  • 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 протокол.

     
     
  • 2.21, Брызгалов Константин (ok), 18:45, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Говорят, есть какой-то патч, позволяющий отправлять DHCP-options

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

     
     
  • 3.22, drTr0jan (?), 18:57, 21/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Возможно это поможет http://www.linux.org.ru/forum/admin/5872966
     
     
  • 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 клиент.

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

     

  • 1.23, Андрей... (?), 20:57, 21/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чегото я не понял... о ЧЕМ ЗАМЕТКА?
     
     
  • 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 для передачи маршрутов и выдачи адресов.

    :)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру