использование netcat для внешнего теста обратной связи между двумя портами

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

Проблема в том, что если я настрою порты Ethernet с IP-адресами в отдельных IP-подсетях и попытаюсь передать данные из одной в другую, стек протоколов ядра обнаружит внутренний маршрут, и хотя передача данных завершится, как ожидалось, это НЕ выйти по проводам. Пакеты маршрутизируются внутри.

Это отлично подходит для оптимизации сети, но мешает тесту, который я хочу провести.

Есть ли простой способ сделать эту работу? Есть ли работающий трюк с iptables? Или, может быть, что-то, что вы можете сделать с таблицей route?


linux networking iptables netcat
person AlanObject    schedule 27.10.2012    source источник
comment
Да, вы можете сделать это с помощью iptables. См. этот ответ о сбое сервера.   -  person Brian Cain    schedule 28.10.2012
comment
@BrianCain Спасибо за ссылку - она ​​выглядит многообещающе. Сложный, но перспективный.   -  person AlanObject    schedule 28.10.2012

Ответы (2)


arrow_upward
2
arrow_downward

Внутренняя маршрутизация предпочтительнее, потому что в поведении маршрутизации по умолчанию все внутренние маршруты помечены как scope link в таблице local. Проверьте это с помощью:

ip rule show
ip route show table local

Если ваше ядро ​​​​поддерживает несколько таблиц маршрутизации, вы можете просто изменить таблицу local для достижения своей цели. Вам не нужно iptables.

Допустим, 192.168.1.1 — это ваш целевой IP-адрес, а eth0 — это интерфейс, через который вы хотите отправлять пакеты по сети.

ip route add 192.168.1.1/32 dev eth0 table local
person Saverio Proto    schedule 07.03.2013
comment
вау, это действительно интересно. Я попробую это на следующей неделе, когда снова буду работать над этим проектом. Судя по вашему профилю, вы здесь новенький, но если вы сможете вытаскивать такие ответы, вы должны мгновенно набрать до 1000 репутаций! - person AlanObject; 07.03.2013

arrow_upward
1
arrow_downward

Я использую сетевые пространства имен для подобных вещей. С каждым из адаптеров в другом пространстве имен трафик данных определенно идет по сети, а не отражается в сетевом стеке. Отдельные пространства имен также предотвращают появление обратных фильтров пакетов и тому подобного.

Итак, предположим, что eth0 и eth1 с iperf3 в качестве отражающего агента (сервер ping или что-то еще). [ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: текст по памяти, все опечатки являются опечатками, YMMV]

ip netns add target
ip link set dev eth1 up netns target
ip netns exec target ip address add dev eth1 xxx.xxx.xxx.xxx/y 
ip netns exec target iperf3 --server

Итак, теперь вы создали пространство имен «цель», переместили один из ваших адаптеров в это пространство имен. Установите его IP-адрес. И, наконец, запустите свое приложение в этом целевом пространстве имен.

Теперь вы можете запускать любую (совместимую) программу в собственном пространстве имен, и если она ссылается на IP-адрес xxx.xxx.xxx.xxx (который явно должен быть доступен по некоторому маршруту), это приведет к передаче трафика по сети, который при надлежащем петлевой путь, найдет адаптер в другом пространстве имен, как если бы это был другой компьютер.

После завершения вы убиваете демон-сервер и удаляете пространство имен по имени, а затем члены пространства имен возвращаются, и вы возвращаетесь к ванили.

killall iperf3
ip netns delete target

Это также работает с «виртуальными функциями» одного интерфейса, но в этом примере требуется выделить одну или несколько виртуальных функций — например. Адаптеры типа SR-IOV — и раздача локальных MAC-адресов. Так что я не сделал этого достаточно, чтобы иметь готовый лакомый кусочек кода.

person Rob White    schedule 03.04.2018