Реализация rfc3442 (бесклассовый статический маршрут) на DHCP-сервере Freeradius

Я пытаюсь настроить сервер Strongswan, который работает в режиме разделенного туннеля, что означает, что я должен отключить использование сервера в качестве шлюза по умолчанию на стороне клиента, а также отключить классовую маршрутизацию в VPN-клиенте.

тогда я должен отправить DHCP-опция 121 (бесклассовый статический маршрут) и DHCP-опция 249 (Вариант Microsoft бесклассового статического маршрута), когда клиент запрашивает IP-адрес с VPN-сервера Strongswan.

Мне нужны обе опции 121 и 249, чтобы учитывать все комбинации операционных систем, которые могут подключаться (Windows, Linux, Android, MacOS, iPhone и т. д.).

У меня не было большого успеха в использовании DHCP-сервера ISC с Strongswan, так как он не был в восторге от прослушивания трафика через интерфейс WireGuard.В нем говорилось, что он не поддерживает интерфейс WireGuard или loopback и в основном игнорировал запросы DHCP, поступающие от VPN-сервера Strongswan на другой стороне канала wireguard.

Поэтому я переключился на DHCP-сервер Freeradius, поскольку Strongswan уже использовал Freeradius для аутентификации пользователей при входе на VPN-сервер Strongswan.

В конце концов: насколько это сложно, ведь я как раз собирался добавить «несколько конфигурационных файлов во Freeradius»? :-)

Оказывается, это немного сложно, но мне удалось заставить Freeradius прослушивать трафик по моей ссылке Wireguard, используя следующую конфигурацию:

Слушать {
        тип = DHCP
        # Подсеть 192.168.200.0/24 — это моя подсеть WireGuard, которая действует как 
        # Магистральная сеть VPN между сайтами.

        IP-адрес = 192.168.200.4
        src_ipaddr = 192.168.200.4
        порт = 67
        интерфейс = WG0
        трансляция = нет
}

В моем файле strongswan.conf у меня есть следующее:

харон {
  load_modular = да
  плагины {
    включить strongswan.d/charon/*.conf

    DHCP {
        force_server_address = да
        identity_lease = да
        интерфейс = WG0
        нагрузка = да
        сервер = 192.168.200.4
        use_server_port = да
    }
  }
}

Во всяком случае: я заставил DHCP-сервер Freeradius раздавать IP-адреса VPN-клиенту, когда Strongswan отправляет DHCP-Discover или DHCP-Request на DHCP-сервер Freeradius, но почему-то я не могу заставить его отправлять статические маршруты?

я вижу в файле Словарь который находится в /etc/свободный радиус/3.0 что словарь для конкретных параметров dhcp загружается из /usr/доля/freeradius/словарь.dhcp.

В этом файле я могу найти две следующие информации:

# Вариант бесклассового статического маршрута
АТРИБУТ DHCP-Classless-Static-Route 121 октетов

...

АТРИБУТ DHCP-Site-specific-25 249 октетов

Согласно с Создать вики Я могу установить шлюз следующего перехода для моего статического маршрута на 0.0.0.0, так что если я хочу сказать, что подсеть 192.168.200.0/24 доступен через VPN-ссылку. Мне нужно закодировать маршрут в виде октетов, записанных в виде шестнадцатеричного кода, используя порядок: {CIDR}{Network}{Gateway}.

Так 192.168.200.0/24 через 0.0.0.0 становится 0x18C0A8C800000000

Поэтому я подумал, что я должен просто изменить обновить ответ в dhcp DHCP-обнаружение и dhcp DHCP-запрос к следующему:

обновить ответ {
    & DHCP-сервер доменных имен = 192.168.200.1
    & DHCP-маска подсети = 255.255.255.0
    & DHCP-IP-адрес-Lease-Time = 86400
    &DHCP-бесклассовый-статический-маршрут = 0x18C0A8C800000000
    & DHCP-сайт-специфический-25 = 0x18C0A8C800000000
    & DHCP-идентификатор DHCP-сервера = 192.168.200.4
}

Однако я не вижу, что маршрут проталкивается в мою таблицу маршрутизации, когда я пытаюсь войти в систему через клиент Windows VPN.

Итак, что мне не хватает?

Обновлять

Оказывается, кодировка DHCP-опции 249 немного отличается от DHCP-опции 121.

По крайней мере, согласно Веб-страница Microsoft для параметра DHCP 249.

Однако я немного запутался в том, как это переводится в кодирование в Freeradius.

Насколько я могу судить, я уже говорил, что заголовок начинается с DHCP-опции 249, так как DHCP-сайт-специфический-25 определяется в словаре.

Но на веб-странице Microsoft говорится, что первый байт после этого — это длина всех маршрутов в DHCP, измеренная в байтах, за которой следует та же кодировка для маршрутов, которая определена в опции DHCP 121.

Таким образом, закодированный маршрут 0x18C0A8C800000000 должен предваряться 08, поэтому строка со статическими маршрутами Microsoft теперь выглядит так:

& DHCP-сайт-специфический-25 = 0x0818C0A8C800000000

Я тестировал эту модификацию, но все равно не повезло.

Второе обновление

Еще немного возни с конфигурационным файлом для DHCP и затем мониторинг через tcpdump о том, что происходит на самом деле.

Всякий раз, когда клиент входит в Strongswan, запрос IP-адреса перенаправляется на сервер DCHP, поэтому, по сути, Strongswan действует как агент ретрансляции DHCP, если я правильно понял эту часть.

В tcpdump я вижу следующий обмен:

Клиент отправляет DHCP Discover Сервер отвечает предложением DHCP Клиент отправляет DHCP-запрос Сервер отвечает DHCP ACK

Мой первый вывод из мониторинга tcpdump заключается в том, что мне не нужно вычислять длину в байтах для закодированного статического маршрута, потому что это искажает вывод tcpdump.

Другими словами, кодирование для параметра DHCP 121 и параметра DHCP 249. та же.

Дальнейшее чтение предполагает, что статическая маршрутизация связана с информацией DHCP, но я никогда не видел этот пакет в tcpdump.

Вывод tcpdump при запуске с моей начальной конфигурацией обновить ответ выше дает следующий сеанс:

tcpdump: прослушивание на wg0, тип ссылки RAW (Raw IP), размер захвата 262144 байт

10:58:17.185671 IP (tos 0x0, ttl 64, id 46089, смещение 0, флаги [нет], proto UDP (17), длина 300)
    192.168.200.1.67 > 192.168.200.4.67: [udp sum ok] BOOTP/DHCP, запрос от 7a:a7:8f:1f:b7:88, длина 272, xid 0x5c9716b5, флаги [нет] (0x0000)
          Шлюз-IP 192.168.200.1
          Клиент-Ethernet-адрес 7a:a7:8f:1f:b7:88
          Расширения Vendor-rfc1048
            Волшебное печенье 0x63825363
            DHCP-сообщение, опция 53, длина 1: обнаружение
            Client-ID Option 61, длина 22: аппаратный тип 108, 61:73:73:65:40:68:6f:6d:65:2e:6d:6f:6c:67:61:61:72:64: 2е:65:75
            Опция запроса параметров 55, длина 2:
              Сервер доменных имен, Netbios-Name-Server
            КОНЕЦ Опция 255, длина 0

10:58:17.195305 IP (tos 0x0, ttl 64, id 19475, смещение 0, флаги [нет], proto UDP (17), длина 328)
    192.168.200.4.67 > 192.168.200.1.67: [плохая udp cksum 0x129d -> 0x9ffd!] BOOTP/DHCP, ответ, длина 300, xid 0x5c9716b5, флаги [нет] (0x0000)
          Ваш-IP 192.168.201.13
          Шлюз-IP 192.168.200.1
          Клиент-Ethernet-адрес 7a:a7:8f:1f:b7:88
          Расширения Vendor-rfc1048
            Волшебное печенье 0x63825363
            DHCP-сообщение, опция 53, длина 1: предложение
            Маска подсети Вариант 1, длина 4: 255.255.255.0
            Вариант 6 сервера доменных имен, длина 4: 192.168.200.1
            Опция аренды 51, длина 4: 86400
            Параметр идентификатора сервера 54, длина 4: 192.168.200.4
            Бесклассовый статический маршрут, опция 121, длина 8: (192.168.200.0/24:0.0.0.0)
            Classless-Static-Route-Microsoft Option 249, длина 8: (192.168.200.0/24:0.0.0.0)
            КОНЕЦ Опция 255, длина 0
            PAD Option 0, длина 0, встречается 12

10:58:17.219444 IP (tos 0x0, ttl 64, id 46098, смещение 0, флаги [нет], proto UDP (17), длина 312)
    192.168.200.1.67 > 192.168.200.4.67: [udp sum ok] BOOTP/DHCP, запрос от 7a:a7:8f:1f:b7:88, длина 284, xid 0x5c9716b5, флаги [нет] (0x0000)
          Шлюз-IP 192.168.200.1
          Клиент-Ethernet-адрес 7a:a7:8f:1f:b7:88
          Расширения Vendor-rfc1048
            Волшебное печенье 0x63825363
            DHCP-сообщение, опция 53, длина 1: запрос
            Client-ID Option 61, длина 22: аппаратный тип 108, 61:73:73:65:40:68:6f:6d:65:2e:6d:6f:6c:67:61:61:72:64: 2е:65:75
            Запрошенный IP-опция 50, длина 4: 192.168.201.13
            Параметр идентификатора сервера 54, длина 4: 192.168.200.4
            Опция запроса параметров 55, длина 2:
              Сервер доменных имен, Netbios-Name-Server
            КОНЕЦ Опция 255, длина 0

10:58:17.228663 IP (tos 0x0, ttl 64, id 19477, смещение 0, флаги [нет], proto UDP (17), длина 328)
    192.168.200.4.67 > 192.168.200.1.67: [плохая udp cksum 0x129d -> 0x9d02!] BOOTP/DHCP, ответ, длина 300, xid 0x5c9716b5, флаги [нет] (0x0000)
          Ваш-IP 192.168.201.8
          Шлюз-IP 192.168.200.1
          Клиент-Ethernet-адрес 7a:a7:8f:1f:b7:88
          Расширения Vendor-rfc1048
            Волшебное печенье 0x63825363
            DHCP-сообщение, опция 53, длина 1: ACK
            Маска подсети Вариант 1, длина 4: 255.255.255.0
            Вариант 6 сервера доменных имен, длина 4: 192.168.200.1
            Опция аренды 51, длина 4: 86400
            Параметр идентификатора сервера 54, длина 4: 192.168.200.4
            Бесклассовый статический маршрут, опция 121, длина 8: (192.168.200.0/24:0.0.0.0)
            Classless-Static-Route-Microsoft Option 249, длина 8: (192.168.200.0/24:0.0.0.0)
            КОНЕЦ Опция 255, длина 0
            PAD Option 0, длина 0, встречается 12

Тот факт, что я вижу Бесклассовый статический маршрут и Бесклассовый-Статический-Маршрут-Майкрософт объявляются, и они действительно говорят, что подсеть 192.168.200.0/24 доступен через туннель, дает мне намек, что я на правильном пути.

Однако:

Маршрут по-прежнему не отображается в моей таблице маршрутизации.

Возможно, это как-то связано со следующей строкой:

192.168.200.4.67 > 192.168.200.1.67: [плохая udp cksum 0x129d -> 0x9ffd!] BOOTP/DHCP, ответ, длина 300, xid 0x5c9716b5, флаги [нет] (0x0000)

Кто-нибудь знает, что нужно исправить?