Задачи (на проработку)
Производительность:
- Алгоритм классификации пакетов (перебор правил)
- Для хранения правил использовать структуры, как в ipset
- Cache вердиктов fw (conntrack)
- Вердикт на обратный трафик на основе conntrack (сейчас требуется обратное правило)
- Часть правил хранить в userspace и подгружать только по необходимости в BPF. Отдельно заполнять таблицу с описанимем пакетов, не попадающих под правила, чтобы постоянно не лезть в userspace
- Ограничение по количеству правил (не хватает стека?)
- Переход на ringbuffer (kernel >= 5.8) или BPF_MAP_TYPE_LRU_HASH (https://github.com/cloudflare/ebpf_exporter) или BPF_MAP_TYPE_PERCPU_HASH (https://justin.azoff.dev/blog/bpf_map_get_next_key-pitfalls/)
- Подписка вместо опроса (docker, devices, info)
- ip адреса передавать как числа (можно ли тип number в JS?)
- Формат передачи статистики (не HTTP?) (перехода на Push режим в части данных)
- Передавать статистику не как JSON или сокращаеть его максимально. Сейчас очень большие объемы лишних данных (ключей) передаем
- Нужно автоматическое нагрузочное тестирование
- Удалить отладочную информацию (stripped)
https://words.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/
- Хранить правила не в массиве, а в hashmap с флагом BPF_F_NO_PREALLOC
- Наборы правил хранить в разных узлах zookeeper (может превысить ограничение на размер узла; при изменении одного набора перезагружаем их все)
- При помощи опции отключать сбор сетевой статистики и статистики по правиалам (сейчас статистика на уровне ядра собирается всегда, но может никуда не отправляться)
Распределенная система / надежность:
- Обрабатывать потерю связи HA с внешними сервисами (сейчас возможно зависание всего цикла отправки из-за недоступности http)
- Агент в оффлайне
- Формирование отказоустойчивый модели зукипепов - возможно распределенной
- Запуск на старом ядре с контролем его версии. При стром ядре запускаем анент, но кернел спейс запуститься не моожет. Пусть юзер часть запустится и отрапартнует пакетом на сервер о старом ядре
- деградация функций
- транзакционность применения конфигурации (откатывать изменения, в случае сбоя)
- после пересоздания контейнера с zookeeper, работающие HA не могут соединиться с ним. Помогает только перезагрузка HA
Качество кода и сборки:
- Один репозиторий на ha, blocker и winHA
- Использовать макросы для разбора сетевых заголовков (https://github.com/cloudflare/ebpf_exporter/blob/master/examples/xdp.bpf.c)
- Авто тесты (модульные и функциональные)
- be типы для bigendian
- предотвращать одновременную работу ha на одной ОС (PID файл?)
Администрирование (наблюдаемость, управляемость):
- Логирование сервисов под linux и windows (отдельный лог файл, текст сообщений хранить в отдельном файле, логировать коды https://learn.microsoft.com/en-us/windows/win32/eventlog/message-files, так же использовать категории, изучить best practice) , syslog
- доставка конфигурации до host agenta
Безопасность:
- Размер IP, TCP, UDP(?) заголовков не фиксирован. Возможны опциональные поля. Это надо учитывать. Особенно для firewall и bloccker.
- Защищенный Канал до агента
- Валидация агента плюс его этп
- CAP_BPF
Поддержка сетевых технологий:
- Добавлять неизвестные(неразобранные) пакеты в статистику (есть потеря части информации)
- Поддержка VLAN
- Поддержка MPLS
- Поддержка IPv6
- Поддержка фрагментации на уровне L3
- Использование совместно с QoS и агригированными интерфейсами
- Совместная работа с другими eBPF программами и очередями на уровне tc?
Баги:
- возможно переполнение счетчика с количеством байт, надо использовать структуру с двумя счетчиками (https://elixir.bootlin.com/linux/v5.17.6/source/samples/bpf/sockex2_kern.c#L213)
- многопоточность не обрабатывается (для правил, опции и статистики), может приводить к редким невоспроизоводимым проблемам
- bpf_skb_pull_data (загрузка всего пакета) Проверить, что skb->len равно размеру всего пакета
- перехватывать панику во всех горутинах, иначе программа падает и не отписывается
- Корректное завершение при сбоях (освобождение ресурсов)
- Обрабатывать превышение размеров eBPF HASH_MAP
- Валидация входных данных
- Обработка ошибок, логирование
Сырое (не разобранное):
SD-WAN:
- Редирект пакетов, VPN
- Корректное переключение на другой канал (разрыв соединений по старому каналу?)