Назад | Перейти на главную страницу

Настройка модуля dhcp в FreeRadius (3.0.2 - Centos 6.5)

Я использую модуль REST для авторизации DHCP-запроса. Я хотел бы отправить явный DHCP NAK, если авторизация не удалась, однако модуль DHCP, кажется, немедленно возвращается в случае сбоя и просто игнорирует запрос DHCP без какого-либо ответа.

Вот моя конфигурация модуля DHCP - если rest.authorize успешно, блок управления if (ok) срабатывает, но если rest.authorize не работает, if (fail) никогда не срабатывает.

  dhcp DHCP-Discover {
    rest.authorize

    if (fail) {
            update reply {
                    DHCP-Message-Type = DHCP-Nak
            }
    }

    if (ok) {
        update reply {
           DHCP-Message-Type = DHCP-Offer
        }

        update reply {
            DHCP-Domain-Name-Server = x.x.x.x
            DHCP-Domain-Name-Server = x.x.x.x
            DHCP-Subnet-Mask = 255.255.255.0
            DHCP-Router-Address = x.x.x.x
            DHCP-IP-Address-Lease-Time = 3600
            DHCP-DHCP-Server-Identifier = x.x.x.x
        }
        mac2ip
    }
 }

Ниже приведен результат после получения сообщения 401 Unauthorized. Я хочу добиться временной блокировки DHCP на определенный (небольшой) период времени. Однако поведение FreeRADIUS заключается в том, чтобы игнорировать повторяющиеся запросы для одной и той же транзакции DHCP, что означает, что DHCP на клиенте блокируется до тех пор, пока он не начнет новую транзакцию. Если DHCP NAK может быть отправлен, DHCP-клиент будет инициировать новую транзакцию после каждого NAK (т.е. DHCP Discover), то есть FreeRADIUS будет обрабатывать каждое DHCP-обнаружение от клиента, и блок будет удален намного ближе к желаемому времени блокировки.

Tue Jun  3 03:00:57 2014 : Debug: (3) rest : Sending HTTP GET to 

"http://xxxxxx//api/v1/dhcp/80%3Aea%3A96%3A2a%3Ab6%3Aaa"
Tue Jun  3 03:00:57 2014 : Debug: (3) rest : Processing response header
Tue Jun  3 03:00:57 2014 : Debug: (3) rest :    Status : 401 (Unauthorized)
Tue Jun  3 03:00:57 2014 : Debug: (3) rest : Skipping attribute processing, no body data received
Tue Jun  3 03:00:57 2014 : Debug: rlm_rest (rest): Released connection (4)
Tue Jun  3 03:00:57 2014 : Debug: (3)   modsingle[authorize]: returned from rest (rlm_rest) for request 3
Tue Jun  3 03:00:57 2014 : Debug: (3)   [rest.authorize] = fail
Tue Jun  3 03:00:57 2014 : Debug: (3)  } # dhcp DHCP-Discover = fail
Tue Jun  3 03:00:57 2014 : Debug: (3) Finished request 3.
Tue Jun  3 03:00:57 2014 : Debug: Waking up in 0.2 seconds.
Tue Jun  3 03:00:58 2014 : Debug: Waking up in 4.6 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:00:59 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:00:59 2014 : Debug: Waking up in 2.9 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:02 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:02 2014 : Debug: Waking up in 0.4 seconds.
Tue Jun  3 03:01:02 2014 : Debug: (2) Cleaning up request packet ID 2064626397 with timestamp +56
Tue Jun  3 03:01:02 2014 : Debug: Waking up in 1999991.0 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:06 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:06 2014 : Debug: Waking up in 3999983.1 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:15 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:15 2014 : Debug: Waking up in 7999966.3 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:23 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:23 2014 : Debug: Waking up in 15999942.1 seconds.

В описанном ниже варианте №4, хотя это работает с точки зрения DHCP NAK, модуль DHCP «запоминает» результат авторизации REST для транзакции DHCP. Только когда устройство пытается новую транзакцию, модуль DHCP снова выполняет вызов авторизации REST:

Received DHCP-Discover of id 7b0fb322 from 172.19.0.9:67 to 172.19.0.12:67
Sending DHCP-NAK of id 7b0fb322 from 172.19.0.12:67 to 172.19.0.9:67
Wed Jun  4 00:31:32 2014 : Debug: Waking up in 3.5 seconds.
Received DHCP-Discover of id 7b0fb322 from 172.19.0.9:67 to 172.19.0.12:67
Sending DHCP-NAK of id 7b0fb322 from 172.19.0.12:67 to 172.19.0.9:67
Wed Jun  4 00:31:35 2014 : Debug: Waking up in 0.6 seconds.
Wed Jun  4 00:31:36 2014 : Debug: (4) Cleaning up request packet ID 2064626465 with timestamp +138
Wed Jun  4 00:31:36 2014 : Debug: Waking up in 1999991.0 seconds.
Received DHCP-Discover of id 7b0fb322 from 172.19.0.9:67 to 172.19.0.12:67
Sending DHCP-NAK of id 7b0fb322 from 172.19.0.12:67 to 172.19.0.9:67
Wed Jun  4 00:31:40 2014 : Debug: Waking up in 3999982.8 seconds.

freeradius

rest.authorize {
    fail = 1
}
if (reject || fail) {
    update reply {
        DHCP-Message-Type = DHCP-NAK
    }
}

ХОРОШО. Итак, у вас есть четыре варианта:

Вернуть 401 с типом содержимого JSON и просто набором пустых скобок {} (это может работать)
Используйте фиксацию HEAD v3.0.x, где я только что изменил поведение, чтобы разрешить пустые тела. Странно, что на самом деле он вызывает обратный вызов данных тела для пустого тела. Я этого не ожидал, поэтому он выдает ошибку. Это появится в выпущенной версии 3.0.4.
Отредактируйте оператор возврата чуть ниже RDEBUG2("Skipping....") в src/modules/rlm_rest/rest.c быть return 0.
Отредактируйте ваш вызов rest, чтобы он соответствовал фрагменту, который я добавил выше (потому что размещение его после этого маркированного списка испорчено с форматированием).