pptp-linux, pppd, pptp-туннель и classless static route.

[koshev]

Всем доброго времени!
Интересует возможность получения маршрутизации через pptp-туннель в 121 и/или 249 option.
В Windows, начиная с XP, это реализовано через клиент-pptp, в Cisco, еяннп, так же.
Как это дело обстоит в Linux (Debian и деривативы)?
Попробовал натравить на туннельный интерфейс dhclient, и ожидаемо нарвался на.

Код: [Выделить]

Unsupported device type 512 for ppp0Может быть кто сталкивался с похожим?
Ситуация следующая:
Нужно подключиться к удалённым сетям по pptp.
Сервером pptp выступает accel-ppp. Клиентом - pptp-linux.
Сети за pptp-сервером: 192.168/24, 192.168.1/27, 213.141.136.40/29.
Клиентам pptp выдаются адреса из 192.168.0.32/27, с доступом только к вышеописанным подсетям, без доступа в сеть Интернет (что впринципе правильно). pptp-сервер он же шлюз, он же DHCP-сервер, он же много_чего_ещё.
В dhcpd.conf за маршрутизацию отвечает следующая секция:

Код: (text) [Выделить]

# <skip>
option ms-route code 249 = string;
# <skip>
shared-network vlan6 {
        subnet 192.168.0.0 netmask 255.255.255.0 {
        # <skip>
        if substring(hardware, 0, 1) = 08 {
              # Маршрутизация на подсети 192.168.1/27 и 213.141.136.40/29
              option ms-route 1d:d5:8d:88:28:c0:a8:00:01:1b:c0:a8:01:00:c0:a8:00:01;
        }
        pool {
              range 192.168.0.65 192.168.0.159;
        }
        # <skip
}
Кроме того развёрнут bcrelay для прохождения broadcast между интерфейсом сети 192.168/24 и ppp+ командой

bcrelay -i vlan6 -o ppp[0-9].* -d

и proxyarp для присутствия удалённых клиентов в сети 192.168/24.
Если подключаться из Windows, то после установлении туннеля, сниффером можно снять следующую информацию:

Код: (text) [Выделить]

root@server:~# tcpdump -vi vlan6 port 67 or port 68
tcpdump: listening on vlan6, link-type EN10MB (Ethernet), capture size 65535 bytes
23:53:47.458440 IP (tos 0x0, ttl 1, id 455, offset 0, flags [none], proto UDP (17), length 328)
    192.168.0.40.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request, length 300, htype 8, hlen 6, xid 0x30d11c6c, secs 1536, Flags [none]
          Client-IP 192.168.0.40
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Inform
            Client-ID Option 61, length 7: hardware-type 8, 00:53:45:00:00:00
            Hostname Option 12, length 15: "pc-fc4cb235e6b4"
            Vendor-Class Option 60, length 8: "MSFT 5.0"
            Parameter-Request Option 55, length 6:
              Domain-Name-Server, Netbios-Name-Server, Vendor-Option, Subnet-Mask
              Classless-Static-Route-Microsoft, Domain-Name
            Vendor-Option Option 43, length 3: 220.1.0
а DHCP сервер отвечает

Код: (text) [Выделить]

Jul  3 00:03:26 server dhcpd: DHCPINFORM from 192.168.0.44 via vlan6
Jul  3 00:03:26 server dhcpd: DHCPACK to 192.168.0.44 (00:53:45:00:00:00) via vlan6В результате на удалённом клиенте появляютя маршруты

(Нажмите, чтобы показать/скрыть)

Код: (text) [Выделить]

C:\>route print -4
===========================================================================
Список интерфейсов
 36...00 1b 10 00 2a ec ......Устройства Bluetooth (личной сети) #3
 28...f2 18 81 00 b9 ba ......Remote NDIS based Internet Sharing Device #3
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0   192.168.42.129    192.168.42.93     10
        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.42.0    255.255.255.0         On-link     192.168.42.93    266
    192.168.42.93  255.255.255.255         On-link     192.168.42.93    266
   192.168.42.255  255.255.255.255         On-link     192.168.42.93    266
        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.42.93    266
  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.42.93    266
===========================================================================
Постоянные маршруты:
  Отсутствует

C:\>

(Нажмите, чтобы показать/скрыть)

Код: (text) [Выделить]

C:\>route print -4
===========================================================================
Список интерфейсов
 42...........................lan
 36...00 1b 10 00 2a ec ......Устройства Bluetooth (личной сети) #3
 28...f2 18 81 00 b9 ba ......Remote NDIS based Internet Sharing Device #3
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0   192.168.42.129    192.168.42.93     10
        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      192.168.0.1     192.168.0.44     11
     192.168.0.44  255.255.255.255         On-link      192.168.0.44    266
      192.168.1.0  255.255.255.224         On-link      192.168.0.44     11
     192.168.1.31  255.255.255.255         On-link      192.168.0.44    266
     192.168.42.0    255.255.255.0         On-link     192.168.42.93    266
    192.168.42.93  255.255.255.255         On-link     192.168.42.93    266
   192.168.42.255  255.255.255.255         On-link     192.168.42.93    266
   213.141.136.40  255.255.255.248         On-link      192.168.0.44     11
   213.141.136.41  255.255.255.255   192.168.42.129    192.168.42.93     11
   213.141.136.47  255.255.255.255         On-link      192.168.0.44    266
        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.42.93    266
        224.0.0.0        240.0.0.0         On-link      192.168.0.44    266
  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.42.93    266
  255.255.255.255  255.255.255.255         On-link      192.168.0.44    266
===========================================================================
Постоянные маршруты:
  Отсутствует

C:\>

Из этого понятно, что на сервер успешно отправлен, а на клиенте получен и обработан запрос DHCP/BOOTP c нужными маршрутами.
Так вот вопрос в следующем: при любых изменениях в структуре сети, удалённые Windows-клиенты прозрачно переходят на новые условия, а для удалённых клиентов на *nix, приходится ручками добавлять новые сети, если таковые могут появиться. Очень бы хотелось автоматизировать подобный механизм работы с ppp-туннелями в *nix.
======================================================================================================
                                ДЛЯ PPTP-клиента РЕШИЛ КОСТЫЛЁМ. Решение следующее:
======================================================================================================

(Нажмите, чтобы показать/скрыть)

В качестве dhcp-клиента использовал udhcpc из состава busybox.
Так как  запрос BOOTP после поднятия туннеля хостом с Windows имеет htype 8, был сделан фильтр в dhcpd, чтобы не отдавать в локалку лишние опции. Для того, чтобы udhcpc имел такой же htype, применил патч:

Код: (diff) [Выделить]

--- busybox-1.20.0.orig/networking/udhcp/packet.c       2012-04-22 05:33:23.000000000 +0400
+++ busybox-1.20.0/networking/udhcp/packet.c    2014-07-04 00:53:08.556867167 +0400
@@ -22,7 +22,7 @@
        case DHCPNAK:
                packet->op = BOOTREPLY; /* if server to client */
        }
-       packet->htype = 1; /* ethernet */
+       packet->htype = 8; /* ethernet */
        packet->hlen = 6;
        packet->cookie = htonl(DHCP_MAGIC);
        if (DHCP_END != 0)
Собрал только udhcpc из состава busybox. Поместил его в /etc/ppp.

(Нажмите, чтобы показать/скрыть)

Штатный udhcpc прекрасно работает и без патча, правда в этом случае пришлось добавить в конфигурацию DHCP сервера статический хост с нулями в MAC-адресе и роутингом, для того, чтобы не отдавать лишние опции хостам в сетях за PPTP-сервером.

В /etc/ppp/ip-up.d/ создал скрипт со следующим содержимым:

(Нажмите, чтобы показать/скрыть)

Скрипт написан с учётом патченного busybox'а, поэтому путь до штатного бинарника будет другим.

Код: (bash) [Выделить]

#!/bin/sh
# file /etc/ppp/ip-up.d/classles_routes

/etc/ppp/udhcpc \
        -qnBS \
        -t 6 \
        -i $PPP_IFACE \
        -C -O121 -O249 \
        -x lease:300 \
        -s /etc/ppp/default.script \
        -p /var/run/udhcpc.$PPP_IFACE.pid



В /etc/ppp поместил скрипт для udhcpc и привёл его к следующему виду:

(Нажмите, чтобы показать/скрыть)

Код: (bash) [Выделить]

#!/bin/bash
# file /etc/ppp/default.script
# depends: netmask

test -x $(which netmask) && NMASK=$(which netmask) || exit 0

case $1 in
    bound|renew)
        network=$($NMASK $ip/$subnet)
        [ -n "$staticroutes" ] && classes_route=$(echo "$staticroutes" | sed -e "s/$router//g")
        [ -n "$msstaticroutes" ] && classes_route=$(echo "$msstaticroutes" | sed -e "s/$router//g")
        [-n "$network" ]&& ip route add $network dev $interface
        if [ -n "$classes_route" ]; then
              for rt in $classes_route; do
                      ip route add $rt dev $interface
              done
        fi
        ;;

    *)
        exit 1
        ;;
esac

Такая конструкция позволила получить роуты через pptp-туннель и успешно внести их в таблицу удалённой машины.

(Нажмите, чтобы показать/скрыть)

До поднятия pptp:

Код: (text) [Выделить]

root@localhost:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.133.2   0.0.0.0         UG    0      0        0 eth0
192.168.133.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0После поднятия pptp

Код: (text) [Выделить]

root@localhost:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.133.2   0.0.0.0         UG    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ppp0
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.1.0     0.0.0.0         255.255.255.224 U     0      0        0 ppp0
192.168.133.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
213.141.136.40  0.0.0.0         255.255.255.248 U     0      0        0 ppp0
213.141.136.41  192.168.133.2   255.255.255.255 UGH   0      0        0 eth0
root@localhost:~#

То есть, добился того, чтобы запрос DHCP/BOOTP отправлялся и принимался в pptp-туннеле и получил механизм похожий на тот, который используется в windows.

Теперь что не нравиться в этой схеме:
- приходится отдавать адрес из 192.168.0.65 - 192.168.0.159 минимум на 5 минут.
Запрос от udhcpc на сервере выглядит сл. образом:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

tcpdump: listening on vlan6, link-type EN10MB (Ethernet), capture size 65535 bytes
01:24:37.912607 IP (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto UDP (17), length 307)
    192.168.0.42.68 > 255.255.255.255.67: BOOTP/DHCP, Request, length 279, htype 8, hlen 6, xid 0x75963b20, Flags [Broadcast]
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 9:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP, Classless-Static-Route
              Classless-Static-Route-Microsoft
            Vendor-Class Option 60, length 12: "udhcp 1.20.2"
            Lease-Time Option 51, length 4: 300
01:24:38.914248 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 337)
    192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 309, htype 8, hlen 6, xid 0x75963b20, Flags [Broadcast]
          Your-IP 192.168.0.82
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: 192.168.0.1
            Lease-Time Option 51, length 4: 300
            Subnet-Mask Option 1, length 4: 255.255.255.0
            Default-Gateway Option 3, length 4: 192.168.0.1
            Domain-Name-Server Option 6, length 4: 192.168.0.1
            Domain-Name Option 15, length 7: "132.lan"
            NTP Option 42, length 4: 192.168.1.1
            Classless-Static-Route-Microsoft Option 249, length 18: (213.141.136.40/29:192.168.0.1),(192.168.1.0/27:192.168.0.1)
01:24:38.916701 IP (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto UDP (17), length 319)
    192.168.0.42.68 > 255.255.255.255.67: BOOTP/DHCP, Request, length 291, htype 8, hlen 6, xid 0x75963b20, secs 1, Flags [Broadcast]
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Requested-IP Option 50, length 4: 192.168.0.82
            Server-ID Option 54, length 4: 192.168.0.1
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 9:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP, Classless-Static-Route
              Classless-Static-Route-Microsoft
            Vendor-Class Option 60, length 12: "udhcp 1.20.2"
            Lease-Time Option 51, length 4: 300
01:24:38.942471 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 337)
    192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 309, htype 8, hlen 6, xid 0x75963b20, secs 1, Flags [Broadcast]
          Your-IP 192.168.0.82
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 192.168.0.1
            Lease-Time Option 51, length 4: 300
            Subnet-Mask Option 1, length 4: 255.255.255.0
            Default-Gateway Option 3, length 4: 192.168.0.1
            Domain-Name-Server Option 6, length 4: 192.168.0.1
            Domain-Name Option 15, length 7: "132.lan"
            NTP Option 42, length 4: 192.168.1.1
            Classless-Static-Route-Microsoft Option 249, length 18: (213.141.136.40/29:192.168.0.1),(192.168.1.0/27:192.168.0.1)

По option 53 запрос приходит с флагом Discover, тогда как в ms - Inform. Вероятнее всего эту причину мне не исправить, что в общем, пока не выглядит критично.

[AnrDaemon]

Получения или передачи?
Посмотрите в сторону accel-ppp, может, там это реализовано.

[koshev]

Получения конечно. Первый пост дополнил.

[AnrDaemon]

Тогда ничем не могу помочь. Просто не знаю. Извините.

[koshev]

Извиняться не за что, беглый поиск по Интернетам надежды не внушил.
РЕШЕНО КОСТЫЛЁМ. Решение в первом посте треда.
Тему не закрываю, буду искать решение.

[AnrDaemon]

Стоп-стоп-стоп.
Если я правильно понимаю, bcrelay и proxyarp - едва ли не взаимоисключающие режимы настройки тоннеля.
Я не прав?

[koshev]

Я тоже так думал. Моя практика правда не совсем с этим согласна.
При отключенном proxyarp локальные хосты в сети 192.168/24 не видят удалённых и наоборот, если не задействовать bcrelay - не проходят broadcast и соответственно не отдаётся маршрутизация удалённым.

[AnrDaemon]

При отключенном proxyarp локальные хосты в сети 192.168/24 не видят удалённых

Эээ... чё? С какого перепугу у вас одна подсеть по обе стороны тоннеля?
Работать не будет. Именем Гуся. (c)

[koshev]

Эээ... чё? С какого перепугу у вас одна подсеть по обе стороны тоннеля?
Работать не будет. Именем Гуся. (c)

В чём проблема?
Именно одна по обе стороны и работает черт знает сколько времени.

[AnrDaemon]

Что-то по вашему топику этого не особо заметно.

[koshev]

Когда говорил про сеть 192.168/24 имел ввиду сеть 192.168/24 и как видятся в ней удалённые по pptp. Нужно было уточнить.