sirmax Опубликовано 18 февраля, 2021 · Жалоба С целью дебага хочу "отмиррорить" все запросы с 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 февраля, 2021 · Жалоба dst NAT, не ужели не работает!? Более сложный вариант это на фре нетграфом bpf отматчить, потом сделать копию пакета, и копию пропатчить - итого 4 нетграф ноды. Можно ещё релей агента поставить и он должен делать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 18 февраля, 2021 · Жалоба 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), и перенаправить часть траффика (например из офисного влана) и исследовать. Что там может не работать мне не ясно совершенно - и по тому интересно нйти Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 февраля, 2021 · Жалоба 2 минуты назад, sirmax сказал: А пакет DHCP это src 0.0.0.0 dst 255.255.255.255 (как минимум первый) Можно такое корректно натить? по-моему нет И что? Я на фре броадкасты редиректил на нужные мне хосты, притом PF делал именно копию пакета. Кажется даже без NAT, просто пересылка. 2 минуты назад, sirmax сказал: Хочу запустить на другом порту собранный с логами и дебагом dhcp-helper (который имплементация dhcp-relay), и перенаправить часть траффика (например из офисного влана) и исследовать. Ой, у вас всё так сложно.... Ну возьмите уже хотя бы мой дхцп на перле, выкиньте от туда всё вообще и сделайте чтобы он тупо отсылал куда вам надо всё что он получает, проще и понятнее уже некуда. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 18 февраля, 2021 · Жалоба По-моему DHCP-запросы/ответы это вообще не IP трафик и iptables его ни блочить, ни тем более редиректить не может. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 18 февраля, 2021 · Жалоба Только что, kayot сказал: По-моему DHCP-запросы/ответы это вообще не IP трафик и iptables его ни блочить, ни тем более редиректить не может. Это не просто ip, это udp. Другой вопрос что да, к конкретно isc-dhcpd и редею от них же есть вопросы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 18 февраля, 2021 · Жалоба 2 минуты назад, kayot сказал: По-моему DHCP-запросы/ответы это вообще не IP трафик и iptables его ни блочить, ни тем более редиректить не может. В Яндексе забанили? https://yandex.ru/search/?text=iptables dhcp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 18 февраля, 2021 · Жалоба @sdy_moscow Смешно. А попробуй так его запретить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 18 февраля, 2021 · Жалоба 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 Попробуйте сами. Если будет работать после этого с меня бутылка коньяка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 18 февраля, 2021 · Жалоба 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 18 февраля, 2021 · Жалоба 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 18 февраля, 2021 · Жалоба 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. По этой причине есть альтернативные реализации и одну из них я дебагаю, собственно и вопрос о ней. Несколько лет назад тут была моя же тема об этой проблеме. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 18 февраля, 2021 · Жалоба @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-ой главы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 февраля, 2021 · Жалоба 26 минут назад, sdy_moscow сказал: СКОРЕЕ ВСЕГО У ВАС НЕ ТА ТАБЛИЦА В ПРАВИЛАХ! таблица-то та. и юникаст пакеты будут натиться. проблема с бродкаст пакетами - они нормально не натятся. и тут разве что кастомный модуль ядра ваять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 18 февраля, 2021 · Жалоба 18 часов назад, NiTr0 сказал: таблица-то та. и юникаст пакеты будут натиться. проблема с бродкаст пакетами - они нормально не натятся. и тут разве что кастомный модуль ядра ваять. Я все-же предположу, что броадкаст в принципе в nat таблицу НИКОГДА не попадает. В raw можно попытаться что-то сделать с пакетом - но что я не знаю :-). NETMAP ? SAME ? MASQUERADE ? вряд-ли, т.к. живут тоже в нат. CT ? Может TEE? DNAT и SNAT- почти на 100% не сработает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 февраля, 2021 · Жалоба пакеты вроде как в нат таблицу попадают, но на правилах ната дропаются (т.к. невозможно создать запись коннтрака - source IP 0.0.0.0, хоть и сорс мак имеется) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 19 февраля, 2021 · Жалоба 54 минуты назад, NiTr0 сказал: пакеты вроде как в нат таблицу попадают, но на правилах ната дропаются (т.к. невозможно создать запись коннтрака - source IP 0.0.0.0, хоть и сорс мак имеется) В таком разрезе разве это не задача для ebtables или для модного нынче nftables? Они умеют работать на уровне MAC но при этом могут смотреть в ip порты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 19 февраля, 2021 · Жалоба 3 минуты назад, NiTr0 сказал: пакеты вроде как в нат таблицу попадают, но на правилах ната дропаются (т.к. невозможно создать запись коннтрака - source IP 0.0.0.0, хоть и сорс мак имеется) мак адрес в нате вроде как не используется. сonntrack его не отслеживает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 февраля, 2021 · Жалоба 1 час назад, taf_321 сказал: В таком разрезе разве это не задача для ebtables или для модного нынче nftables? Они умеют работать на уровне MAC но при этом могут смотреть в ip порты. они должны работать на уровне MAC, но уметь менять порт. nftables возможно и справится, я его не крутил, ebtables - он не сможет в udp пакет залезть. 11 минут назад, sdy_moscow сказал: мак адрес в нате вроде как не используется. сonntrack его не отслеживает. о чем и речь - обратно пакет вроде как известно кому слать (мак адрес), но сорс IP 0.0.0.0, а значит conntrack/nat (которые не в курсе про мак адрес) обработать его не смогут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 19 февраля, 2021 · Жалоба 19 часов назад, sirmax сказал: С целью дебага хочу "отмиррорить" все запросы с 67/68 порта на другой порт? (проблема в dhcp-helper не работает новая сборка, откатил на старую, но на тестовом окружении не воспроизводится) На коммутаторе миррор-порт не сделать ? и дебажьте с этого порта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 февраля, 2021 · Жалоба 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, там вроде как мака нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 19 февраля, 2021 · Жалоба 55 минут назад, Ivan_83 сказал: Фактически это работает так: PF берёт все пакеты на vlan777 с dst IP 255.255.255.255 и пересылает их на MAC адрес которому соответствует 172.16.0.119, через интерфейс ng0. Ну примерно так, потому что тут ng0, там вроде как мака нет. Интересно, а в тунель такое можно засунуть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 февраля, 2021 · Жалоба 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? а на какой мак? что, неизвестно? отож... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 19 февраля, 2021 · Жалоба 1 час назад, Ivan_83 сказал: Те которые я видел юзали BPF и пихали фильтр чтобы сразу нужное из ядра получать. Я (пока) не осилил BPF но похоже без этого никак скоро будет Исходную задачу запуска 2 копий dhcp-helper решил через костыль с бриджом в бридж засунул оригинальный интерфейс и на него перенес ip адрес в него же виртуальную езернет-пару (veth), второй конец - в неймспейс, там и вторая копия helper но степень костыльности зашкаливает - это совсем не то что я хотел Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 февраля, 2021 · Жалоба 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 это я предложил не совсем то. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...