Идентичный MAC-адрес на двух разных виртуальных машинах, но у меня есть подключение к Интернету

Я настроил сеть следующим образом: Настройте сеть только на хосте в VirtualBox. Первый адаптер настроен с NAT, второй с сетью только для хоста

ВЕДУЩИЙ: Windows
GUEST: CentOS VM1, CentOS VM2 (клон VM1)

При выполнении ifconfig -a на обеих виртуальных машинах я заметил, что MAC-адреса в точности совпадают. У меня вопрос, как я могу пинговать с VM1 на VM2, учитывая, что MAC-адреса совпадают?

VM1:
eth0      Link encap:Ethernet  HWaddr 08:00:27:AF:A3:28  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feaf:a328/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10671 (10.4 KiB)  TX bytes:5682 (5.5 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:C4:A8:B6  
          inet addr:192.168.56.102  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fec4:a8b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:859 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:114853 (112.1 KiB)  TX bytes:4823 (4.7 KiB)

 ip -6 addr
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:feaf:a328/64 scope link 
           valid_lft forever preferred_lft forever
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:fec4:a8b6/64 scope link 
           valid_lft forever preferred_lft forever

VM2:

eth0      Link encap:Ethernet  HWaddr 08:00:27:AF:A3:28  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feaf:a328/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:114 errors:0 dropped:0 overruns:0 frame:0
          TX packets:151 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:41594 (40.6 KiB)  TX bytes:13479 (13.1 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:C4:A8:B6  
          inet addr:192.168.56.101  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fec4:a8b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1900 errors:0 dropped:0 overruns:0 frame:0
          TX packets:78 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:259710 (253.6 KiB)  TX bytes:9736 (9.5 KiB)



ip -6 addr
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:feaf:a328/64 scope link 
           valid_lft forever preferred_lft forever
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:fec4:a8b6/64 scope link tentative dadfailed 
           valid_lft forever preferred_lft forever

Это одна из тех вещей, которая удивляет людей, потому что идет вразрез с тем, чему их учили.
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-адрес, но разные IP-адреса.

Давайте попробуем пинговать:

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-адрес отправителя и получателя, все по-прежнему работает отлично.

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

Следует также отметить, что это зависит от инфраструктуры второго уровня. Как эти машины связаны и что между ними. Если у вас есть более интеллектуальный переключатель, это может не сработать. Это может видеть, что этот пакет проходит и отклоняет это.

Теперь перейдем к традиционному убеждению, что это не работает. Что ж, это правда, с определенной точки зрения :-)
Проблема возникает, когда другой хост в сети должен общаться с любой из этих машин. Когда трафик уходит, коммутатор собирается маршрутизировать трафик по MAC-адресу назначения и отправляет его только на один хост.

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

1. Трафик транслируется на все порты или на все порты, которым соответствует MAC.
2. Коммутатор отбрасывает порт источника в качестве опции при определении порта назначения.
3. Коммутатор на самом деле является коммутатором уровня 3 и выполняет маршрутизацию на основе IP-адреса, а не MAC-адреса.

Влияние дублирования MAC-адреса может быть незначительным в некоторых случаях.

Коммутаторы распределяют трафик к хостам на основе «увиденных MAC» адресов. Когда вы включаете компьютер и он отправляет свой первый пакет в сеть, ваш коммутатор регистрирует в своей таблице MAC-адресов, что «MAC-адрес X пришел из порта Y». И наоборот, в будущем, когда он видит одноадресный пакет, адресованный MAC-адресу X, он знает, что должен отправить его на порт Y.

Поскольку ваша виртуальная машина находится только на одном физическом порту коммутатора, ваш гипервизор (VirtualBox) должен выяснить, куда отправлять пакеты, направленные на этот виртуальный MAC. В случае дубликата, он, вероятно, просто отправляет его обеим виртуальным машинам и позволяет сетевому стеку на каждой виртуальной машине разбирать его. (сетевой стек, скорее всего, увидит, что трафик был отправлен на его MAC-адрес, который не принадлежит ни одному из его собственных IP-адресов, и тихо отбросит пакет.) Таким образом, вы можете себе представить, что это вызовет изрядное количество дополнительной работы, для ОС для пробуждения и обработки каждого пакета, тогда как при наличии уникальных MAC-адресов [виртуальное] оборудование или драйвер могут отбросить пакет, предназначенный для другого хоста, перед отправкой его в стек.

В коммутируемой сети (в отличие от примера с вашей виртуальной машиной) дублированный MAC-адрес может вызвать путаницу в коммутаторе по поводу направления трафика. Каждый пакет, который отправляет хост с дублирующимся MAC, обычно заставляет коммутатор предполагать, что хост «перешел» с одного порта на коммутаторе на другой. Если бы оба хоста отправляли и получали трафик с одинаковой скоростью, можно ожидать, что каждый хост потеряет 50% своего обратного трафика.

ARP и IPv4 могут быть не слишком озабочены дублированием MAC-адресов, поэтому работа в сети IPv4 может работать должным образом. (хотя надежный стек или узел с дополнительными инструментами безопасности / сети могут рассматривать дублирующийся MAC-адрес как красный флаг.) Кроме того, если вы используете DHCP, DHCP-сервер (при отсутствии достаточно уникального идентификатора клиента) может назначить дублированный адрес IPv4, который может быть проблематичным.

С другой стороны, IPv6 основывает автоматически настроенные адреса на MAC-адресе . IPv6 также включает в себя концепцию обнаружения дублированного адреса , что означает, что дублированный MAC-адрес может вызывать следующие эффекты (согласно разделу 5.4.5 RFC 4862):

-  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).