The OpenNET Project / Index page

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



"DHCP не отдает static-routes клиентам vpn"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (DHCP / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"DHCP не отдает static-routes клиентам vpn"  +/
Сообщение от Аноним (0), 27-Апр-21, 09:15 
имеется работающий сервер softether + ISC-DHCP для раздачи адресов и маршрутов клиентам.
Сервер с двумя сетевыми + tap-интерфейс softether:
# ifconfig
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        ether 08:02:ef:29:a6:94
        inet xx.xx.xx.xx netmask 0xffffff00 broadcast xx.xx.xx.xx
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
bge1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c0099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE>
        ether 08:02:ef:29:a6:95
        inet 10.0.9.3 netmask 0xff000000 broadcast 10.255.255.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 0a:94:ef:29:e6:9b
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33160
        groups: pflog
tap_vpn: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        ether 5e:ac:ef:ce:9b:60
        hwaddr 58:96:fc:10:11:09
        inet 172.16.0.1 netmask 0xffff0000 broadcast 172.16.255.255
        groups: tap
        media: Ethernet autoselect
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 1281

DHCP сконфигурирован следующим образом:

# less /etc/rc.conf| grep dhcp
dhcpd_enable="YES"
dhcpd_flags="-4"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_ifaces="tap_vpn bge1"

# less /usr/local/etc/dhcpd.conf
ddns-update-style none;
log-facility local7;

option ms-static-routes code 249 = array of unsigned integer 8;
option rfc-static-routes code 121 = array of unsigned integer 8;

subnet 172.16.0.0 netmask 255.255.0.0 {
  authoritative;
  range 172.16.0.10 172.16.255.254;
  option domain-name-servers 10.0.1.2, 10.0.1.4;
  option netbios-node-type 8;
  option routers 172.16.0.1;
  option broadcast-address 172.16.255.255;
  option ms-static-routes 8,10, 172,16,0,1, 24,192,168,30, 172,16,0,1;
  option rfc-static-routes 8,10, 172,16,0,1, 24,192,168,30, 172,16,0,1;
  default-lease-time 600;
  max-lease-time 7200;
}

Это работает, клиент по vpn подключается, получает адрес из сети 172.16.0.0 и маршруты для 10.0.0.0/8 и 192.168.30.0/24:

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.216   4250
          0.0.0.0          0.0.0.0         On-link       172.16.0.20     26
         10.0.0.0        255.0.0.0         On-link       172.16.0.20     26
   10.255.255.255  255.255.255.255         On-link       172.16.0.20    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1   4556
        127.0.0.1  255.255.255.255         On-link         127.0.0.1   4556
  127.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
       172.16.0.0      255.255.0.0         On-link       172.16.0.20     26
      172.16.0.20  255.255.255.255         On-link       172.16.0.20    281
   172.16.255.255  255.255.255.255         On-link       172.16.0.20    281
      192.168.1.0    255.255.255.0         On-link     192.168.1.216   4506
    192.168.1.216  255.255.255.255         On-link     192.168.1.216   4506
    192.168.1.255  255.255.255.255         On-link     192.168.1.216   4506
     192.168.30.0    255.255.255.0         On-link       172.16.0.20     26
   192.168.30.255  255.255.255.255         On-link       172.16.0.20    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1   4556
        224.0.0.0        240.0.0.0         On-link     192.168.1.216   4506
        224.0.0.0        240.0.0.0         On-link       172.16.0.20     26
  255.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
  255.255.255.255  255.255.255.255         On-link     192.168.1.216   4506
  255.255.255.255  255.255.255.255         On-link       172.16.0.20    281
===========================================================================

Но с недавних пор группа товарищей кровь из носу захотела получать адреса непременно из внутренней сети 10.0.9.х. Дописал в конфиг dhcp subnet по аналогии

subnet 10.0.9.0 netmask 255.255.255.0 {
  authoritative;
  range 10.0.9.240 10.0.9.254;
  option domain-name-servers 10.0.1.2, 10.0.1.4;
  option netbios-node-type 8;
  option routers 10.0.9.1;
  option broadcast-address 10.0.9.255;
  option ms-static-routes  24,192,168,30, 10,0,9,1;
  option rfc-static-routes 24,192,168,30, 10,0,9,1;
  default-lease-time 600;
  max-lease-time 7200;
}

В softether, соответственно, добавил второй бридж к внутренней сетевой карте bge1

VPN Server/HUB0-LOCAL>BridgeList
BridgeList command - Get List of Local Bridge Connection
Number|Virtual Hub Name|Network Adapter or Tap Device Name|Status
------+----------------+----------------------------------+---------
1     |HUB0            |vpn                               |Operating
2     |HUB0-LOCAL      |bge1                              |Operating
The command completed successfully.

Клиент подключается, получает адрес из подсети 10.0.9.х, а вот маршрут к закрытой сетке 192.168.30.0/24 - почему-то не хочет передаваться:

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.216   4250
          0.0.0.0          0.0.0.0         On-link        10.0.9.250     26
       10.0.9.250  255.255.255.255         On-link        10.0.9.250    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1   4556
        127.0.0.1  255.255.255.255         On-link         127.0.0.1   4556
  127.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
      192.168.1.0    255.255.255.0         On-link     192.168.1.216   4506
    192.168.1.216  255.255.255.255         On-link     192.168.1.216   4506
    192.168.1.255  255.255.255.255         On-link     192.168.1.216   4506
        224.0.0.0        240.0.0.0         On-link         127.0.0.1   4556
        224.0.0.0        240.0.0.0         On-link     192.168.1.216   4506
        224.0.0.0        240.0.0.0         On-link        10.0.9.250     26
  255.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
  255.255.255.255  255.255.255.255         On-link     192.168.1.216   4506
  255.255.255.255  255.255.255.255         On-link        10.0.9.250    281
===========================================================================

Пока вышли из положения прописыванием маршрута на клиенте вручную.
Но вопрос "почему так" и "что делать" - остался. Почему в одном случае маршруты отсылаются клиенту, а в другом - нет? И как это поправить?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от pavel_simple. (?), 28-Апр-21, 16:19   +/
>[оверквотинг удален]
>   255.255.255.255  255.255.255.255        
>  On-link     192.168.1.216   4506
>   255.255.255.255  255.255.255.255        
>  On-link        10.0.9.250  
>   281
> ===========================================================================
> Пока вышли из положения прописыванием маршрута на клиенте вручную.
> Но вопрос "почему так" и "что делать" - остался. Почему в одном
> случае маршруты отсылаются клиенту, а в другом - нет? И как
> это поправить?

выкинуть ICS и поставить dnsmasq

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от Аноним (0), 28-Апр-21, 18:42   +/
> выкинуть ICS и поставить dnsmasq

Уважаемый, а чем ваш совет поможет, если у меня, скажем, в файрволе какой-то косяк?
Нет, дело не в нем, но раз уж у нас ваш бесполезный ответ, то у меня к вам встречный бесполезный вопрос.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Алдр Бов (?), 29-Апр-21, 13:14   –1 +/
> Это работает, клиент по vpn подключается, получает адрес из сети 172.16.0.0 и маршруты для 10.0.0.0/8 и 192.168.30.0/24:

ВПН? При чём тут dhcp? Информацию о маршрутах клиенту впн обычно передаёт впн-сервер. Из тех, что мне известны. Не исключаю, что есть какие-то ещё реализации впн, которые пользуются для настроек клиента dhcp-сервером, но я с такими пока не работал.

Вас, кстати, совсем не смущает разница в настройках dhcpd и получаемыми клиентом? Меня - сильно. Что-то вы нам не договариваете или сами сильно не понимаете.

>  option routers 10.0.9.1;
>          0.0.0.0          0.0.0.0         On-link       172.16.0.20     26
>         10.0.0.0        255.0.0.0         On-link       172.16.0.20     26

                                                                    ^^^^^^^^^^^^^^^^^^^^^
Здесь глаз совсем ни за что не цепляется?

>   range 10.0.9.240 10.0.9.254;
>   option domain-name-servers 10.0.1.2, 10.0.1.4;
>   option netbios-node-type 8;
>   option routers 10.0.9.1;
>   option broadcast-address 10.0.9.255;
>   option ms-static-routes  24,192,168,30, 10,0,9,1;
>   option rfc-static-routes 24,192,168,30, 10,0,9,1;
>   default-lease-time 600;
>   max-lease-time 7200;
> }

Может, я чего-то не понимаю, но какой смысл прописывать клиентам отдельный маршрут на defaultgw? Клиенты - M$? Если да - у них своя особая логика и маршрут, поглощаемый основным вполне может отбрасываться. Но!...

Во втором диапазоне тоже есть очень странные расхождения:
>  option routers 10.0.9.1;
>          0.0.0.0          0.0.0.0         On-link        10.0.9.250     26

Очень похоже, что Вы пользуете openvpn, но тогда и настройки надо ковырять не в несчастном dhcpd, а в впн-сервере. "Мухи - отдельно, котлеты - отдельно" - не надо всё смешивать в одну кучу.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

4. Сообщение от Аноним (4), 29-Апр-21, 13:36   +/
>> Это работает, клиент по vpn подключается, получает адрес из сети 172.16.0.0 и маршруты для 10.0.0.0/8 и 192.168.30.0/24:
> ВПН? При чём тут dhcp? Информацию о маршрутах клиенту впн обычно передаёт
> впн-сервер. Из тех, что мне известны.

Стало быть, известно вам мало. Точнее, только openvpn. Ну-ка, с ходу - нарисуйте мне конфигурацию mpd5 или wireguard с передачей маршрутов клиенту...

> Вас, кстати, совсем не смущает разница в настройках dhcpd и получаемыми клиентом?
> Меня - сильно. Что-то вы нам не договариваете или сами сильно не понимаете.

Нисколько не смущает. Непонимание происходящего, кажется, имеет место на вашей стороне. Осознайте, что vpn представляет собой point-to-point connection, для которого существуют только клиент и сервер. После этого смущения и непонимания должны исчезнуть.

> Может, я чего-то не понимаю, но какой смысл прописывать клиентам отдельный маршрут
> на defaultgw? Клиенты - M$? Если да - у них своя
> особая логика и маршрут, поглощаемый основным вполне может отбрасываться. Но!...

Дичь какая. Извините.

> Очень похоже, что Вы пользуете openvpn,

Очень похоже, что вы читаете через строку. Иначе не строили бы предположений, а знали, что в качестве vpn-сервера выступает softether.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #5

5. Сообщение от Алдр Бов (?), 29-Апр-21, 15:23   –1 +/
>>> Это работает, клиент по vpn подключается, получает адрес из сети 172.16.0.0 и маршруты для 10.0.0.0/8 и 192.168.30.0/24:
>> ВПН? При чём тут dhcp? Информацию о маршрутах клиенту впн обычно передаёт
>> впн-сервер. Из тех, что мне известны.
> Стало быть, известно вам мало.

Не исключаю.

> Точнее, только openvpn.

Тут уже Вы вступили на зыбкую почву предположений.

> Ну-ка, с ходу - нарисуйте мне конфигурацию mpd5 или wireguard с передачей маршрутов клиенту...

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

>> Вас, кстати, совсем не смущает разница в настройках dhcpd и получаемыми клиентом?
>> Меня - сильно. Что-то вы нам не договариваете или сами сильно не понимаете.
> Нисколько не смущает.

Печально. Когда на сервере выдаётся в качестве маршрута адрес 0.1, а у клиента вместо этого - 0.20 - любая логика происходящего ломается напрочь. Объяснение одно - isc-dhcpd не имеет к маршрутизации у клиента никакого отношения.

> Непонимание происходящего, кажется, имеет место на вашей стороне.

Да, абсолютно. Я ж Вашей сети не знаю. Извините, что попытался помочь разобраться.

> Осознайте, что vpn представляет собой point-to-point connection, для которого существуют
> только клиент и сервер. После этого смущения и непонимания должны исчезнуть.

Такой костыль, как маршрут (по умолчанию), направленный на отображение локального адреса я пока встречал только в openvpn. Помню бурную дискуссию в конференциях лет ... (много) назад с разработчиками на эту тему, которая закончилась словами "ну вот так вот нам было проще сделать". В том же mpd, насколько мне помнится, маршрут указывает на противоположный конец туннеля.

>> Может, я чего-то не понимаю, но какой смысл прописывать клиентам отдельный маршрут
>> на defaultgw? Клиенты - M$? Если да - у них своя особая логика и маршрут,
>> поглощаемый основным вполне может отбрасываться. Но!...
> Дичь какая. Извините.

Увы, от M$, из опыта, приходится ожидать совершенно нелогичного поведения. И когда-то я с чем-то таким уже сталкивался.

>> Очень похоже, что Вы пользуете openvpn,
> Очень похоже, что вы читаете через строку. Иначе не строили бы предположений,
> а знали, что в качестве vpn-сервера выступает softether.

Не пробовал, что это такое, поэтому ещё раз прошу прощения, что влез со своими предположениями. Сейчас вот заглянул почитать, что это: "строит L2 и L3 туннели, имеет встроенный DHCP-сервер, поддерживает...". Так что isc-dhcpd, как я и пытался Вам донести, в Вашем случае совершенно не причём. Пошёл читать дальше....

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #7

6. Сообщение от fantom (??), 29-Апр-21, 15:38   +/
>[оверквотинг удален]
>   255.255.255.255  255.255.255.255        
>  On-link     192.168.1.216   4506
>   255.255.255.255  255.255.255.255        
>  On-link        10.0.9.250  
>   281
> ===========================================================================
> Пока вышли из положения прописыванием маршрута на клиенте вручную.
> Но вопрос "почему так" и "что делать" - остался. Почему в одном
> случае маршруты отсылаются клиенту, а в другом - нет? И как
> это поправить?

1. На клиенте wireshark-ок слушаете интерфейс и смотрите содержимое пакета -- есть ваши опции или нет.
2. Логи никто не отменял.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8

7. Сообщение от Аноним (4), 29-Апр-21, 15:41   +/
Спасибо за желание помочь, но извините - вы несете полную чушь. По всем пунктам.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Аноним (4), 29-Апр-21, 15:47   +/
> 1. На клиенте wireshark-ок слушаете интерфейс и смотрите содержимое пакета -- есть
> ваши опции или нет.

Смотрели. В том и дело, что нет ничего, будто бы сервер вообще их не отправляет.

> 2. Логи никто не отменял.

Спасибо, я грамотный, было бы хоть что-то наводящее на подозрение - сообщил бы.

В итоге развернули рядом на скорую руку еще один сервер, скопировали на него конфигурации файрвола, dhcp и softether  - все заработало как из пушки. Разумных объяснений у меня нет, разве что комбинация глюков, накопившихся в ходе обновлений и апгрейдов сервера с 2012 года привела к столь странному результату. Будем переустанавливать систему с нуля.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #9

9. Сообщение от Аноним (9), 08-Май-21, 08:59   +/
> 2. Логи никто не отменял.
> Спасибо, я грамотный, было бы хоть что-то наводящее на подозрение - сообщил бы.

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

А раз вопрос есть, адресован Вами к другим, то - логи для тех глаз, которые увидят в них ответ. Ибо самостоятельно не сошлось уже.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от Аноним (9), 08-Май-21, 09:00   +/
Т.е. больше слушать, меньше делать выводов. :)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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