У меня следующая сетевая настройка Linux: есть сетевой интерфейс eth10 с назначенным адресом 10.11.0.1/24. Затем есть сетевой интерфейс tap0 с назначенным фиктивным адресом 0.0.0.1/32 (я назначил фиктивный адрес для запуска интерфейса), и трафик от / до него управляется программой пользовательского пространства, которая изначально создала интерфейс tap0. На другой стороне интерфейса tap0 есть программа пользовательского пространства, использующая его через необработанные сокеты, которая ищет запросы ARP и создает ответ.
Теперь, когда программа пользовательского пространства создает запрос ARP, запрашивающий 10.11.0.1, я ожидаю, что другая программа пользовательского пространства необработанного сокета ответит на него. Однако я получаю два ответа: один от программы сырых сокетов, а другой от ядра Linux.
Очевидно, ядро Linux делает вывод, что 10.11.0.1 - это принадлежащий ему адрес, и, таким образом, отвечает. Однако 10.11.0.1 не является адресом интерфейса tap0. Это адрес интерфейса eth10.
У меня вопрос: почему ядро Linux это делает? Есть ли способ отключить ответы ARP на неправильном интерфейсе?
Моим временным решением этой проблемы является использование адреса, отличного от 10.11.0.1, для целей raw socket / tap0. Но поскольку эта система должна быть тестом на уровне системы для приложения, которое может быть запущено на любой машине разработки, я не могу гарантировать отсутствие конфликтов IP-адресов с другими интерфейсами. Таким образом, было бы неплохо отключить ответы ARP на неправильном интерфейсе.
Другое решение этой проблемы - использовать карту сети, которая резервирует весь интерфейс для приложения пользовательского пространства, не позволяя ядру использовать его для чего-либо, пока выполняется приложение пользовательского пространства. Но я бы хотел, чтобы мои тесты выполнялись без сетевой карты.
Почему вы называете ответ ARP «неправильным»? Безусловно, через этот интерфейс можно получить доступ к IP-адресу системы. Вот почему для начала отправляется ответ ARP. Невыполнение этого может привести к тому, что некоторый трафик будет проходить по менее оптимальным путям или вообще не будет проходить. Например, tap0 может быть подключением VPN, и этот ответ ARP помогает гарантировать, что трафик на другой IP-адрес будет правильно проходить через VPN.
Если вы действительно хотите это сделать, вы можете установить sysctls arp_ignore и arp_announce к желаемым значениям.
arp_announce - INTEGER Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent on interface: 0 - (default) Use any local address, configured on any interface 1 - Try to avoid local addresses that are not in the target's subnet for this interface. This mode is useful when target hosts reachable via this interface require the source IP address in ARP requests to be part of their logical network configured on the receiving interface. When we generate the request we will check all our subnets that include the target IP and will preserve the source address if it is from such subnet. If there is no such subnet we select source address according to the rules for level 2. 2 - Always use the best local address for this target. In this mode we ignore the source address in the IP packet and try to select local address that we prefer for talks with the target host. Such local address is selected by looking for primary IP addresses on all our subnets on the outgoing interface that include the target IP address. If no suitable local address is found we select the first local address we have on the outgoing interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes no matter the source IP address we announce. The max value from conf/{all,interface}/arp_announce is used. Increasing the restriction level gives more chance for receiving answer from the resolved target while decreasing the level announces more valid sender's information.
И arp_ignore описывается как:
arp_ignore - INTEGER Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses: 0 - (default): reply for any local target IP address, configured on any interface 1 - reply only if the target IP address is local address configured on the incoming interface 2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface 3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied 4-7 - reserved 8 - do not reply for all local addresses The max value from conf/{all,interface}/arp_ignore is used when ARP request is received on the {interface}
Итак, вы хотите установить arp_ignore к 1 (или, возможно, 2) и arp_announce к 2.
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
Для тестирования это, наверное, нормально. Но настоящая производственная система, скорее всего, будет вести себя так же, как вы, и ваша программа должна уметь справляться с этим.