У меня есть машина Ubuntu с двумя интерфейсами (eth0 и eth1). Интерфейс Eth0 имеет адрес dhcp, а eth1 — адрес apipa (169.254.x.x). eth1 не подключен, а eth0 подключен к локальной сети. С моего рабочего стола, который также подключен к той же сети, я могу пропинговать адрес 169.254.x.x и выполнить scp и т. д.

Как это возможно? Маршрутизация не включена.

1
Kumar 4 Июн 2020 в 22:20
1
На каком хосте находится адрес 169.254.x.x? Вы уверены, что eth0 не имеет двух адресов? Включение ip addr и ip route get 169.254.x.x (для любого x.x., который вы использовали) в вопросе может помочь...
 – 
dirkt
5 Июн 2020 в 00:05
Итак, Кумар, какие-либо отзывы о моем ответе?
 – 
A.B
8 Июн 2020 в 11:21

1 ответ

Просто для пояснения: APIPA — это оригинальное название Microsoft, стандартизированное как Динамическая настройка локальных адресов IPv4 (IPv4LL).

Вот что, вероятно, происходит:

  • Рабочий стол сам имеет маршрут к локальной сети IPv4LL, вероятно, в дополнение к более «классическому» маршруту, который он получил с помощью того же DHCP, который использует Ubuntu, скажем, частной локальной сети 192.168.1.0/24.

  • У Ubuntu есть адрес IPv4LL на eth1, скажем, 169.254.5.6.

  • Когда Desktop ищет 169.254.5.6 с момента подключения (непосредственно доступный), он отправляет запросы ARP для 169.254.5.6 в широковещательном режиме,

  • Ubuntu принимает трансляцию. Как хост Linux, он следует модели слабого хоста: IP-адреса, добавленные к его интерфейсам, принадлежат к хосту, а не к их интерфейсу. Это справедливо как для IPv4, так и для ARP, как описано в arp_filter:

arp_filter - логическое значение

[...]

0 - (по умолчанию) Ядро может отвечать на arp-запросы с адресами из других интерфейсов. Это может показаться неправильным, но обычно смысл, потому что это увеличивает шанс успешного общения. IP-адреса принадлежат всему хосту в Linux, а не конкретных интерфейсов. Только для более сложных настроек, таких как загрузка- балансировка, вызывает ли такое поведение проблемы.

Поэтому он отвечает на запрос ARP для 169.254.5.6, назначенного eth1, но на eth0, где он запрашивался, используя MAC-адрес Ethernet eth0. .

  • Теперь рабочий стол разрешил Ethernet-адрес уровня 2, обновляет свою таблицу ARP и отправляет пакет эхо-запроса IPv4 ICMP на 169.254.5.6 Ubuntu с MAC-адресом назначения MAC-адрес eth0 Ubuntu,

  • Ubuntu, следуя модели слабого хоста, отвечает эхо-ответом IPv4 ICMP на запрос. Поскольку OP сообщает, что он работает, это также означает, что:

    • любой исходный адрес рабочего стола также является IPv4LL, и Ubuntu также имеет маршрут 169.254.0.0/16 на eth0 с более низкой метрикой (или все равно используется первым, если равен), поэтому ответ приходит справа,

    • или, что более вероятно, рабочий стол не использует источник IPv4LL для запроса IPv4LL-адреса 169.254.5.6, поэтому он находится в той же IP-сети (установленной DHCP), что и IP-адрес Ubuntu на eth0 и Ubuntu тоже отвечает справа (потому что в его таблице маршрутизации есть запись типа 192.168.1.0/24 на eth0). Этот случай (без использования источника IPv4LL) рекомендуется RFC:

Если и IPv4 Link-Local, и маршрутизируемый адрес доступны на тот же интерфейс, маршрутизируемый адрес должен быть предпочтительнее
исходный адрес для новых сообщений
, но пакеты, отправленные с или на
адрес IPv4 Link-Local по-прежнему доставляется, как и ожидалось.

Предполагая, что я ничего не упустил в своем объяснении, что это за случай?

Конечно, такое поведение не совсем правильно. Потому что каждый широковещательный домен должен иметь свою частную локальную сеть IPv4LL для себя, а не сливать адреса в другую.

На практике это означает, что если хост Linux с конфигурацией по умолчанию участвует в нескольких таких сетях IPv4LL (по одной на каждый интерфейс), он может (неопределенно, см. без необходимости переключать свой собственный адрес IPv4LL, даже если они не находятся на одной стороне, потому что есть заголовок обнаружение конфликтов. Но на практике, все еще из-за слабой модели хоста, по умолчанию несколько маршрутов к 169.254.0.0/16 будут входить в землю раздела Многосетевая (неправильная) конфигурация. Обычно правильно работает только один маршрут: первый среди равных, как показано с помощью ip route show 169.254.0.0/16. Другие будут иметь работающий ARP, но, вероятно, не работающую IP-маршрутизацию. Это требует правильной настройки хоста для множественной адресации (в этом случае он в любом случае, вероятно, перестанет отвечать на ARP, отправленные на «неправильный» интерфейс выше, и не вызовет эту проблему), и интеграция с IPv4LL не поможет. В большинстве случаев этого не происходит с IPv6, потому что любое использование локального адреса канала должно включать интерфейс.

0
Community 7 Окт 2021 в 10:34