[sirmax]

С целью дебага хочу "отмиррорить" все запросы с 67/68 порта на другой порт? 
(проблема в dhcp-helper не работает новая сборка, откатил на старую, но  на тестовом окружении не воспроизводится)

Так неткат видет запросы

nc -ul 0.0.0.0 67

O(�Z�'�$��c�Sc52

...

(пример того что увидел неткат)

А вот ак не видет (не только неткат -сначала пробовал с релеем, думал что-то не то с ним, неткат только для проверки)

iptables -t nat -I PREROUTING -i eth101 -p udp -m udp --dport 67 -j REDIRECT --to-ports 1067

nc -ul 0.0.0.0 1067

 

Тспдамп запросы естественно видит с оригинальным портом до редиректа
Счетчики правила ростут

Устроит вариант с "скопировать" пакет - нужно проверять работу на реальном траффике так как клиенты разные
Вариант "сдампать и проиграть трааффик на лабе" оставлю как последний шанс.

Вариант с перебросом на  ifb тоже не работает (но тут я не уверен насчет броадкастов)

 

tc filter add dev  eth101 parent 1:      prio 1  protocol ip u32 match ip protocol 17 0xFF  match ip dport 68 0xFFFF action mirred egress redirect dev ifb0
tc filter add dev  eth101 parent 1:      prio 1  protocol ip u32 match ip protocol 17 0xFF  match ip dport 67 0xFFFF action mirred egress redirect dev ifb0
tc filter add dev  eth101 parent 1:      prio 1  protocol ip u32 match ip protocol 17 0xFF  match ip sport 68 0xFFFF action mirred egress redirect dev ifb0
tc filter add dev  eth101 parent 1:      prio 1  protocol ip u32 match ip protocol 17 0xFF  match ip sport 67 0xFFFF action mirred egress redirect dev ifb0

 

 

[Ivan_83]

dst NAT, не ужели не работает!?

Более сложный вариант это на фре нетграфом bpf отматчить, потом сделать копию пакета, и копию пропатчить - итого 4 нетграф ноды.

Можно ещё релей агента поставить и он должен делать.

[sirmax]

11 минут назад, Ivan_83 сказал:

dst NAT, не ужели не работает!?

Более сложный вариант это на фре нетграфом bpf отматчить, потом сделать копию пакета, и копию пропатчить - итого 4 нетграф ноды.

Можно ещё релей агента поставить и он должен делать.

DST  nat подразумевает получателя
А пакет DHCP  это   src 0.0.0.0 dst 255.255.255.255
(как минимум первый) 
Можно такое корректно натить? по-моему нет

С нетграфом не выйдет так как линукс

Это и есть релей агент (сейчас на 67/68 как и положено). НО он цепляется на ВСЕ интерфейсы и потом внутри себя анализирует с какого интерфейса пришел пакет и есть ли он в списке "разрешенных"
Соответвенно запустить 2 копии на одном сервере не выйдет - только на разных портах. Вторая копия, обновленная, не работает как ожидалось и нужна отладка. Запустить на живых клиентах - и  сломать многим интернет не вариант

Хочу запустить на другом порту собранный с логами и дебагом dhcp-helper (который имплементация dhcp-relay), и перенаправить часть траффика (например из офисного влана) и исследовать.
Что там может не работать мне не ясно совершенно - и по тому интересно нйти

 

[Ivan_83]

2 минуты назад, sirmax сказал:

А пакет DHCP  это   src 0.0.0.0 dst 255.255.255.255
(как минимум первый) 
Можно такое корректно натить? по-моему нет

И что?

Я на фре броадкасты редиректил на нужные мне хосты, притом PF делал именно копию пакета. Кажется даже без NAT, просто пересылка.

 

2 минуты назад, sirmax сказал:

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

Ой, у вас всё так сложно....

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

[kayot]

По-моему DHCP-запросы/ответы это вообще не IP трафик и iptables его ни блочить, ни тем более редиректить не может.

[sirmax]

Только что, kayot сказал:

По-моему DHCP-запросы/ответы это вообще не IP трафик и iptables его ни блочить, ни тем более редиректить не может.

Это не просто ip, это udp. Другой вопрос что да,  к конкретно isc-dhcpd и редею от них же есть вопросы.

[sdy_moscow]

2 минуты назад, kayot сказал:

По-моему DHCP-запросы/ответы это вообще не IP трафик и iptables его ни блочить, ни тем более редиректить не может.

В Яндексе забанили?

https://yandex.ru/search/?text=iptables dhcp

[kayot]

@sdy_moscow 

Смешно. А попробуй так его запретить.

[sdy_moscow]

17 минут назад, kayot сказал:

@sdy_moscow 

Смешно. А попробуй так его запретить.

На сервере или клиенте?

На сервере:

$IPTABLES -I INPUT -i $LAN_IFACE -p udp –dport 67:68 –sport 67:68 -j DROP

$IPTABLES -I OUTPUT -i $LAN_IFACE -p udp –dport 67:68 –sport 67:68 -j DROP

Попробуйте сами. Если будет работать после этого с меня бутылка коньяка.

[kayot]

2 минуты назад, sdy_moscow сказал:

На сервере или клиенте?

А зачем блокировать на клиенте?

When getting an IP address the dhcp daemon creates a raw socket to the network interface and handles the UDP protocol itself. Thus the UDP packets never go through iptables.

 

 

10 минут назад, sdy_moscow сказал:

Попробуйте сами. Если будет работать после этого с меня бутылка коньяка.

Пробовал, думай как переслать в ua.

[sdy_moscow]

10 минут назад, kayot сказал:

А зачем блокировать на клиенте?

When getting an IP address the dhcp daemon creates a raw socket to the network interface and handles the UDP protocol itself. Thus the UDP packets never go through iptables.

 

Потому что то, что вы цитируете относиться к инициализации клиента, вот продолжение текста с объяснением причин не работы фильтра на клиенте:

The reason the dhcp daemon has to implement UDP is that the kernel can only handle UDP (in fact all of the TCP/IP suite) when the interface has an IP address. Previously dhcp daemons would first give an interface the IP address of 0.0.0.0 but that no longer works.

 

[sirmax]

59 минут назад, sdy_moscow сказал:

На сервере или клиенте?

На сервере:

$IPTABLES -I INPUT -i $LAN_IFACE -p udp –dport 67:68 –sport 67:68 -j DROP

$IPTABLES -I OUTPUT -i $LAN_IFACE -p udp –dport 67:68 –sport 67:68 -j DROP

Попробуйте сами. Если будет работать после этого с меня бутылка коньяка.

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

[sdy_moscow]

@sirmax https://kb.isc.org/docs/aa-00211

There's no rate-limiting built into the DHCP server, but you may be able to use iptables or other software or middleware solutions to provide that kind of protection for your server.

 

Т.Е. ПАКЕТЫ ЧЕРЕЗ iptables ХОДЯТ.

 

СКОРЕЕ ВСЕГО У ВАС НЕ ТА ТАБЛИЦА В ПРАВИЛАХ!

5 часов назад, sirmax сказал:

iptables -t nat -I PREROUTING -i eth101 -p udp -m udp --dport 67 -j REDIRECT --to-ports 1067

http://ipset.netfilter.org/iptables.man.html

Промотайте до  TABLES.

 

В таблицу nat попадают новые соединения скорее всего ваши dhcp пакеты не классифицируются как подходящие под nat или conntrack не включен.

Попробуйте поместить правила в таблицу raw или mangle.

https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html

 

З.Ы. Искал, но не нашел хорошей документации по прохождению пакетов в ядре. Когда-то (когда ковырял ядро) она мне попадалась, но это было 10 лет назад ...

 

Тут кажется где-то было:

http://www.netfilter.org/

или тут

https://www.kernel.org/doc/html/

 

З.З.Ы. Кажется нашел полезное

https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html

С 6-ой главы.

 

[NiTr0]

26 минут назад, sdy_moscow сказал:

 

СКОРЕЕ ВСЕГО У ВАС НЕ ТА ТАБЛИЦА В ПРАВИЛАХ!

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

[sdy_moscow]

18 часов назад, NiTr0 сказал:

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

Я все-же предположу, что броадкаст в принципе в nat таблицу НИКОГДА не попадает. В raw можно попытаться что-то сделать с пакетом - но что я не знаю :-).

NETMAP ? SAME ? MASQUERADE ? вряд-ли, т.к. живут тоже в нат. CT ? Может TEE?

DNAT и SNAT- почти на 100% не сработает.

[NiTr0]

пакеты вроде как в нат таблицу попадают, но на правилах ната дропаются (т.к. невозможно создать запись коннтрака - source IP 0.0.0.0, хоть и сорс мак имеется)

[taf_321]

54 минуты назад, NiTr0 сказал:

пакеты вроде как в нат таблицу попадают, но на правилах ната дропаются (т.к. невозможно создать запись коннтрака - source IP 0.0.0.0, хоть и сорс мак имеется)

В таком разрезе разве это не задача для ebtables или для модного нынче nftables? Они умеют работать на уровне MAC но при этом могут смотреть в ip порты.

[sdy_moscow]

3 минуты назад, NiTr0 сказал:

пакеты вроде как в нат таблицу попадают, но на правилах ната дропаются (т.к. невозможно создать запись коннтрака - source IP 0.0.0.0, хоть и сорс мак имеется)

мак адрес в нате вроде как не используется. сonntrack его не отслеживает.

[NiTr0]

 

1 час назад, taf_321 сказал:

В таком разрезе разве это не задача для ebtables или для модного нынче nftables? Они умеют работать на уровне MAC но при этом могут смотреть в ip порты.

они должны работать на уровне MAC, но уметь менять порт. nftables возможно и справится, я его не крутил, ebtables - он не сможет в udp пакет залезть.

 

11 минут назад, sdy_moscow сказал:

мак адрес в нате вроде как не используется. сonntrack его не отслеживает.

о чем и речь - обратно пакет вроде как известно кому слать (мак адрес), но сорс IP 0.0.0.0, а значит conntrack/nat (которые не в курсе про мак адрес) обработать его не смогут.

[YuryD]

19 часов назад, sirmax сказал:

С целью дебага хочу "отмиррорить" все запросы с 67/68 порта на другой порт? 
(проблема в dhcp-helper не работает новая сборка, откатил на старую, но  на тестовом окружении не воспроизводится)

 

 На коммутаторе миррор-порт не сделать ? и дебажьте с этого порта.

[Ivan_83]

19 часов назад, kayot сказал:

По-моему DHCP-запросы/ответы это вообще не IP трафик и iptables его ни блочить, ни тем более редиректить не может.

И эти люди продают интернет другим...

 

 

18 часов назад, sirmax сказал:

Эти правила не работают. Более того в сокет dhcpd залетает не только его трафик и он грузит процессор если стоит на шлюзе.

Скорее всего корявые реализации.

Те которые я видел юзали BPF и пихали фильтр чтобы сразу нужное из ядра получать.

 

 

17 часов назад, NiTr0 сказал:

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

Уж от тебя то не ожидал :)

Это же ты рассказывал про чудеса на линуксе при туннелировании, пару лет назад :)

 

На фре с помощью PF это делается как то так:

pass in quick on vlan777 dup-to (ng0 172.16.0.119) to 255.255.255.255

просто указываем куда переслать дубликат пакета.

Фактически это работает так: PF берёт все пакеты на vlan777 с dst IP 255.255.255.255 и пересылает их на MAC адрес которому соответствует 172.16.0.119, через интерфейс ng0. Ну примерно так, потому что тут ng0, там вроде как мака нет.

[sdy_moscow]

55 минут назад, Ivan_83 сказал:

Фактически это работает так: PF берёт все пакеты на vlan777 с dst IP 255.255.255.255 и пересылает их на MAC адрес которому соответствует 172.16.0.119, через интерфейс ng0. Ну примерно так, потому что тут ng0, там вроде как мака нет.

Интересно, а в тунель такое можно засунуть?

[NiTr0]

1 час назад, Ivan_83 сказал:

На фре с помощью PF это делается как то так:

pass in quick on vlan777 dup-to (ng0 172.16.0.119) to 255.255.255.255

просто указываем куда переслать дубликат пакета.

так я кажется о NAT говорил, не?

переслать-то можно (-j TEE, уверен, отработает на ура), но ответ-то куда возвращать? на 0.0.0.0? а на какой мак? что, неизвестно? отож...

[sirmax]

1 час назад, Ivan_83 сказал:

Те которые я видел юзали BPF и пихали фильтр чтобы сразу нужное из ядра получать.

 

Я (пока) не осилил BPF но похоже без этого никак скоро будет

Исходную задачу запуска 2 копий dhcp-helper  решил через костыль с бриджом

в бридж засунул оригинальный интерфейс и на него перенес ip адрес в него же виртуальную езернет-пару (veth), второй конец - в неймспейс, там и вторая копия helper
но степень костыльности зашкаливает - это совсем не то что я хотел

 

[Ivan_83]

40 минут назад, sdy_moscow сказал:

Интересно, а в тунель такое можно засунуть?

Так я в эту тему полез чтобы поиграть в игруху по сетке, игруха как раз только броадкастами и умела, друг подключался ко мне по впн вендой, а у меня на домашнем сервере в PF была два правила, одно пересылало его броадкасты мне, а другое мои ему.

Но тут был хак в том, что оно из броадкаста превращалось в юникаст, те dst mac был уже не броадкастовый совсем.

А его интерфейс был вообще p2p, там не было эзернет уровня.

На фре можно вот так сделать:

http://netlab.dhis.org/wiki/ru:software:freebsd:igmpproxy_on_netgraph

только переписать немного правила для BPF чтобы он броадкасты нужные матчил.

 

 

7 минут назад, NiTr0 сказал:

переслать-то можно (-j TEE, уверен, отработает на ура), но ответ-то куда возвращать? на 0.0.0.0? а на какой мак? что, неизвестно? отож...

Ему ответы не нужны.

Насчёт NAT это я предложил не совсем то.