Задачи (на проработку)

SD-WAN:

- Редирект пакетов, VPN

- Алгоритм классификации пакетов (перебор правил) https://codilime.com/blog/network-acl-processing-algorithms-optimizing-firewall-performance/

- Ограничение по количеству правил (не хватает стека?)

- connection tracking?

Рефакторинг:

Один репозиторий на ha, blocker и winHA

Переход на ringbuffer

bpf_skb_pull_data (загрузка всего пакета) Проверить, что skb->len равно размеру всего пакета

be для bigendian

разделять broadcast, multicast, unicast

использовать go context для завершения программы

перехватывать панику во всех горутинах, иначе программа падает и не отписывается

Логирование сервисов под linux и windows (отдельный лог файл, текст сообщений хранить в отдельном файле, логировать коды https://learn.microsoft.com/en-us/windows/win32/eventlog/message-files, так же использовать категории, изучить best practice)

Обрабатывать потерю связи HA с внешними сервисами (сейчас возможно зависание всего цикла отправки из-за недоступности http)

Сбор информации по докеру: (не создавать соединение при каждом сборе информации, а держать одно соединение; подписываться на появление новых контейнеров)

Также попдисывать на остальную osInfo и появление новых сетевых интерфейсов

Поддержка ipv6, добавлять неизвестные(неразобранные) пакеты в статистику

ip адресса передавать как числа (можно ли тип number в JS?)

контроль соответствия userspace и kernelspace. Не давать возможность подключатся к нашему ebpf из чужой программы

Размер IP, TCP, UDP(?) заголовков не фиксирован. Возможны опциональные поля. Это надо учитывать. Особенно для firewall и bloccker.

Формат передачи статистики (не HTTP?)

Алексей:

1. Защищенный Канал до агента

2. Валидация агента плюс его этп

3. Формирование отказоустойчивый модели зукипепов - возможно распределенной

4. Агент в оффлайне

5. Сислог + стандарты легирования

6. Принципы аварийного отключения и корректная отписка от эбпф

7. Работа при наличии эбпф и падении юзерспейса

1) компиляция по частям (часть сборок будут обадать более опасными функциями, которые надо в определенных сборках исключать физиески)

2) контроль версионности и сборки как Юзер, так и кеонел спейс модуля

3) вопрос протоколов и перехода на Push режим в части данных

4) Запуск на старом ядре с контролем его версии. При стром ядре запускаем анент, но кернел спейс запуститься не моожет. Пусть юзер часть запустится и отрапартнует пакетом на сервер о старом ядре ...

5) контроль агентом утилизации ресурсов и потенциальная деградация функций при его перегрузки