У нас есть интернет-сервис AT&T U-Verse, у которого есть чрезвычайно тупой шлюз DSL.
У нас есть 5 IP-адресов (сетевая маска 248), но шлюз не может делать ничего, кроме сопоставления одного IP -> одного MAC-адреса.
У нас есть один брандмауэр, и мы перенаправляем разные комбинации IP / портов в разные места внутри DMZ.
Наше решение пока состоит в том, чтобы иметь виртуальную машину VMWare на брандмауэре с 4 дополнительными сетевыми адаптерами в ней, чтобы получить остальные 4 IP-адреса ... однако у нас есть проблема.
Шлюз в основном выполняет эхо-запрос ARP, чтобы узнать, отвечает ли IP на ожидаемый MAC. С 4 сетевыми адаптерами в одной локальной сети Linux отвечает на запросы ARP для ВСЕХ IP-адресов с помощью единого интерфейса. Это не то, чего ожидает шлюз, и это приводит к выходу из строя трех других сетевых адаптеров. Шлюз отказывается направлять входящий трафик для 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-адреса совместно используют сегмент LAN, но используют другую 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-адрес, как если бы он принадлежал блоку, а не только конкретному сетевому адаптеру. В результате вы можете получать ответы 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-адреса?