Не сможет. Потому что это не так. В nftables правила так же остаются отдельными правилами (отдельными сущностями), организованными в линейные списки, только в этих правилах можно дополнительно проверять отдельные сопоставления по словарям/сетам/конкатенациям. Почти того же самого можно добиться при использовании iptables + ipset + multiport. Т.е. если у тебя в nftables 10к правил, то они в самом худшем случае пакет так же пройдёт через 10к проверок правил. Относительно недавно в nftables добавили автоматический оптимизатор, который позволяет слепливать правила, но работает он неидеально.
За счёт чего nftables чуть более продвинуто:
наличие словарей вердиктов, сетов и словарей, и конкатенаций (специальный вид словаря с составными ключами, позволяя проверять в нём несколько полей/свойств за один лукап)
flowtable - очень крутая фича, позволяющая значительно снизить нагрузку на ЦПУ за счёт того, что мы полный процесс обработки производим только для первого пакета соединения, а потом записываем все необходимые действия для потока, и последующие пакеты этого соединения уже берут действия сразу из таблицы потоков, а не прогоняются по всему набору правил.
хранение ruleset чуть более удобное - это всё так же большой набор данных, но уже более структурированный, чем xtables blob. Кстати, про атомарность в xtables - её можно достичь с использованием xtables-restore (загружает все правила отдельной таблицы атомарно).
Так же в iptables есть очень крутая штука - iptables-apply - типа commit confirm в juniper - если не подтвердить новые правила за таймаут, то правила откатятся на предыдущую версию.
Так же в nftables ещё достаточно часто встречаются баги и недоработки. В xtables с этим получше - код уже давно достаточно хорошо вылизан.
Довольно типичная для айтишников (как людей, в целом не обладающих развитым гуманитарным знанием) и неверная точка зрения.
В чём именно она неверная? Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит. Есть задача. Делаем её, документируем в базе знаний, чтобы всем было понятно. При этом пишем поддерживаемый и понятный код. Если кому-то что-то непонятно, то они задают вопросы в комментариях к документации, и там же получают ответы. Имхо, этого вполне хватает для качественной передачи знаний внутри компании.
Что значит "не делится знаниями"? Если процессы документирования налажены, то это не проблема. А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа.
Для защиты от кражи сокетов необходимо настраивать серверные приложения в стандартный режим монопольного использования сетевых портов. На использование опций SO_REUSEPORT или SO_REUSEADDR для серверных сокетов следует наложить табу.
Многопоточные/многопроцессные приложения, которым это необходимо, при этом как себя поведут? Так же предлагаю вам дополнить статью конкретным примером, как это можно сделать :)
жёстко зашиты в коде (внутри функций / методов) / hardcoded
вынесены в константы модулей
константы намного лучше, чем «магическеские числа» и «магические строки» непосредственно в коде
полезно если константы меняются крайне редко, но всё же могут меняться
вынесены в отдельные конфиг‑файлы (файлы, используемые для хранения параметров и настроек приложений).
Я бы добавил ещё два метода конфигурирования - через переменные окружения и через аргументы командной строки. Ну и никто не запрещает использовать сразу несколько методов конфигурирования, которые "наслаиваются" друг на друга.
А вот зря не считаете это страшным. Это очень сильно фрустрирует - внедрение какой-то хурмы ради отсутствия застоя. Это время и усилия можно потратить с большей пользой.
Но раз мы уменьшили себя, то значит уменьшились и наши рецепторы и теперь мы не можем видеть волны, которые значительно больше нас самих. То есть мы перестанем видеть в обычном видимом свете, как видит человек стандартных размеров. Мы перестанем видеть большинство цветов, зато будем видеть рентгеновское излучение.
Мне такое рассуждение кажется немного сомнительным.
В командах есть добавление фильтра с действием зеркалирования трафика, но не учтено, что команды создания ingress очереди нет, а без неё и фильтр не будет создан.
UPD: ни через tc, ни через netdev / ingress хук невозможно заблокировать получение датаграм на сокеты af_packet / pf_packet, т.к. клонирование происходит вот здесь (при условии, что у нас в системе есть фильтры, которые отбирают данные датаграммы; если таких фильтров нет, то и клонирования не происходит - т.н. ленивое поведение), а обработка tc qdisc ingress происходит чуть дальше по коду, и только после происходит обработка через netdev / ingress хук. Так что, похоже, XDP является одним из немногих оставшихся вариантов дропнуть подобный трафик, т.к. выполнение XDP программы происходит чуть раньше, чем происходит клонирование датаграммы.
Пунтим вопрос обратно на мозг: как так iptables пакет считает в статистику, но не может дропнуть? Или может?
На стековерфлоу есть ответ на вопрос, почему счётчики правил для отбрасывания пакетов инкрементируются (и эти пакеты на самом деле дропаются), а dhcp клиент продолжает работать без проблем.
Да, причём именно в egress направлении замечательно фильтруется. Вешаем любую classfull дисциплину и навешиваем несложный фильтр. Например:
~/# tc q add dev <iface> root handle 1: prio
~/# tc f add dev <iface> parent 1: protocol ip prio 1 flower ip_src 0.0.0.0/32 ip_dst 255.255.255.255 ip_protocol udp src_port 68 dst_port 67 action drop
Но нужно дополнительно исследовать поведение, когда на сокете выставлена опция PACKET_QDISC_BYPASS. Тут я навскидку не скажу - надо читать код ядра.
Для ядер, начиная с 5.16 доступен дополнительный способ вместо tc - там добавлен хук netdev/egress, который можно использовать из nftables.
~/# nft -i
nft> flush ruleset
nft> add table netdev t
nft> add chain netdev t egress_chain { type filter hook egress device <iface> priority 0; }
nft> add rule netdev t egress_chain ip saddr 0.0.0.0/32 ip daddr 255.255.255.255/32 meta l4proto udp udp sport 68 udp dport 67 counter drop
А вот в направлении ingress фильтрация через tc / nftables обламывается, потому что клонирование пакета происходит раньше, чем эти инструменты вступают в работу. Это можно увидеть на прекрасной диаграмме из вики (на ней есть неточности, так что не верьте всему и перепроверяйте всегда).
Не сможет. Потому что это не так. В nftables правила так же остаются отдельными правилами (отдельными сущностями), организованными в линейные списки, только в этих правилах можно дополнительно проверять отдельные сопоставления по словарям/сетам/конкатенациям. Почти того же самого можно добиться при использовании iptables + ipset + multiport. Т.е. если у тебя в nftables 10к правил, то они в самом худшем случае пакет так же пройдёт через 10к проверок правил. Относительно недавно в nftables добавили автоматический оптимизатор, который позволяет слепливать правила, но работает он неидеально.
За счёт чего nftables чуть более продвинуто:
наличие словарей вердиктов, сетов и словарей, и конкатенаций (специальный вид словаря с составными ключами, позволяя проверять в нём несколько полей/свойств за один лукап)
flowtable - очень крутая фича, позволяющая значительно снизить нагрузку на ЦПУ за счёт того, что мы полный процесс обработки производим только для первого пакета соединения, а потом записываем все необходимые действия для потока, и последующие пакеты этого соединения уже берут действия сразу из таблицы потоков, а не прогоняются по всему набору правил.
хранение ruleset чуть более удобное - это всё так же большой набор данных, но уже более структурированный, чем xtables blob. Кстати, про атомарность в xtables - её можно достичь с использованием xtables-restore (загружает все правила отдельной таблицы атомарно).
Так же в iptables есть очень крутая штука - iptables-apply - типа commit confirm в juniper - если не подтвердить новые правила за таймаут, то правила откатятся на предыдущую версию.
Так же в nftables ещё достаточно часто встречаются баги и недоработки. В xtables с этим получше - код уже давно достаточно хорошо вылизан.
Если хочется самостоятельно покопаться в исходниках, то для nftables лучше начать вот отсюда - https://elixir.bootlin.com/linux/v7.0/source/net/netfilter/nf_tables_core.c#L250 , а для iptables с аналогичной функции вот отсюда - https://elixir.bootlin.com/linux/v7.0/source/net/ipv4/netfilter/ip_tables.c#L223
Ошибка при выборе инструмента.
Skill issues.
Вполне себе заменяет.
В чём именно она неверная? Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит. Есть задача. Делаем её, документируем в базе знаний, чтобы всем было понятно. При этом пишем поддерживаемый и понятный код. Если кому-то что-то непонятно, то они задают вопросы в комментариях к документации, и там же получают ответы. Имхо, этого вполне хватает для качественной передачи знаний внутри компании.
Тут уже другая проблема - человек пишет неподдерживаемый код (магия без комментариев и документации).
Что значит "не делится знаниями"? Если процессы документирования налажены, то это не проблема. А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа.
Ну и всё-таки
GRE over IPSEC, а не наоборот.Многопоточные/многопроцессные приложения, которым это необходимо, при этом как себя поведут? Так же предлагаю вам дополнить статью конкретным примером, как это можно сделать :)
Я бы добавил ещё два метода конфигурирования - через переменные окружения и через аргументы командной строки. Ну и никто не запрещает использовать сразу несколько методов конфигурирования, которые "наслаиваются" друг на друга.
А вот зря не считаете это страшным. Это очень сильно фрустрирует - внедрение какой-то хурмы ради отсутствия застоя. Это время и усилия можно потратить с большей пользой.
О, ещё один SHITOps!
Но раз мы уменьшили себя, то значит уменьшились и наши рецепторы и теперь мы не можем видеть волны, которые значительно больше нас самих. То есть мы перестанем видеть в обычном видимом свете, как видит человек стандартных размеров. Мы перестанем видеть большинство цветов, зато будем видеть рентгеновское излучение.Мне такое рассуждение кажется немного сомнительным.
В командах есть добавление фильтра с действием зеркалирования трафика, но не учтено, что команды создания ingress очереди нет, а без неё и фильтр не будет создан.
А как вам такое мировоззрение - https://ru.wikipedia.org/wiki/Философский_пессимизм
А будет в обозримом будущем что-нибудь из свежей литературы по Rust? Например, второе издание The rust programming language.
Это разные программы. "Соло на клавиатуре" и сейчас живёт и здравствует. Переехало в вэб.
В openwrt используется своя система инициализации и управления сервисами - procd
UPD: ни через tc, ни через netdev / ingress хук невозможно заблокировать получение датаграм на сокеты af_packet / pf_packet, т.к. клонирование происходит вот здесь (при условии, что у нас в системе есть фильтры, которые отбирают данные датаграммы; если таких фильтров нет, то и клонирования не происходит - т.н. ленивое поведение), а обработка tc qdisc ingress происходит чуть дальше по коду, и только после происходит обработка через netdev / ingress хук. Так что, похоже, XDP является одним из немногих оставшихся вариантов дропнуть подобный трафик, т.к. выполнение XDP программы происходит чуть раньше, чем происходит клонирование датаграммы.
На стековерфлоу есть ответ на вопрос, почему счётчики правил для отбрасывания пакетов инкрементируются (и эти пакеты на самом деле дропаются), а dhcp клиент продолжает работать без проблем.
Да, причём именно в egress направлении замечательно фильтруется. Вешаем любую classfull дисциплину и навешиваем несложный фильтр. Например:
Но нужно дополнительно исследовать поведение, когда на сокете выставлена опция
PACKET_QDISC_BYPASS. Тут я навскидку не скажу - надо читать код ядра.Для ядер, начиная с 5.16 доступен дополнительный способ вместо tc - там добавлен хук netdev/egress, который можно использовать из nftables.
А вот в направлении ingress фильтрация через tc / nftables обламывается, потому что клонирование пакета происходит раньше, чем эти инструменты вступают в работу. Это можно увидеть на прекрасной диаграмме из вики (на ней есть неточности, так что не верьте всему и перепроверяйте всегда).