Решено: dhcpd для dhcp-relay

Обсуждение настройки и работы сервисов, резервирования, сетевых настроек и вопросов безопасности ОС.

Модераторы: SLEDopit, Модераторы разделов

Аватара пользователя
Olden Gremlin
Сообщения: 365
Статус: RAP22-RIPE
ОС: Debian GNU/Linux Wheezy

Решено: dhcpd для dhcp-relay

Сообщение Olden Gremlin »

В общем суть вопроса вот в чём.
Есть AccessPoint на котором клиенты авторизуются в WPA2 через EAP-TLS. На этом этапе всё хорошо. Плохо становится когда хочется отдать клиенту ip-адрес по DHCP. Почему плохо?
Сеть большая, транспортное кольцо построено на третьем уровне + MPLS. Есть "тазик" на котором подняты некоторые сервисы, при этом именно на нём и нужно поднять DHCP-сервер.
В самом упрощённом варианте приведу, куски конфигурации маршрутизаторов. Есть Cisco 7206:

Код: Выделить всё

interface GigabitEthernet0/1.654
 description WIFI
 encapsulation dot1Q 654
 xconnect xxx.xxx.120.68 654 encapsulation mpls
end
Собственно AP стоит чуточку дальше, но непосредственно к ней подводится vlan и это не особо интересно.
С киски транспорт поднялся нормально:

Код: Выделить всё

#sh mpls l2transport vc 654

Local intf     Local circuit              Dest address    VC ID      Status
-------------  -------------------------- --------------- ---------- ----------
Gi0/1.654      Eth VLAN 654              xxx.xxx.120.68   654        UP
Принимающая транспорт сторона это Juniper mx80-t. Принимается этот транспорт в vpls-инстанс, принимается нормально. Конфигурация инстанса:

Код: Выделить всё

> show configuration routing-instances WiFi_Clients
instance-type vpls;
vlan-id 654;
interface ge-1/0/2.654;
interface ae0.654;
routing-interface irb.654;
protocols {
    vpls {
        no-tunnel-services;
        mtu 2000;
        mesh-group WiFi_AP_l2ccc {
            vpls-id 654;
            local-switching;
            neighbor xxx.xx.171.201 {
                encapsulation-type ethernet-vlan;
            }
        }
    }
}

Код: Выделить всё

> show configuration interfaces ge-1/0/2.654
encapsulation vlan-vpls;
vlan-id 654;
family vpls;

Код: Выделить всё

> show configuration interfaces irb.654
family inet {
    address 10.254.207.29/30;
    address xx.xxx.127.129/28;
}
Статус:

Код: Выделить всё

> show vpls connections brief instance WiFi_Clients
Layer-2 VPN connections:
...
Instance: WiFi_Clients
  Mesh-group connections: WiFi_AP_l2ccc
    Neighbor                  Type  St     Time last up          # Up trans
    xxx.xx.171.201(vpls-id 654) rmt Up     Dec 29 10:15:42 2012           1

Всё работает, именно через этот транспортный канал происходит обращение с AP к FreeRADIUS-у для EAP-TLS запросов. Но в бочке мёда не без ложки дёгтя.
Всё прекрасно работает когда ip-адрес на конечном оборудовании задаётся из сети xx.xxx.127.128/28 вручную, но всё становится очень плохо если попытаться получить адрес у DHCP-сервера. (Сразу замечу, что принять на сервере vlan 654 нет возможности)
Тут вплотную приблизились к самой сути проблемы. Конфигурация DHCP-сервера, проще некуда, но она не работает:

Код: Выделить всё

shared-network WIFI {
    subnet xx.xxx.127.128 netmask 255.255.255.240 {
        pool {
            range xx.xxx.127.130 xx.xxx.127.142;
            option routers 94.125.127.129;
        }
#       host TestHP { hardware ethernet 00:0e:35:9b:68:f9; fixed-address xx.xxx.127.130; } <-- так тоже не работает, даже если вынести за пределы shared-network
    }
}
На mx80 настраивается helper bootp:

Код: Выделить всё

> show configuration forwarding-options helpers bootp interface irb.654
server xxx.xx.160.7;
maximum-hop-count 8;
dhcp-option82 {
    circuit-id {
        use-vlan-id;
    }
    remote-id {
        prefix mac;
    }
    vendor-id;
}
Да, запросы начинают транслироваться на сервер xxx.xx.160.7, но толку от этого мало:

Код: Выделить всё

Dec 29 11:42:03 ns dhcpd: DHCPDISCOVER from 00:0e:35:9b:68:f9 via 10.254.207.29: unknown network segment
Dec 29 11:42:39 ns dhcpd: DHCPDISCOVER from 00:0e:35:9b:68:f9 via 10.254.207.29: unknown network segment
Dec 29 11:42:44 ns dhcpd: DHCPDISCOVER from 00:0e:35:9b:68:f9 via 10.254.207.29: unknown network segment
Dec 29 11:42:52 ns dhcpd: DHCPDISCOVER from 00:0e:35:9b:68:f9 via 10.254.207.29: unknown network segment
Dec 29 11:43:08 ns dhcpd: DHCPDISCOVER from 00:0e:35:9b:68:f9 via 10.254.207.29: unknown network segment

Если на mx80 в forwarding-options helpers bootp поменять роут-интерфейс irb.654 на ge-1/0/2.654 то толку ещё меньше - запросов вообще нет.
Попытка выцепить agent.circuit-id ни к чему не приводит, так как agent.circuit-id просто нет в запросе :(
Итоговая суть вопроса формулируется просто: как избавиться от "unknown network segment" и отдать таки адрес на конечное оборудование?

«Когда у общества нет цветовой дифференциации штанов — то нет цели!»
nic-hdl: RAP22-RIPE
Спасибо сказали:
Аватара пользователя
Bluetooth
Сообщения: 4395
Статус: Блюзовый
ОС: Debian Squeeze amd64

Re: Решено: dhcpd для dhcp-relay

Сообщение Bluetooth »

Спасибо сказали:
Аватара пользователя
Olden Gremlin
Сообщения: 365
Статус: RAP22-RIPE
ОС: Debian GNU/Linux Wheezy

Re: Решено: dhcpd для dhcp-relay

Сообщение Olden Gremlin »

Конечно-же, уважаемый Bluetooth, dhcp был собран с USE_SOCKETS и затем именно эта версия установлена.

Ещё идеи и мысли есть?
«Когда у общества нет цветовой дифференциации штанов — то нет цели!»
nic-hdl: RAP22-RIPE
Спасибо сказали:
Аватара пользователя
Bluetooth
Сообщения: 4395
Статус: Блюзовый
ОС: Debian Squeeze amd64

Re: Решено: dhcpd для dhcp-relay

Сообщение Bluetooth »

Ещё идеи и мысли есть?
Ну, насколько я понимаю, dhcpd неправильно настроен.
subnet должен быть с адресом сети, в которую смотрит dhcpd, но пустой.
В общем, посмотрите повнимательнее секцию "настройка dhpcd" по ссылке.
Спасибо сказали:
Аватара пользователя
Olden Gremlin
Сообщения: 365
Статус: RAP22-RIPE
ОС: Debian GNU/Linux Wheezy

Re: Решено: dhcpd для dhcp-relay

Сообщение Olden Gremlin »

Bluetooth писал(а):
03.01.2013 15:34
Ещё идеи и мысли есть?
Ну, насколько я понимаю, dhcpd неправильно настроен.
subnet должен быть с адресом сети, в которую смотрит dhcpd, но пустой.
В общем, посмотрите повнимательнее секцию "настройка dhpcd" по ссылке.
Бог мой, мне бы Вашу самоуверенность, уважаемый Bluetooth. ;)

Всё оказалось куда как проще и прозаичней. Просто в предновогодней запарке совершенно было выпущено из виду, что в построенной схеме option 82 не работает и circuit-id не передаётся. Отсюда невозможность построить класс, со всеми вытекающими последствиями.

Так что решение прозаично и совсем неинтересно. В конфигурации dhcp просто описывается подсеть в которой формируются запросы.

Код: Выделить всё

subnet xx.xxx.127.128 netmask 255.255.255.240 {
    pool {
        range xx.xxx.127.130 xx.xxx.127.142;
        option broadcast-address xx.xxx.127.143;
        option routers xx.xxx.127.129;
    }
}
В принципе диапазона /28 (13 клиентских хостов) под одну точку доступа вполне достаточно.

Что-же касается Juniper-а то там тоже произошли изменения в секции описания irb-интерфейса и в forwarding-options:

Код: Выделить всё

> show configuration interfaces irb.654
family inet {
    address 10.254.207.29/30;
    address xx.xxx.127.129/28 {
        primary;
    }
}

Код: Выделить всё

> show configuration forwarding-options helpers bootp interface irb.654
server xxx.xxx.160.7;
maximum-hop-count 8;


ps: Всем спасибо за внимание, вопрос закрыт ;)
«Когда у общества нет цветовой дифференциации штанов — то нет цели!»
nic-hdl: RAP22-RIPE
Спасибо сказали: