У меня есть конфигурация клиентской машины (Ubuntu 14.04.2 LTS), которая напрямую подключается к двум серверным машинам. Серверные машины - находясь в одной подсети - не могут маршрутизировать друг друга. Пакеты не должны маршрутизироваться между клиентскими eth1 и eth2, либо (то есть клиент не является маршрутизатором), и поскольку здесь задействован акт обнаружения, таблица маршрутизации не может быть предварительно запрограммирована с использованием IP-адресов serverX.
Ниже представлена грубая диаграмма. eth0 исключен из этого изображения, поскольку он не может маршрутизироваться в подсеть 172.16.37.0/24. Брандмауэров нет (оба iptables и ufw чисты как свист).
client server01 +-------------------+ +-------------------+ | 172.16.37.53 eth1-|----------|-eth1 172.16.37.11 | | | +-------------------+ | | server02 | | +-------------------+ | 172.16.37.54 eth2-|----------|-eth1 172.16.37.12 | +------------------ + +-------------------+
Проблема, с которой я сталкиваюсь, заключается в том, что ping -I eth2 172.16.37.12 не работает с клиентской машины. Короче, что я наблюдаю через tcpdump является:
client:eth2 выдает ping-запросserver02:eth1 получает ping-запросserver02:eth1 выдает ARP для 172.16.37.54client:eth2 получает ARP, у кого естьЕсли я отправлю бесплатные ARP с arping -A -I eth2 172.16.37.54 от клиента, то наблюдение будет таким:
client:eth2 выдает ping-запросserver02:eth1 получает ping-запросserver02:eth1 выдает пинг-ответ клиентуclient:eth2 получает пинг-ответКогда я straced мой сеанс ping, он повторяет попытку recvmsg; на сокете ничего не отображается.
Вот таблица маршрутизации для вышеупомянутых наблюдений:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.16.187.2 0.0.0.0 UG 0 0 0 eth0 172.16.37.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 172.16.37.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 172.16.187.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Если я добавлю маршрут к хосту в таблицу маршрутизации для 172.16.37.12 -> eth2, то и разрешение ARP, и операция ping работают должным образом. Однако я не могу предварительно запрограммировать маршруты хоста, так как мне нужно обнаружить подключенные машины - все, что у меня есть, это активные интерфейсы и их подсети.
Пакеты не принимаются на eth1 при тестировании eth2 (У меня наблюдались почти все интерфейсы). Также стоит отметить, что такой проблемы не бывает с eth1; он способен ping -I eth1 правильно без записи маршрута к хосту (и из-за порядка маршрута -I вариант в данном случае избыточен, но в целом я не могу полагаться на порядок таблицы).
Почему не приложение (в одном случае кеш ARP; в другом ping) получать пакеты? Как я могу отследить, куда идут данные? Все кажется чтобы пакет работал правильно до тех пор, пока пакет не будет доставлен в приложение.