Địa chỉ MAC giống hệt nhau trên hai VM khác nhau, nhưng tôi có kết nối internet

Tôi đã thiết lập một mạng như sau: Thiết lập mạng chỉ lưu trữ trên VirtualBox. Bộ điều hợp đầu tiên được cấu hình với NAT, bộ thứ hai có kết nối mạng chỉ có máy chủ

XƯỚNG NGÔN VIÊN: Windows
GUEST: CentOS VM1, CentOS VM2 (bản sao của VM1)

Khi thực hiện ifconfig -a trên cả hai VM, tôi nhận thấy rằng các địa chỉ MAC hoàn toàn giống nhau. Câu hỏi của tôi là làm thế nào tôi có thể ping từ VM1 đến VM2 khi xem xét rằng các địa chỉ MAC giống nhau?

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

Đây là một trong những điều khiến mọi người ngạc nhiên vì nó đi ngược lại những gì họ đã được dạy.
2 máy có cùng địa chỉ mac phần cứng trên cùng một miền quảng bá có thể nói chuyện với nhau tốt miễn là chúng có địa chỉ IP khác nhau (và thiết bị chuyển mạch hoạt động tốt).

Hãy bắt đầu với một thiết lập thử nghiệm:

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

Vì vậy, hãy chú ý làm thế nào cả hai máy có cùng addr MAC, nhưng IP khác nhau.

Hãy thử ping:

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

Vì vậy, các máy chủ từ xa trả lời. Chà, thật lạ. Hãy nhìn vào bảng hàng xóm:

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

Đó là MAC của chúng tôi!

Hãy thực hiện tcpdumptrên máy chủ khác để thấy rằng nó thực sự có lưu lượng truy cập:

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

Vì vậy, như bạn có thể thấy, mặc dù lưu lượng truy cập có cùng địa chỉ mac phần cứng nguồn và đích, mọi thứ vẫn hoạt động hoàn toàn tốt.

Lý do cho điều này là việc tra cứu địa chỉ MAC đến rất muộn trong quá trình giao tiếp. Hộp đã sử dụng địa chỉ IP đích và các bảng định tuyến để xác định giao diện nào sẽ gửi lưu lượng ra ngoài. Địa chỉ mac mà nó thêm vào gói đi kèm sau quyết định đó.

Tôi cũng cần lưu ý rằng điều này phụ thuộc vào cơ sở hạ tầng lớp 2. Làm thế nào những máy này được kết nối, và những gì nằm giữa chúng. Nếu bạn có một công tắc thông minh hơn, điều này có thể không hoạt động. Nó có thể thấy gói này đi qua và từ chối nó.

Bây giờ, tiếp tục với niềm tin truyền thống, rằng điều này không hoạt động. Vâng, đó là sự thật, từ một quan điểm nhất định :-)
Vấn đề phát sinh khi một máy chủ khác trên mạng cần nói chuyện với một trong hai máy này. Khi lưu lượng đi ra, công tắc sẽ định tuyến lưu lượng theo địa chỉ mac đích và nó sẽ chỉ gửi nó đến một máy chủ duy nhất.

Có một vài lý do có thể khiến thiết lập thử nghiệm này hoạt động:

1. Lưu lượng được phát đến tất cả các cổng hoặc tới tất cả các cổng mà MAC khớp.
2. Công tắc loại bỏ cổng nguồn dưới dạng tùy chọn khi xác định cổng đích.
3. Switch thực sự là một switch 3 lớp và được định tuyến dựa trên địa chỉ IP chứ không phải địa chỉ mac.

Các hiệu ứng của một địa chỉ MAC trùng lặp có thể tinh tế trong một số trường hợp.

Chuyển mạch phân phối lưu lượng truy cập đến máy chủ dựa trên địa chỉ "đã thấy MAC". Khi bạn bật máy tính lên và nó sẽ gửi gói đầu tiên của nó ra mạng, công tắc của bạn sẽ đăng nhập vào bảng MAC của nó rằng "địa chỉ MAC X đến từ cổng Y". Ngược lại, trong tương lai khi thấy một gói tin unicast được gửi đến địa chỉ MAC X, nó biết gửi nó đến cổng Y.

Vì VM của bạn chỉ trên một cổng chuyển đổi vật lý duy nhất, nên tùy thuộc vào trình ảo hóa của bạn (VirtualBox) để sắp xếp nơi gửi các gói được hướng đến MAC ảo đó. Trong trường hợp trùng lặp, có lẽ nó chỉ gửi nó cho cả hai VM và cho phép ngăn xếp mạng trên mỗi VM sắp xếp nó. (ngăn xếp mạng có thể sẽ thấy lưu lượng được gửi đến địa chỉ MAC không thuộc một trong các địa chỉ IP của chính nó và âm thầm thả gói.) Vì vậy, bạn có thể tưởng tượng rằng điều này sẽ gây ra một lượng công việc bổ sung khá lớn, cho HĐH để đánh thức và xử lý từng gói, trong khi nếu bạn có địa chỉ MAC duy nhất thì phần cứng hoặc trình điều khiển [ảo] có thể bỏ gói dành cho máy chủ khác, trước khi gửi lên ngăn xếp.

Trên mạng chuyển mạch (không giống như ví dụ VM của bạn), địa chỉ MAC trùng lặp sẽ khiến công tắc bị nhầm lẫn về nơi gửi lưu lượng. Mỗi gói mà một máy chủ có MAC trùng lặp được gửi đi thường sẽ khiến công tắc phỏng đoán rằng máy chủ đó "di chuyển" từ một cổng trên công tắc sang một cổng khác. Nếu cả hai máy chủ đều gửi và nhận lưu lượng truy cập ở cùng một tỷ lệ, bạn sẽ hy vọng mỗi máy chủ sẽ mất 50% lưu lượng truy cập trở lại.

ARP và IPv4 có thể không quá quan tâm đến các địa chỉ MAC trùng lặp, vì vậy mạng IPv4 có thể hoạt động chính xác. (mặc dù ngăn xếp mạnh mẽ hoặc máy chủ có thêm công cụ bảo mật / mạng, có thể coi địa chỉ MAC trùng lặp là cờ đỏ.) Ngoài ra, nếu bạn đang sử dụng DHCP, máy chủ DHCP (không có ID khách hàng đủ duy nhất) có thể chỉ định địa chỉ IPv4 trùng lặp, có thể có vấn đề.

Mặt khác, các cơ sở IPv6 tự động định cấu hình các địa chỉ trên địa chỉ MAC . IPv6 cũng bao gồm khái niệm phát hiện địa chỉ trùng lặp , có nghĩa là một địa chỉ MAC trùng lặp có thể gây ra các hiệu ứng sau (theo RFC 4862, phần 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).