Падение ядра при синхронизации conntrackd

[Antaryo]

Падение ядра при синхронизации conntrackd

[vel21ripn]

В conntrack, в connlabel (128bit) хранится адрес структуры. На разных хостах адреса структур будут разные. При такой схеме синхронизация невозможна принципиально.
Чтобы хоть как-то синхронизовать ноды нужно решить 2 проблемы: падение и синхронизация данных о соединених самого nDPI.

Чтобы избежать падения нужно как минимум иметь разные MAGIC_CT на разных хостах (например задать через procfs). Это просто.
Либо подправить conntrackd чтобы он не восстанавливал данные для connlabel.

Для синхронизации данных nDPI нужно писать аналог conntrackd или допиливать сам conntrackd т.к. в connlabel не запихнуть всю необходимую информацию. Полная синхронизация это очень сложно. Нужно учитывать, что у ndpi данные о соединении меняются чуть ли не после каждого пакета (в начале соединения).
Если синхронизировать только номера протоколов и уровень достоверности, то
это можно сделать путём допиливания conntrackd и модуля ядра.
Всё, что не влезает в 128 бит синхронизировать значительно сложнее.

У нас большие проблемы с ядром.
С 5.19 нет возможности легально обработать удаление записи из conntrack. Чуть ранее была ликвидирована возможность расширять nfconntrack.

Пока я пытаюсь обходиться без патчей для ядра (пересобрать ядро во многих дистрибутивах невозможно для большинства пользователей т.к. ядро подписано).

[Antaryo]

То есть для чего используется connlabel в conntrack в общем случае?

Судя по тому что я вижу, это "буфер" для синхронизации данных в модуле, которые взаимодействуют с сессией.
И эти данные должны быть одинаковыми между нодами, чтобы прозрачно переключаться между ними.

Поправьте, если я не прав.

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

По крайней мере в эксперименте с синхронизацией conntrackd, с разным MAGIC_CT у нод, падения действительно не было, но сессии через правило iptables с nDPI не переносились.

[Antaryo]

А собственно появление connlabel - это не этот патч к ядру?

Я пытаюсь найти концы connlabel, в частности как оно применяется в conntrack и откуда ограничение в 128 бит.

И если это оно, а не может пользователь заменить этот самый label через iptables -m connlabel?

[vel21ripn]

Это не тот патч. Патч нужен если нет возможности использовать live-patch.
connlabel - это возможность хранить в conntrack свои 128 бит данных.
ndpi использует connlabel для хранения указателя на свои структуры.
Это грязный хак.

[Antaryo]

connlabel - это возможность хранить в conntrack свои 128 бит данных.

Разве свои 128 бит данных?
Судя по общению в коммите(коммите, не патче, перепутал) connlable - это расширение conntrack, чтобы хранить lablel, который задаётся через iptables -m connlabel.

Поэтому следом у меня и возник вопрос:

И если это оно, а не может пользователь заменить этот самый label через iptables -m connlabel?

[vel21ripn]

Я сейчас в отпуске, т.ч. не каждый день заглядываю на гитхаб.

connlabel позволяет задать соединению метку в виде 128 битного значения.

Я использовал эту возможность для хранения указателя на внутренние структуры ndpi. Это грязый хак. Если через -j CONNLABEL исправить заначения битов с 64 по 127, то можно получить kernel panic.

Твой PR задает MAGIC_CT один раз при загрузке модуля, что не совсем корректно.

MAGIC_CT должен быть уникален для каждого netns и сделать это нужно до появления первого правила ndpi.
Нужно добавить поле типа "uint16_t magic_ct" в "struct ndpi_net".
Нужно добавить в парсер для /proc/net/xt_ndpi/proto назначение поля.
В качестве примера можно использовать команду netns которая задает имя для netns (поле ns_name) .