2015-05-22 6 views
2

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

  • всегда устанавливает свой IP-адрес, чтобы быть 172.16.0.50, и предполагает, что он подключен непосредственно к 172.16.0.250 (через физический кабель)
  • он посылает UDP сердцебиения до .250: 2000, независимо от того, был ли 0,250 привязывается к этому порту
  • может передавать трафик UDP на .250: 9001 через .250: 9016
  • он выставляет на основе текста admin через TCP по .50: 7734
  • он связывается как UDP с .50: 7734 и принимает любой входящий трафик на этом порту как временная метка для синхронизации с

Изменение кода устройства абсолютно не касается, к сожалению. Источник доступен, для тестирования доступно оборудование для распаковки, но развернутые блоки агрессивно закрыты для среды, и получить доступ к флеш-чипу, с которого он загружается, - это дневной процесс.

Я заинтересован в подключении нескольких из этих устройств к одному и тому же компьютеру, но мой фон находится в приложениях, в Интернете и некоторых встроенных - а не в сети. Каждое устройство имеет выделенный сетевой интерфейс (например, p1p1, p1p2 и т. Д.), Который, как мне кажется, должен спасти меня, но я не уверен, как установить Fedora для выполнения необходимого олицетворения, и я не уверен, как настроить мой код приложения, чтобы различать UDP-трафик на интерфейсе p1p1 - IP 172.16.0.50 - порт 9000, из UDP-трафика с интерфейса p1p2 - IP 172.16.0.50 - порт 9000 или указать, что я хочу транслировать данную датаграмму через UDP по адресу 172.16 .0.50: 9000 на интерфейсе p1p1 vs 172.16.0.50:9000 на интерфейсе p1p2.

Я считаю, что я могу сделать это с достаточно умной комбинацией статических записей маршрутизации и правил iptables для двунаправленной переадресации портов, но я бы хотел спросить, прежде чем тратить дни на фундаментально ошибочный подход. Какой самый надежный способ сделать это приемлемым?

+0

Вы могли бы в принципе решить проблему с помощью маршрутизации, специфичной для источника, но вы столкнулись с проблемой из-за кэша ARP. Я не вижу никакого хорошего решения, не считая отключения кэша ARP в ядре вашего хоста. – jch

+0

Могут ли здесь помочь 'SO_BINDTODEVICE' и' SO_DONTROUTE'? –

+0

Возможно, хотя более простым решением было бы создать таблицу маршрутизации, специфичную для источника. В любом случае вы по-прежнему будете укушены кэшем ARP, если только вы не ставите отдельный маршрутизатор перед каждым устройством. – jch

ответ

1

Короче говоря, вы хотите подключить к одному хосту ряд устройств, все из которых имеют один и тот же IP-адрес. Вам нужно решить две проблемы - кеш ARP и маршрутизацию.

ARP-кэш

IP-адреса ARP-MAPS кэш соседей по MAC-адресам. Поскольку все ваши устройства имеют один и тот же IP-адрес, кеш ARP будет запутан в вашей ситуации и приведет к тому, что весь трафик будет отправлен одному и тому же соседу.

Я считаю, что под Linux кеш ARP индексируется парами (IP, интерфейс). Это означает, что кеш ARP не запутается, если каждое устройство подключено к другому интерфейсу (сообщите нам, если это работает). С другой стороны, если вы подключите все свои устройства к одному и тому же коммутатору, кэш ARP будет мешать (если вы не будете играть в трюки с VLAN).

Routing

В традиционной маршрутизации следующего прыжка, таблица маршрутизации индексируется IP-адреса назначения. Поскольку все ваши устройства имеют один и тот же IP-адрес, традиционный следующий хоп не может отличить их. В маршрутизация, специфичная для источника, таблица маршрутизации индексируется (dest, src) пар. Другими словами, маршрутизатор, специфичный для источника, может выбрать следующий прыжок, используя как источник, так и пункт назначения.

Для использования маршрутизации, специфичной для источника, вам необходимо настроить отдельный IP-адрес вашего хоста для каждого из устройств. Затем ваше приложение сможет выбрать подходящее устройство, выполнив bind по правому адресу.

Настройка таблицы маршрутизации, специфичной для источника, описана в разделе 4.1 раздела LARTC. Для получения дополнительной информации о маршрутизации, ориентированной на источник, см. draft-troan-homenet-sadr или this paper about source-specifig routing (отказ от ответственности - я соавтор).