Назад | Перейти на главную страницу

Ответы ARP от хоста с несколькими интерфейсами

У меня есть (экспериментальная) установка, в которой хост myhost.mydomain имеет три сетевых интерфейса, все подключенные к той же VLAN, что и его шлюз по умолчанию mygateway.mydonain. Настройка выглядит следующим образом:

interface MAC               IP address
--------- ----------------- ---------------
eth0      aa:aa:aa:aa:aa:aa myhost.mydomain
eth1      bb:bb:bb:bb:bb:bb 192.168.0.7
eth2      cc:cc:cc:cc:cc:cc 192.168.1.7

Я наблюдаю, что ок. каждый 4 часа запрос ARP поступает от шлюза по умолчанию, и ответы ARP отправляются на все три интерфейса. Запрос ARP (согласно tcpdump), который улавливается всеми тремя интерфейсами, читает:

who-has myhost.mydomain tell mygateway.mydomain

Ответы ARP гласят:

myhost.mydomain is aa:aa:aa:aa:aa:aa # on eth0
myhost.mydomain is bb:bb:bb:bb:bb:bb # on eth1
myhost.mydomain is cc:cc:cc:cc:cc:cc # on eth2

Так и должно быть в такой установке? Я немного удивлен, потому что myhost.mydomain видимо только "есть" aa:aa:aa:aa:aa:aa, поскольку этот адрес привязан к eth0. Я также вижу, что после этих ответов шлюз по умолчанию отправляет дальнейший TCP-трафик на eth2(вместо того eth0), что вызывает другие осложнения.

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

ОБНОВИТЬ Похоже, я столкнулся ARP поток Вот.

Оказалось, что это случай ARP-потока. Применяется следующее описание:

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

Тот же источник предлагает это средство:

Один из методов предотвращения потока ARP включает использование net/ipv4/conf/$DEV/arp_filter. Короче говоря, использование arp_filter заставляет получателя (в приведенном ниже случае, реальный сервер) выполнять поиск маршрута для определения интерфейса, через который следует отправить ответ, вместо поведения по умолчанию (показанного выше), отвечая со всех интерфейсов Ethernet, которые получают запрос. (Вот)

Чтобы прийти к решению, которое может сохраняться после перезагрузки myhost.mydomain Я выбрала такой рецепт:

echo "net.ipv4.conf.all.arp_filter = 1" > /etc/sysctl.d/arp_filter.conf
sysctl -p /etc/sysctl.d/arp_filter.conf

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