Почему Linux иногда отбрасывает корректный пакет из-за rp_filter… — Network Admin — TG.ME

Почему Linux иногда отбрасывает корректный пакет из-за rp_filter

Ситуация выглядит странно: маршрут до сервера есть, интерфейс поднят, tcpdump показывает входящие пакеты, но соединение не устанавливается.

Одна из причин - Reverse Path Filtering.

Что происходит

Linux получает пакет от 10.20.30.50 на eth1 и проверяет, через какой интерфейс он сам отправил бы трафик обратно к 10.20.30.50.

Если маршрут указывает на eth0, а пакет пришёл через eth1, ядро может решить, что источник подозрительный, и отбросить пакет.

Проверить настройку:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

Почему это часто ломается

Особенно заметно при:

• нескольких uplink
• ECMP
• Policy-Based Routing
• VRF
• асимметричной маршрутизации
• балансировщиках и firewall-кластерах

Например:

Internet → eth1 → server
server → eth0 → Internet

Маршрутизация работает, но обратный путь отличается от входящего.

Как увидеть проблему

Сначала смотрим, куда ядро отправит ответ:

ip route get 10.20.30.50

Затем проверяем фактический входящий трафик:

tcpdump -ni eth1 host 10.20.30.50

Если пакет виден на интерфейсе, но приложение его не получает, стоит проверить фильтрацию на уровне ядра.

Какие значения бывают

rp_filter=0 — проверка отключена

rp_filter=1 — strict mode, обратный маршрут должен совпадать с входящим интерфейсом

rp_filter=2 — loose mode, достаточно существования маршрута до источника

Для сложной маршрутизации strict mode часто становится источником трудноуловимых проблем.

Что важно проверить перед изменением

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

И обязательно смотреть не только all, но и параметры конкретного интерфейса - итоговое поведение зависит от них.

N.A.