UDP sendto не работает при использовании определенных таблиц маршрутизации

343
IMerin

У меня есть система с несколькими интерфейсами. Я изолировал все эти интерфейсы друг от друга, используя несколько sysctlопций, таблицы и правила маршрутизации.

Каждый интерфейс имеет свою собственную таблицу маршрутизации, определяющую маршрут по умолчанию.

Каждая таблица маршрутизации имеет набор из 4 правил, которые определяют, какие пакеты должны идти в какую таблицу.

Для упрощения, скажем, у меня есть eth0 (192.168.1.1)и eth1 (192.168.1.2).

из 192.168.1.1таблицыeth0

к 192.168.1.1столуeth0

iif eth0 table eth0

oif eth0 table eth0

Ибо eth2это то же самое.

Эти sysctlопции:

net.ipv4.conf.all.arp_filter = 1 net.ipv4.conf.all.arp_ignore = 2 net.ipv4.conf.all.arp_announce = 1 net.ipv4.conf.all.rp_filter = 1

Это отлично работает для 99% моих предполагаемых вариантов использования, но один не помогает. Если пакет генерируется из сокета, который не связан, как, например, ответ на UDP-клиент с помощью «sendto», вызов завершается с «Network Unreachable». Если определенный IP-адрес привязан до вызова sendto, вызов завершается, как и ожидалось.

Если не считать настройки универсального маршрута по умолчанию для подобных ситуаций, можно ли что-нибудь сделать с использованием политики маршрутизации (например, iptables, ip rule) для решения этой проблемы?

Спасибо

0
Решение, использующее метку с iptables, не поможет. Выходной манипулятор iptables происходит * после * первого поиска маршрута («решение о маршрутизации») и запускает * второй * поиск («проверка перенаправления»). Таким образом, использование знака iptables здесь не поможет, потому что «Сеть недоступна» происходит при первом поиске, а таблица искажения никогда не используется. Смотрите эту картинку: https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilter-packet-flow.svg A.B 6 лет назад 0
Но добавление этого универсального маршрута по умолчанию, даже если вы никогда не собираетесь его использовать, позволит разрешить использование iptables mark + ip rule fwmark (из проверки запускаемого маршрута). Я не знаю, есть ли решение с использованием iptables для этой проблемы, но маршрут по умолчанию все еще необходим, если задействован iptables A.B 6 лет назад 0
Благодарю. Есть ли какое-либо решение, не связанное с IP-таблицами? Интересно, почему поиск маршрутизации не удается, если указан адрес источника, и у меня есть правило, в котором все пакеты с адреса источника X используют таблицу Y IMerin 6 лет назад 0
как насчет этого? `ip link add dummy0 type dummy`; `ip link set dummy0 up`; `ip route add default dev dummy0`. Очевидно, что ни один пакет не попадет в неправильное место. В моем тесте с socat я перешел от «Сеть недоступна» к ответу с источником 192.168.1.1 при контакте с той же локальной сети через eth0 до 192.168.1.1. Теперь это кажется простым делом. Есть ли реальный реальный случай? Кстати, вы не написали ни одного маршрута в вопросе, поэтому я не могу сделать больше, чем это здесь A.B 6 лет назад 0
Хорошо, все работает нормально для ответа (в том числе случай UDP). Но при инициации исходящего соединения, без указания IP, он выберет ip 1-го интерфейса (192.168.1.1) и dummy0 интерфейса маршрута по умолчанию. Но если я затем отмечу пакет, он запускает проверку перенаправления и, наконец, следует ожидаемым правилам (поэтому переключается на eth0), даже не добавляя правило fwmark, это делает только перенаправление. A.B 6 лет назад 0

0 ответов на вопрос

Похожие вопросы