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
Решено! Смотрите мой ответ ниже.
5 ответов
Хорошо, вот решение. Во-первых, резюме:
Вот мой основной сетевой план:
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, чтобы сделать то же самое.
Выбранное вами решение работает, но есть альтернативы, которые не включают 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).
Это связано с тем, как 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-адресов?