Почему IP на фиктивном интерфейсе отвечает на запрос ARP на eth0

Question

Я установил на своем ноутбуке (Ubuntu 15.10) фиктивный интерфейс с IP-адресом 10.0.3.144, маской 255.255.255.255

У меня есть USB -> Ethernet-адаптер. Когда он подключен, он настроен на предоставление интерфейса "eth0", который получает свой IP-адрес через DHCP в диапазоне 10.0.3.2 - 10.0.3.10 (маска сети 255.255.255.0)

Я замечаю, что когда появляется eth0 - например, на 10.0.3.2, другие машины могут достигать 10.0.3.144 - это желаемое поведение, но я не совсем понимаю, ПОЧЕМУ это происходит. У меня нет никакой настройки моста, поэтому я подумал бы, что машина не ответила бы за фиктивный интерфейс.

Я могу видеть запросы и ответы arp на интерфейсе ноутбука -

tcpdump -n -i eth0 arp tcpdump: подробный вывод подавлен, используйте -v или -vv для прослушивания полного декодирования протокола на eth0, тип канала EN10MB (Ethernet), размер захвата 262144 байта

tcpdump -n -i eth0 arp
14:01:31.948781 ARP, Request who-has 10.0.3.144 tell 10.0.3.254, length 48
14:01:31.948842 ARP, Reply 10.0.3.144 is-at 00:23:55:9c:52:31, length 28

Это поведение повторяется, если я удаляю запись ARP на 10.0.3.254 (которая является маршрутизатором, также работающим под управлением Linux)

Кто-нибудь может посоветовать, могу ли я положиться на это поведение? (и почему компьютер будет отвечать на интерфейсе для IP-адреса, не связанного с ним - и, соответственно, - будет ли это иметь возможность при определенных обстоятельствах заполнять маршрутизацию в сценариях, где имеется несколько интерфейсов в разных подсетях, и пакеты должны быть вынужденным пересечь брандмауэр?).

Answer 1

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

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

Эту "особенность" Linux иногда называют "проблемой потока ARP", и она описана в разделе 2.1.4 Протокола разрешения адресов (ARP)

Есть несколько способов изменить это поведение в Linux. В прошлом я исправлял ядро, чтобы устранить его. Другие методы менее навязчивы, как указано в LVS HOWTO.
Если вы ничего не делаете, то это поведение ARP должно быть последовательным.

Answer 2

Другие устройства считают, что 10.0.3.144 является частью сети. Маска подсети 255.255.255.255 (aka /24) определяет размер сети 256 адресов. При способе расположения подсетей подсеть с 256 адресами, которая содержит 10.0.3.2-10.0.3.10, является подсетью, которая идет от 10.0.3.0 до 10.0.3.255. Таким образом, когда другие устройства пытаются установить связь с 10.0.3.144, этот адрес представляется частью той же подсети. В результате другие устройства будут пытаться установить связь с использованием уровня 2 (ARP, Ethernet /WiFi), а не уровня 3 (маршрутизация с использованием IPv4 /IPv6).

Компьютер, который получает трафик уровня 2, распознает 10.0.3.144 как часть подсети, которую он использует. Поэтому компьютер обращает внимание на трафик, который адресован компьютеру. Возможно, позже компьютер может даже понять, что 10.0.3.144 - это IP-адрес, который находится на другой сетевой карте. Поскольку сеть реализована с использованием различных программных компонентов, предназначенных для обработки одного или нескольких "уровней" модели OSI, вполне возможно, что компонент, который распознал 10.0.3.144 как IP-адрес уровня 3, не является тем же набором инструкции / код / программирование, которые определили, что адрес ARP был приемлемым.

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

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

• установите IP-адрес как часть другой подсети. (Просмотр диаграммы маски подсети переменной длины ("VLSM") может помочь визуализировать, какие адреса являются частью каких подсетей. Обычные диаграммы обычно просто фокусируются на последнем октете, делая диаграммы проще для понимания для сетей /24 - /32 (где первые 3 октета маски подсети IPv4 («255.255.255»).
• Отключение пересылки может быть полезным. Я думаю, что разные компьютеры могут действовать по-разному в отношении того, считается ли "пересылка" трафика на другой сетевой адаптер в одной и той же системе. Если переадресация включена, то должно быть еще меньше удивления, что трафик может достигнуть другой сетевой карты.
• Межсетевые экраны могут быть полезны для блокирования некоторых типов трафика. (Обратите внимание, что некоторые брандмауэры могут быть ограничены. Например, я знаю, что в OpenBSD клиент DHCP использует BPF, которые не блокируются брандмауэром IP.)

Чтобы ответить на другой вопрос: мостовое соединение часто можно рассматривать как «перенаправление 2-го уровня». Переадресация уровня 3 также может привести к пересечению трафика на другой сетевой адаптер, даже если вы не используете мосты уровня 2.

Относительно того, можете ли вы положиться на поведение: я верю в это. Но вы должны это понимать и задавать вопросы, пока не поймете. Как только вы поймете, как все должно работать, вы можете проверить, так ли это работает; если так, это должно быть довольно надежно. Если все еще есть загадки, тогда могут быть сюрпризы, поэтому не забывайте спрашивать о том, что еще неясно.