Идентичный MAC-адрес на двух различных VM, все же у меня есть интернет-соединение
Как предложено @michael-hampton find путь состоит в том, чтобы пойти. Однако немного больше объяснения необходимо. Опция -type может иметь несколько значений, проверить страницу справочника (man find). Вот быстрое определение:
Если Вы ищете регулярные файлы только:
find -type f
Если Вы ищете что-нибудь не каталог:
find ! -type d
Если Вы ищете регулярные файлы и символьные ссылки:
find -type f -o -type l
(предыдущая команда ищет регулярный ИЛИ ссылка),
Это одна из тех вещей, которые удивляют людей, потому что это идет против того, что они учили.
2 Машины с тем же оборудованием MAC-адресом на одном и том же широковещательном домене могут хорошо разговариваться друг с другом, пока у них есть разные IP-адреса (и переключающая передача играет приятно).
Давайте начнем с настройки теста:
VM1 $ ip addr show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:3c:f9:ad brd ff:ff:ff:ff:ff:ff
inet 169.254.0.2/24 scope global enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe3c:f9ad/64 scope link
valid_lft forever preferred_lft forever
VM2 $ ip addr show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:3c:f9:ad brd ff:ff:ff:ff:ff:ff
inet 169.254.0.3/24 scope global enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe3c:f9ad/64 scope link tentative dadfailed
valid_lft forever preferred_lft forever
Так что обратите внимание, как обе машины имеют одинаковый Mac Addr, но разные IPS.
Давайте попробуем пинггинг:
VM1 $ ping -c 3 169.254.0.3
PING 169.254.0.3 (169.254.0.3) 56(84) bytes of data.
64 bytes from 169.254.0.3: icmp_seq=1 ttl=64 time=0.505 ms
64 bytes from 169.254.0.3: icmp_seq=2 ttl=64 time=0.646 ms
64 bytes from 169.254.0.3: icmp_seq=3 ttl=64 time=0.636 ms
--- 169.254.0.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.505/0.595/0.646/0.070 ms
Итак, удаленный хост ответил. Ну, это странно. Давайте посмотрим на соседнюю таблицу:
VM1 $ ip neigh
169.254.0.3 dev enp0s8 lladdr 08:00:27:3c:f9:ad REACHABLE
10.0.2.2 dev enp0s3 lladdr 52:54:00:12:35:02 STALE
Это наш Mac!
позволяет сделать TCPDUMP на другом хосте, чтобы увидеть, что он на самом деле получает трафик:
VM2 $ tcpdump -nn -e -i enp0s8 'host 169.254.0.2'
16:46:21.407188 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.2 > 169.254.0.3: ICMP echo request, id 2681, seq 1, length 64
16:46:21.407243 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.3 > 169.254.0.2: ICMP echo reply, id 2681, seq 1, length 64
16:46:22.406469 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.2 > 169.254.0.3: ICMP echo request, id 2681, seq 2, length 64
16:46:22.406520 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.3 > 169.254.0.2: ICMP echo reply, id 2681, seq 2, length 64
16:46:23.407467 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.2 > 169.254.0.3: ICMP echo request, id 2681, seq 3, length 64
16:46:23.407517 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.3 > 169.254.0.2: ICMP echo reply, id 2681, seq 3, length 64
Итак, как вы можете видеть, даже если трафик имеет тот же трафик, Все все еще работает отлично.
Причина этого состоит в том, что поиск MAC-адреса приходит очень поздно в процессе связи. Коробка уже использовала IP-адрес назначения, а таблицы маршрутизации, чтобы определить, какой интерфейс он собирается отправить трафик на. MAC-адрес, который он добавляет на пакет, поступает после этого решения.
Я также следует отметить, что это зависит от инфраструктуры слоя 2. Как эти машины связаны, и что сидит между ними. Если у вас есть более интеллектуальный выключатель, это может не работать. Это может увидеть этот пакет, проходящий и отклонить его.
Теперь, продолжая традиционную веру, из этого это не работает. Ну, это правда, с определенной точки зрения: -)
Проблема возникает, когда другой хост в сети необходимо поговорить с любыми из этих машин. Когда трафик выходит, переключатель собирается направить трафик MAC-адресом назначения, и он только будет отправлять его на один хост.
Есть несколько возможных причин, по которым эта настройка тестирования работает:
- Трафик транслируется для всех портов, или для всех портов, которые MAC-матчи.
- Переключатель отбрасывает исходный порт в качестве опции при определении порта назначения.
- Выключатель на самом деле является коммутатором уровня 3 и маршрутизация на основе IP-адреса, а не MAC-адреса.
Эффекты дублирующего MAC-адреса могут быть тонкие в некоторых случаях.
Переключатели распределяют трафик на хосты на основе адресов «WETEL MAC». Когда вы включаете свой компьютер, и он отправляет свой первый пакет в сети, ваш коммутатор будет входить в свой таблиц MAC, который «MAC-адрес X пришел из порта y». И наоборот, в будущем, когда он видит одноадресный пакет, адресованный на MAC-адрес X, он знает, чтобы отправить его в порт Y.
, поскольку ваша виртуальная машина находится только на одном порте физического коммутатора, это зависит от вашего гипервизора (VirtualBox) Чтобы разобраться, где отправлять пакеты, направленные на этот виртуальный Mac. В случае дубликата, он, вероятно, просто отправляет его как VMS, так и позволяет стеку сети на каждой VM разбираться. (Сетевой стек скорее всего, увидит, что трафик был отправлен на его MAC-адрес, который не принадлежал к одному из его собственных IP-адресов, и молча сбросьте пакет.) Итак, вы можете себе представить, что это приведет к тому, что это приведет к тому, что это приведет к тому, что это приведет к тому, что это приведет к честному количеству дополнительной работы. ОС для просыпания и обработки каждого пакета, тогда как у уникальных MAC-адресов [Virtual] аппаратное обеспечение или драйвер может отбросить пакет, предназначенный для другого хоста, прежде чем отправлять его в стек.
В коммутируемой сети (в отличие от примера VM), дубликат MAC-адрес приведет к смущению переключателя, где отправлять трафик. Каждый пакет Host с дублирующим MAC отправляет, как правило, приведет к выключанию, чтобы хост «переместился» из одного порта на переключатель на другой. Если оба хозяева отправляли и получают трафик с той же скоростью, вы ожидаете, что каждый хост проиграл 50% от его обратного трафика.
ARP и IPv4 могут быть не слишком обеспокоены дублирующими MAC-адресами, поэтому сеть IPv4 может работать должным образом. (Хотя надежный стек или хост с дополнительными инструментами безопасности / сетевой обработки, могут рассмотреть дубликат MAC-адрес как красный флаг.) Кроме того, если вы используете DHCP, сервер DHCP (отсутствует достаточно уникальный идентификатор клиента) Дублируйте адрес IPv4, который может быть проблематичным.
С другой стороны, Основы IPv6 автоматически настроили адреса на MAC-адресе . IPv6 также включает в себя концепцию обнаружения Дубликата обнаружения адресов , что означает, что дубликат MAC-адрес может привести к следующим эффектам (согласно РФК 4862 Раздел 5.4.5):
- not send any IP packets from the interface,
- silently drop any IP packets received on the interface, and
- not forward any IP packets to the interface (when acting as a
router or processing a packet with a Routing header).