Иногда маршрут выбран правильно, firewall ничего не блокирует, но трафик всё равно уходит не таким, каким его отправляет приложение.
Между сетевым стеком и интерфейсом пакет может пройти через
tc — Traffic ControlСмотрим, есть ли вообще правила
tc filter show dev eth0
Если используется ingress:
tc filter show dev eth0 ingress
На современных системах правила могут быть привязаны к разным hook и chain, поэтому полезно сначала посмотреть всю конфигурацию интерфейса:
tc -s filter show dev eth0
Например, можно обнаружить filter, который выполняет действие над пакетом ещё до его фактической отправки.
Что именно может делать filter
Через actions пакет можно перенаправить:
action mirred egress redirect dev ifb0
Зеркалировать на другой интерфейс:
action mirred egress mirror dev eth1
Или изменить его поля через
pedit.Например, переписать TTL или DSCP. Поэтому приложение может отправить обычный пакет, но на физический интерфейс он попадёт уже после обработки
tc.Смотрим actions подробнее
tc -s filter show dev eth0 egress
-s добавляет статистику.Если у конкретного filter растут
Sent, bytes или packets, правило реально обрабатывает трафикЭто полезнее простого просмотра конфигурации: сразу видно, какой filter участвует в обработке прямо сейчас
Почему это сложно заметить
ip route get покажет правильный интерфейсiptables или nftables могут быть пустымиНо пакет всё равно может:
eth0 → tc filter → redirect → ifb0
или:
application → tc filter → изменение полей → eth0
Особенно часто это встречается на серверах с QoS, Kubernetes CNI, виртуализацией и BPF-программами.
При странном поведении трафика полезно смотреть не только route и firewall, но и tc qdisc, tc filter и счётчики actions - пакет может изменить или направление, или параметры уже внутри сетевого стека Linux
