Предположим топологию
А <=> eth0 eth1 <=> B
eth0 и eth1 находятся на одном устройстве с включенной пересылкой IPv6, но эти два интерфейса не объединены в мост.
В случае, если A, B, eth0 и eth1 имеют одинаковый префикс адреса, например их IPv6-адреса
, смогут ли А и Б общаться друг с другом?
Как насчет того, если адреса являются глобальными одноадресными адресами.
Если eth0 и eth1 не настроены для работы в качестве частей моста, как изначально предполагалось в вопросе, тогда средняя система не будет прозрачной для трафика от A к B. Но если эти интерфейсы настроены как две части моста, тогда трафик может проходить через от A до B и наоборот без каких-либо изменений конфигурации A или B.
Использование переадресации для прохождения трафика между A и B через среднее устройство будет сложнее, потому что в условиях, указанных в вопросе, пересылка - не лучший инструмент для этой работы.
Во-первых, поскольку fe80 :: является префиксом локальной ссылки, любой трафик с этим префиксом не будет перенаправляться с одной ссылки (например, A <=> eth0) на другую (eth1 <=> B); вот только как "link-local" определено. Но давайте предположим, что вы используете какой-то другой префикс, но в остальном сохраните настройку точно такой же.
Ядро на среднем устройстве должно сначала получить пакет трафика, чтобы переслать его. И если вы не используете мост, тогда уровень 2 остановит вас здесь: если вы специально не укажете устройству A, что оно должно использовать eth0 для доступа к устройству B (= настроить маршрут хоста на устройстве A для устройства B, используя eth0 как шлюз), устройство A увидит, что IPv6-адрес устройства B имеет тот же префикс, что и само устройство A.
Обычно это означает, что устройство B должно быть непосредственно доступно в том же сегменте сети, поэтому устройство A просто отправит пакет ICMPv6 Neighbor Discovery (NDP) (также известный как Neighbor Solicitation) по каналу A <=> eth0, запрашивая MAC. адрес устройства B.
Адресом назначения пакета запроса соседей будет многоадресный адрес "запрошенного узла", который будет находиться в префиксе FF02: 0: 0: 0: 0: 1: FF00 :: / 104. Начальный FF02 указывает, что это link-local многоадресная рассылка, так что это не будет перенаправляться средним устройством. Таким образом, устройство B никогда не получит его и не сможет на него ответить.
После нескольких попыток устройство A придет к выводу, что нет ответа на запрос соседа, и что это означает, что устройство B недоступно. Среднее устройство никогда не получает возможности переслать что-либо, потому что оно никогда не получает ничего, что можно было бы переслать.
Даже если устройству A уже известен MAC-адрес устройства B, MAC-фильтр (часто в оборудовании сетевого интерфейса) на eth0 не будет передавать пакет ядру промежуточного устройства. В основном: «Это не мой адрес и не адрес многоадресной / широковещательной рассылки, о котором мне нужно заботиться; мне больше не нужно смотреть на него».
Но если вы добавляете запись в таблицу маршрутизации устройства A, которая имеет более высокий приоритет, чем запись по умолчанию для сегмента локальной сети (то есть более жесткий префикс), в которой говорится: «Чтобы достичь устройства B, вы должны использовать eth0 в качестве шлюза», тогда устройство Сначала A будет использовать NDP для получения MAC-адреса eth0 и отправит пакет на устройство B с IPv6-адресом уровня 3 устройства B, но с MAC-адресом уровня 2 eth0.
Сейчас трафик достигает eth0 среднего устройства, проходит MAC-фильтр уровня 2, и ядро пересылает его. «Это мой MAC-адрес, но не мой IPv6-адрес, поэтому его следует переслать». Но как ядро решит, какой интерфейс использовать для пересылки пакета? Ну, он использует таблица маршрутизации!
В соответствии с правилами маршрутизации по умолчанию (также известными как модель слабого хоста) ядро просто выберет первую строку в таблице маршрутизации, префикс которой совпадает с адресом назначения, и будет использовать ее для пересылки трафика. Но у вас будет два интерфейса с одним и тем же префиксом и, вероятно, с одинаковым значением метрики, поэтому у него будет 50% шанс использовать eth1, обычно в зависимости от того, какой интерфейс был настроен последним.
Предположим, вам повезло, и в таблице маршрутизации eth1 указан как самый верхний маршрут для вашего префикса. Пакет перейдет в очередь исходящих сообщений для eth1, и ядро сначала отправит запрос NDP для MAC-адреса устройства B на eth1. Устройство B ответит на него, а затем пакет выйдет из eth1 с IPv6-адресом назначения устройства B, а также с MAC-адресом уровня 2 устройства B. И, наконец, устройство B получит его.
Но подождите, это просто первая половина проблемы! Ответ также должен иметь возможность пройти от B через среднее устройство к A. Таким образом, у него будут те же проблемы: первое устройство B должно знать, что «чтобы достичь устройства A, пакет должен быть отправлен на eth1, а не напрямую на устройство. MAC-адрес A ".
И еще одна проблема. Помните, что eth1 был самым предпочтительным выбором для исходящего трафика для вашего сетевого префикса на среднем устройстве? Теперь, когда ответ идет в обратном направлении, он отправит ответ обратно через eth1, что для него неверно.
Чтобы исправить это, вам понадобится либо маршрут к хосту на среднем устройстве, либо, что более универсально, отдельная таблица маршрутизации для любого трафика, входящего через eth1. Это потребует расширенные правила маршрутизации. (По сути, вы бы реализовали альтернативную стратегию маршрутизации, известную как модель сильного хоста.)
Так что вы жестяная банка сделайте то же самое с пересылкой, но для работы требуется столько дополнительных настроек, что обычно это не стоит усилий.
Вот почему хороший дизайн и планирование сети важны: если вы структурируете свои сетевые префиксы так, чтобы они соответствовали фактической топологии вашей сети, получить пакеты для их назначения будет намного проще.
fe80::/10 являются локальными адресами ссылки. Всегда на связи, никогда не маршрутизируется; только в масштабах местного сегмента. Это адрес «следующего перехода», способ в протоколе IP обнаруживать и разговаривать с соседями, включая маршрутизаторы.
Вы указали без моста, поэтому A и B не являются соседями через уровень 2.
Пересечение границ уровня 2 - это работа маршрутизатора уровня 3. В вашем примере нет такого маршрута, поэтому вот как он обычно проходит, на rfc4861.
Узлы A и B настраивают дополнительные IP-адреса вне глобального одноадресного или уникального локального адресного пространства. Сказать 2001:db8:0:7224::a и 2001:db8:0:7224::b.
2001:db8:0:7224::b. fe80::3 на стороне eth0. Заголовок назначения все еще 2001:db8:0:7224::b, будучи маршрутизатором, он будет пересылать пакеты до их конечного пункта назначения.В любом случае обнаружение соседей определяет адрес канального уровня, в который будет заключен IP-пакет.
Это не должно быть само по себе ответом, просто я могу просто соединить проводные и беспроводные сети. Для IPv4 у меня есть ручной IP-адрес, для IPv6 у меня включена автоконфигурация. Автоконфигурация проходит через br0 нормально. Если вы запускаете radvd на пи (я это делаю), вам нужно указать br0 как интерфейс, иначе вам не о чем беспокоиться.
Мост L2 не может просто мостить IPv4, но не IPv6, потому что мост действительно работает с пакетами Ethernet, а IPv4 и IPv6 на вершине Ethernet. Это все или ничего - мост и то, и другое.
auto eth0
iface eth0 inet manual
auto wlan0
iface wlan0 inet manual
auto br0
iface br0 inet static
» bridge_ports eth0 wlan0
» address 192.168.1.72
» netmask 255.255.255.0
» gateway 192.168.1.1
iface br0 inet6 auto
» bridge_ports eth0 wlan0 # Configured via radvd on this same host
Вы сказали, что eth0 - это WAN, а wlan - это LAN. Это усложняет задачу, потому что вы просто не можете правильно соединить их без серьезных проблем. В этом случае вам придется переслать. Но тогда почему вы хотите маршрутизировать между LAN и WAN по IPv6? Для меня это не имеет особого смысла.