Вопросы Теги

IPTables и вопросы о DHCP?

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

8
задан 13 April 2017 в 15:14
3 ответа

Я отвечу на № 2: Нет.

При получении IP-адреса dhcp демон создает неструктурированный сокет к сетевому интерфейсу и обрабатывает сам протокол UDP. Таким образом пакеты UDP никогда не проходят iptables.

Причина dhcp демон должен реализовать UDP, состоит в том, что ядро может только обработать UDP (на самом деле весь комплект TCP/IP), когда интерфейс имеет IP-адрес. Ранее демоны dhcp сначала дали бы интерфейсу IP-адрес 0.0.0.0, но это больше не работает.

11
ответ дан 2 December 2019 в 22:46

Добавление

$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT

заставлю DHCPD обновить быстрее :) Это должно быть работы оба ВВОДА И ВЫВОДА стороны. Можно ОТБРОСИТЬ dhcpd с ebtables, не с iptables. DHCPD, слушающий в 0.0.0.0, не в IP

5
ответ дан 2 December 2019 в 22:46
  • 1
    +1 я иметь его на ВХОДЕ и это должно занимать то же количество времени, как будто я не должен делать иметь его на моих правилах. Когда я делал, это ПРОИЗВЕСТИ его действительно имело Огромное значение. Я читал о ebtables спасибо. –  Guapo 15 October 2010 в 19:27
  • 2
    I ВВЕЛИ-i $INTIF-s 0/0-p udp - dport 67:68 - спорт 67:68-j ПРИНИМАЕТ –  Ta Coen 15 October 2010 в 19:41
  • 3
    просто пробует вышеупомянутое и все еще занимающий слишком много времени по сравнению с использованием ВЫХОДНОГО правила. –  Guapo 15 October 2010 в 19:45
  • 4
    Так как политика является ОТБРАСЫВАНИЕМ, затем необходимо использовать оба ВВОДА И ВЫВОДА. –  Ta Coen 15 October 2010 в 19:55

Мое недавнее наблюдение на OpenWRT Kamikaze 7.09 = 2.4.34 и udhcpc из busybox 1.4.2:

У меня есть политика «ПРИНЯТЬ» в цепочке OUTPUT и в направлении INPUT , изначально я полагался на это классическое универсальное правило: 

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

, чтобы разрешить ответы DHCP в (на мой udhcpc) ​​на интерфейсе WAN. Т.е. именно здесь восходящий DHCP-сервер моего интернет-провайдера назначает мне IP-адрес.

Обратите внимание на разницу между начальным DHCP-обменом (обнаружение, предложение, запрос, подтверждение) и продлением аренды DHCP (запрос, подтверждение).

] После загрузки udhcpc запускает полный начальный обмен. Этот обмен будет успешным. И еще одно или два обновления тоже будут успешными - просто просьба и подтверждение. DHCP-сервер моего интернет-провайдера обычно запрашивает время обновления от примерно часа до 1,5 часов, поэтому мой DHCP-клиент запрашивает обновление каждые 30-45 минут (это поведение основано на RFC).

Но примерно на третьем или четвертое обновление, стало бы интересно. TCPdump покажет около трех попыток обновления, за которыми последует полный первоначальный обмен - всего за несколько минут или даже секунд. Как будто udhcpc не понравилось то, что он получил обратно :-( и в конечном итоге будет удовлетворен полным обменом. После этого будет выполнено еще одно обновление через полчаса ... и история повторится снова.

Я подумал что, возможно, что-то не так с отслеживанием соединения в ядре. Как будто запись conntrack истекает через два часа или около того, а более поздние обновления DHCP терпят неудачу, потому что ACK от сервера фактически не позволяет udhcpc прослушивать сокет. Обратите внимание, что tcpdump (libpcap) прослушивает необработанный интерфейс и может видеть все входящие пакеты, прежде чем они станут объектом iptables. Как только udhcpc отказывается от продлений и, в отчаянии, пытается начать с нуля, используя полный обмен (начиная с DISCOVER), ядро ​​создает новую запись conntrack и может еще некоторое время понимать связанные пакеты ...

Конечно, как только я добавил что-то вроде: 

iptables -A INPUT -i $OUT_IF -p udp --sport 67 --dport 68 -j ACCEPT

, кажется, что обновления работают вечно.

Вы можете найти следующие аргументы командной строки tcpdump полезными: 

tcpdump -vv -s 1500 -i eth0.1 port 67 or port 68

Примечание: -vv спрашивает для подробного вывода диссектора. eth0.1 - мой порт WAN (также интерфейс «NAT за пределами»).

Интересным атрибутом в пакетах ACK является LT: field = предлагаемое / максимальное предоставленное время аренды в секундах. Запросы DHCP отправляются с порта 68 на порт 67. Ответы приходят с порта 67 на порт 68.

3
ответ дан 2 December 2019 в 22:46

Теги

Похожие вопросы