Ubuntu Linux - несколько сетевых карт, одна и та же локальная сеть… Ответы ARP всегда выходят из одной сетевой карты

У нас есть интернет-сервис AT & T U-Verse, который имеет чрезвычайно тупой шлюз DSL.

У нас есть 5 IP-адресов (маска сети 248), но шлюз не может делать ничего, кроме сопоставления одного IP-адреса -> одного MAC-адреса.

У нас есть один брандмауэр, и мы перенаправляем различные комбинации IP / портов в разные места внутри DMZ.

Наше решение до сих пор состоит в том, чтобы иметь виртуальную машину VMWare на брандмауэре с 4 дополнительными сетевыми картами, чтобы получить остальные 4 IP-адреса ... однако у нас есть проблема.

Шлюз в основном выполняет пинг ARP, чтобы узнать, отвечает ли IP ожидаемый MAC. С 4 сетевыми картами, расположенными в одной локальной сети, linux отвечает на запросы ARP для ВСЕХ IP-адресов, используя один интерфейс. Это не то, что ожидает шлюз, и это портит 3 другие сетевые карты. Шлюз отказывается маршрутизировать входящий трафик для IP-адресов, где результаты пинга ARP не являются ожидаемыми MAC.

Как мы можем получить ответы ARP для IP-адреса eth0, чтобы выйти из eth0, IP-адреса eth1 для выхода из eth1 и т. Д.?

РЕДАКТИРОВАТЬ

Ответ Кристофера Кэшелла не работает в этой ситуации. Я очень надеялся прочитать это, но ... Нет.

РЕДАКТИРОВАТЬ 2

Решено! Смотрите мой ответ ниже.

Выбранное вами решение работает, но есть альтернативы, которые не включают arptables. (Изначально Кристофер Кэшелл был на правильном пути, но он был не в курсе.)

Короче говоря, вы хотите установить эти параметры:

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

Они должны быть доступны при запуске современного ядра Linux серии 2.6. Проверьте и убедитесь, что в вашей системе существуют / proc / sys / net / ipv4 / conf / / arp_announce и / proc / sys / net / ipv4 / conf / / arp_ignore.

Параметр arp_filter работает только тогда, когда ваши различные IP-адреса совместно используют сегмент локальной сети, но используют другую IP-подсеть. Если они также используют подсеть IP, вам нужно использовать «arp_ignore» и «arp_announce», как указано выше.

(Полагаю, вам также может понадобиться установить arp_filter обратно на 0).

Хорошо, вот решение. Во-первых, резюме:

Вот мой основной сетевой план:

 eth0 10.10.10.2 netmask 255.255.255.248
 eth1 10.10.10.3 netmask 255.255.255.248
 eth2 10.10.10.4 netmask 255.255.255.248
 eth3 10.10.10.5 netmask 255.255.255.248

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

Во-первых, широковещательные запросы ARP идут на все это. Поскольку все 4 IP-адреса являются действительными локальными адресами, все 4 интерфейса будут пытаться ответить.

1) установить arptables . Добавьте это куда-нибудь во время загрузки ( /etc/rc.local здесь):

arptables -F INPUT
arptables -A INPUT -i eth0 --destination-ip ! 10.10.10.2 -j DROP
arptables -A INPUT -i eth1 --destination-ip ! 10.10.10.3 -j DROP
arptables -A INPUT -i eth2 --destination-ip ! 10.10.10.4 -j DROP
arptables -A INPUT -i eth3 --destination-ip ! 10.10.10.5 -j DROP

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

Этого само по себе недостаточно. Следующий бит - это проблема таблицы ARP. Запрашивающий ПК, вероятно, уже имеет запись таблицы ARP, и поэтому в Linux он будет использовать интерфейс, связанный с этим. До тех пор, пока не истечет срок действия этой записи таблицы ARP, он будет пытаться отправлять ответы ARP, используя интерфейс этой записи, а не тот, который связан с запросом ARP.

Опция sysctl rp_filter , по-видимому, отклоняет исходящие пакеты ответа ARP, если они находятся на неправильном интерфейсе. Так...

2) Отключить rp_filter .

В Debian / Ubuntu это означает комментирование двух строк rp_filter в /etc/sysctl.d/10-network-security.conf .

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

Если я добавлю другой интерфейс и мне понадобится защита от спуфинга, возможно, я смогу создать несколько записей arptables / iptables, чтобы сделать то же самое.

Это связано с тем, как Linux обрабатывает IP-адреса и сетевые карты. По сути, он обрабатывает IP-адрес, как если бы он принадлежал блоку, а не только конкретному NIC. В результате вы можете получить ARP-ответы от IP-адресов на интерфейсах, которые вы не ожидаете.

Решение является опцией sysctl. Насколько я помню, вы ищете:

net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1

Это решит проблему для вас. Просто добавьте их в /etc/sysctl.conf и запустите ' sysctl -p' (или запустите каждую строку в качестве аргумента ' sysctl -w'.

Это заставит Linux отвечать только на запросы ARP на интерфейсе, которому фактически назначен IP-адрес.

Принятый ответ в сочетании с этим: http://www.linuxquestions.org/questions/linux-networking-3/multiple-interfaces-all-traffic-flows-through-just-one-538701/

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

Можете ли вы соединить шлюз и иметь брандмауэр для обработки IP-адресов?