4

Я использую Centos 7 с Dhclient 4.2.5:

$ uname -a
Linux hostname 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ dhclient -V
Internet Systems Consortium DHCP Client 4.2.5
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.

Недавно я заметил, что журналы содержат много следующих записей:

Dec 14 10:12:32 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:12:49 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:13:09 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:13:23 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:13:41 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)

Кажется, это связано с тем, что DHCP-сервер игнорирует одноадресные запросы. Есть другие люди с такой проблемой: https://forum.pfsense.org/index.php?topic=51701.0

Я попытался изменить IP-адрес назначения пакета на 255.255.255.255 с помощью iptables:

sudo iptables -t nat -I OUTPUT 1 -d 10.23.0.4 -p udp --dport 67 -j DNAT --to-destination 255.255.255.255

Но по какой-то причине правило не соответствует пакетам из dhclient . Однако это совпадает с пакетами из nc: echo 123 | nc -u 10.23.0.4 67

Я нашел эту ссылку, где сказано, что dhclient работает не так, как iptables:

For most operations, DHCP software interfaces to the Linux IP stack at
a level below Netfilter. Hence, Netfilter (and therefore Shorewall)
cannot be used effectively to police DHCP. The “dhcp� interface option
described in this article allows for Netfilter to stay out of DHCP's
way for those operations that can be controlled by Netfilter and
prevents unwanted logging of DHCP-related traffic by
Shorewall-generated Netfilter logging rules.

Итак, у меня есть пара вопросов:

  • правильно ли, что dhclient использует какой-то API более низкого уровня, который не обрабатывается iptables?
  • Есть ли способ уменьшить количество логов от dhclient для неотвеченных одноадресных запросов?

2 ответа2

4
  • правильно ли, что dhclient использует какой-то API более низкого уровня, который не обрабатывается iptables?

Короткая версия: да, для некоторых DHCP-серверов (isc-dhcp и более ранние версии dnsmasq), нет для некоторых других серверов (более поздние версии dnsmasq).

Более длинная версия: источником проблемы является raw socket . Сырая розетка , согласно Википедии,

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

На этой вики-странице ISC (Консорциум интернет-систем является автором самой распространенной программы DHCP) говорится, что:

Протокол DHCP имеет некоторые специфические требования для правильной работы - в частности, возможность передавать и принимать пакеты, отправленные на ограниченный широковещательный адрес "все единицы" (255.255.255.255), и возможность отправлять одноадресную рассылку без ARP. Это невозможно сделать через BSD/UDP-сокеты, хотя dhcpd также открывает BSD/UDP-сокет (называемый "резервным интерфейсом"), который вы увидите в netstat.

Это интересно, потому что это объясняет, почему вы, Googling, будете часто находить людей, пытающихся контролировать запросы DHCP в iptables через UDP-порты 67 и 68. Конечно, дело не в том, что эти порты не открыты, а в том, что это не единственный канал, через который происходит связь между сервером и клиентом.

Это, однако, не может быть полностью успешным: некоторые парни дошли до крайности, полностью закрыв свою машину (iptables отбрасывает все!), Но они не смогли отключиться от DHCP через необработанные пакеты).

Другой интересный эксперимент состоит в том, чтобы снова использовать iptables для отключения компьютера, а затем использовать необработанный сокет для DNS или для соединения TCP: несмотря на iptables, эти попытки связи успешны.

Очень авторитетный комментарий по этому поводу можно найти на сайте Netfilter, где указано:

Необработанные сокеты обходят стек TCP/IP. Хуки Netfilter и, следовательно, iptables находятся внутри стека IP.

И то же самое относится к анализатору пакетов.

Здесь они также объясняют, как обойти проблему: осторожно, это шутка, утверждает Шааф

Это не проект выходного дня.

Наконец, я также хотел бы отметить, что ситуация с dnsmasq отличается: на вики-странице Debian автор dnsmasq Саймон Келли заявляет:

Dnsmasq открывает необработанный сокет, но никогда не читает данные из сокета: вместо этого он используется для общения с клиентами DHCP, которые еще не полностью настроены и не могут выполнять ARP. Это не проблема безопасности. Более поздние версии dnsmasq используют другую технику и больше не имеют открытого сокета.

Редактировать:

Есть ли способ уменьшить количество логов от dhclient для неотвеченных одноадресных запросов?

Это не тривиально, потому что параметр CLI для уменьшения вывода из dhclient , -q , может быть вызван из CLI, но не из dhclient.conf. Кроме того, dhclient вызывается напрямую не вашим сетевым менеджером в целом, а исполняемым файлом ifup: на самом деле,

# strings `(which ifup)` | grep dhclient
/sbin/dhclient
/sbin/dhclient3
dhclient -v -r -pf /run/dhclient.%iface%.pid -lf    /var/lib/dhcp/dhclient.%iface%.leases %iface%
dhclient3 -r -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp3/dhclient.%iface%.leases %iface%
dhclient -1 -v -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp/dhclient.%iface%.leases %iface%  [[-e IF_METRIC=%metric%]]
dhclient3 -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp3/dhclient.%iface%.leases %iface%      [[-e IF_METRIC=%metric%]]
dhclient -6 -r -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases %iface%
dhclient -1 -6 -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases %iface%
dhclient -1 -6 -S -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases %iface%

Как видите, ifup вызывает dhclient с -v (= многословно!) вариант, противоположный тому, что вы хотите.

Какие у вас варианты?

  • Загрузите исходный код, измените приведенный выше вызов и перекомпилируйте его для своего ядра. Это должно быть подпруга.

  • Вы можете использовать двоичный редактор для преобразования -v в -q .

  • Вы можете изменить файл сценария /etc/init.d/networking , заменив вызов ifup на

    ifup .... > /dev/null 2>&1
    

    Перезагрузка или перезапуск networking службы завершит эту модификацию. Это далеко не идеально, потому что он выбрасывает в мусор как бесполезные предупреждения, так и серьезные сообщения об ошибках.

  • Наконец, вы можете выполнить следующее: переместить /sbin/dhclient в /sbin/dhclient-true , а затем создать исполняемый файл /sbin/dhclient со следующим содержимым:

     #!/bin/bash
     ARGS=$(echo "$@" | sed 's/ -v / /g')
     exec /sbin/dhclient-true "-q" "$ARGS"
    
0

DHCP - это то, как клиент получает IP в первую очередь, поэтому, если он использует IP, это будет курица и яйцо. Таким образом, он работает на уровне ниже L2, используя MAC-адреса. Таким образом, IP-маршрутизация не замечает своего существования.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .