Вопрос или проблема
Меня сбивает с толку обработка широковещательных пакетов в nftables и их ответы. Это связано с разрешением имен NetBIOS.
nmblookup отправляет пакет на 192.168.115.255:137. Однако выражение meta pkttype broadcast не соответствует этому пакету. Почему? Я упускаю что-то важное?
Другая проблема в том, что ct state established,related не соответствует ответу на широковещательный пакет. Опять почему? Это преднамеренное поведение conntrack? На мой взгляд, это не имеет смысла. Или я здесь тоже упускаю что-то важное?
Ответ или решение
Обработка широковещательных пакетов в nftables может быть источником путаницы, особенно когда речь идет о разрешении имен NetBIOS. Давайте разберем ваш вопрос по частям, чтобы выяснить причины такого поведения системы nftables и conntrack.
Во-первых, рассмотрим, почему выражение meta pkttype broadcast не соответствует пакету, отправленному командой nmblookup на адрес 192.168.115.255:137. Важно понимать, что meta pkttype broadcast предназначено для идентификации пакетов на канальном уровне (L2), которые являются широковещательными. Однако IP-адрес 192.168.115.255 является широковещательным на уровне сети (L3). Именно поэтому, хотя IP-адрес имеет вид широковещательного, сам пакет не определяется как таковой на основе поля pkttype, поскольку это поле рассчитано для анализов на уровне канала передачи данных.
Теперь перейдем ко второй части вашего вопроса о состоянии соединения в контексте conntrack. Вы упомянули, что состояние ct state established,related не соответствует ответу на широковещательный пакет. Это действительно так и связано с тем, что conntrack, как правило, отслеживает соединения на основе пары IP-адресов и портов. Широковещательный запрос генерирует множественные ответы, которые не ассоциированы с конкретным сеансом соединения, в виду отсутствия четкого идентификатора источника в виде IP-адреса отправителя, используемого для начальной установки соединения.
Таким образом, поведение conntrack в отношении широковещательных сообщений носит специфический характер, и его невозможно практически применять для базовой логики conntrack, заключающейся в отслеживании состояния соединений. Это не является ошибкой или недостатком, а скорее логическим следствием природы работы протокола.
Если вам необходимо обработать ответы на широковещательные пакеты, вы можете использовать прямое указание на определенные условия в ваших правилах nftables, такие как IP-адрес источника и порт, вместо использования механизма conntrack.
Итак, в сущности, вы ничего не упускаете. Это действительно особенности работы с широковещательными пакетами и conntrack, которые требуют специального учета в конфигурациях систем фильтрации пакетов. Надеюсь, это объяснение внесло ясность в ваш вопрос и помогло лучше понять механизмы работы nftables и обработки состояний соединений со стороны conntrack.