В Dhcpd заблокировать выдачу определенным мак-адресам

[lalex 0]

Требуется запретить выдачу динамического адреса для списка mac-адресов в локальной сети вида 192.168.1.0/24

 

правила вида:

iptables -I INPUT -i eth0 -p udp --sport 68 --dport 67 -m mac --mac-source $MAC -j DROP

или

iptables -I INPUT -m mac --mac-source $MAC -j DROP

 

не приводят к нужному результату, адреса по прежнему выдаются, а счётчик в iptables, говорящий о том, что правило сработало, исправно растёт.

как решить вопрос?

[Serjio 19]

Требуется запретить выдачу динамического адреса для списка mac-адресов в локальной сети вида 192.168.1.0/24

 

правила вида:

iptables -I INPUT -i eth0 -p udp --sport 68 --dport 67 -m mac --mac-source $MAC -j DROP

или

iptables -I INPUT -m mac --mac-source $MAC -j DROP

 

не приводят к нужному результату, адреса по прежнему выдаются, а счётчик в iptables, говорящий о том, что правило сработало, исправно растёт.

как решить вопрос?

 

However, the ISC DHCP server uses an Internet Socket of protocol Raw instead of TCP or UDP. This facility, naturally, is only available to root (uid 0, really), and receives packets before the IP Tables processing. It also receives all Internet packet headers as well, so it gets to do additional processing.

But because Raw sockets get packets before the IP Tables processing, the ISC DHCP server is able to obtain an IP address through DHCP.

[roger 12]

man dhcpd.conf

 

CLIENT CLASSING

Clients can be separated into classes, and treated differently depend-

ing on what class they are in. This separation can be done either

with a conditional statement, or with a match statement within the

class declaration. It is possible to specify a limit on the total

number of clients within a particular class or subclass that may hold

leases at one time, and it is possible to specify automatic subclassing

based on the contents of the client packet.

 

To add clients to classes based on conditional evaluation, you can

specify a matching expression in the class statement:

 

class "ras-clients" {

match if substring (option dhcp-client-identifier, 1, 3) = "RAS";

}

 

Note that whether you use matching expressions or add statements (or

both) to classify clients, you must always write a class declaration

for any class that you use. If there will be no match statement and

no in-scope statements for a class, the declaration should look like

this:

 

class "ras-clients" {

}

 

SUBCLASSES

In addition to classes, it is possible to declare subclasses. A sub-

class is a class with the same name as a regular class, but with a spe-

cific submatch expression which is hashed for quick matching. This is

essentially a speed hack - the main difference between five classes

with match expressions and one class with five subclasses is that it

will be quicker to find the subclasses. Subclasses work as follows:

 

class "allocation-class-1" {

match pick-first-value (option dhcp-client-identifier, hardware);

}

 

class "allocation-class-2" {

match pick-first-value (option dhcp-client-identifier, hardware);

}

 

subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;

subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;

subclass "allocation-class-1" 1:0:0:c4:aa:29:44;

 

subnet 10.0.0.0 netmask 255.255.255.0 {

pool {

allow members of "allocation-class-1";

range 10.0.0.11 10.0.0.50;

}

pool {

allow members of "allocation-class-2";

range 10.0.0.51 10.0.0.100;

}

}

 

The data following the class name in the subclass declaration is a con-

stant value to use in matching the match expression for the class.

When class matching is done, the server will evaluate the match expres-

sion and then look the result up in the hash table. If it finds a

match, the client is considered a member of both the class and the sub-

class.

 

Subclasses can be declared with or without scope. In the above exam-

ple, the sole purpose of the subclass is to allow some clients access

to one address pool, while other clients are given access to the other

pool, so these subclasses are declared without scopes. If part of the

purpose of the subclass were to define different parameter values for

some clients, you might want to declare some subclasses with scopes.

 

In the above example, if you had a single client that needed some con-

figuration parameters, while most didn't, you might write the following

subclass declaration for that client:

 

subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {

option root-path "samsara:/var/diskless/alphapc";

filename "/tftpboot/netbsd.alphapc-diskless";

}

 

In this example, we've used subclassing as a way to control address

allocation on a per-client basis. However, it's also possible to use

subclassing in ways that are not specific to clients - for example, to

use the value of the vendor-class-identifier option to determine what

values to send in the vendor-encapsulated-options option. An example

of this is shown under the VENDOR ENCAPSULATED OPTIONS head in the

dhcp-options(5) manual page.

 

 

 

Вот отсюда: http://www.daemon-systems.org/man/dhcpd.conf.5.html

[lalex 0]

что-то я не очень понял смысла написанного.

[roger 12]

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