Adresse MAC identique sur deux VM différentes, mais j'ai une connectivité Internet

J'ai configuré un réseau en tant que tel: configurez un réseau hôte uniquement sur VirtualBox. Le premier adaptateur est configuré avec NAT, le second avec un réseau uniquement hôte

HÔTE: Windows
GUEST: CentOS VM1, CentOS VM2 (clone de VM1)

Lors de l'exécution d'ifconfig -a sur les deux machines virtuelles, j'ai remarqué que les adresses MAC sont exactement les mêmes. Ma question est de savoir comment puis-je envoyer une requête ping de VM1 à VM2 étant donné que les adresses MAC sont les mêmes?

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

networking ip ethernet mac-address

— utilisateur
source

Êtes-vous sûr que vous effectuez réellement un ping sur VM1 à partir de VM2 et que vous ne pingez pas réellement sur VM1? Vous pouvez avoir deux machines avec la même adresse MAC, mais uniquement si elles se trouvent sur des liaisons Ethernet différentes, ce qui n'est pas le cas pour deux machines virtuelles utilisant le même logiciel de virtualisation sur le même hôte.

— Gilles 'SO- arrête d'être méchant'

Pourquoi est-ce fermé en double? Les questions ne sont pas les mêmes.

— Patrick

Avez-vous copié une VM sur l'autre? Dans ce cas, vous devez changer cela via "VirtualBox Manager" -> Paramètres -> Adaptateur 1 -> Avancé -> Adresse MAC

— Anthon

@Gilles. Vous avez tort. Deux machines virtuelles utilisant le même logiciel de virtualisation sur le même hôte peuvent avoir des liaisons Ethernet différentes. Regardez VMware Workstation Virtual Network Editor pour un exemple.

— fpmurphy

@khadija, remarquez que vous voyez dadfaileddans votre ip -6 addrsortie. Cela signifie que votre adresse n'a pas détecté d'adresse en double, donc IPv6 ne sera pas utilisable sur cette interface.

— mpontillo

Réponses:

C'est une de ces choses qui surprend les gens parce que cela va à l'encontre de ce qu'on leur a enseigné.
2 machines avec la même adresse matérielle mac sur le même domaine de diffusion peuvent très bien communiquer entre elles tant qu'elles ont des adresses IP différentes (et que l'équipement de commutation fonctionne bien).

Commençons par une configuration de test:

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

Notez donc comment les deux machines ont le même adresse MAC, mais des adresses IP différentes.

Essayons de cingler:

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

Ainsi, l'hôte distant a répondu. Eh bien, c'est bizarre. Regardons la table voisine:

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

C'est notre MAC!

Permet de faire un tcpdumpsur l'autre hôte pour voir qu'il obtient réellement le trafic:

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

Ainsi, comme vous pouvez le voir, même si le trafic a la même adresse mac matérielle source et de destination, tout fonctionne toujours parfaitement bien.

La raison en est que la recherche d'adresse MAC arrive très tard dans le processus de communication. La boîte a déjà utilisé l'adresse IP de destination et les tables de routage pour déterminer sur quelle interface elle va envoyer le trafic. L'adresse mac qu'il ajoute au paquet vient après cette décision.

Je dois également noter que cela dépend de l'infrastructure de couche 2. Comment ces machines sont connectées et ce qui se trouve entre elles. Si vous avez un commutateur plus intelligent, cela peut ne pas fonctionner. Il peut voir ce paquet passer et le rejeter.

Passons maintenant à la croyance traditionnelle selon laquelle cela ne fonctionne pas. Eh bien, c'est vrai, d'un certain point de vue :-)
Le problème se pose lorsqu'un autre hôte du réseau doit parler à l'une ou l'autre de ces machines. Lorsque le trafic disparaît, le commutateur va acheminer le trafic par l'adresse mac de destination, et il ne l'enverra qu'à un seul hôte.

Il existe plusieurs raisons possibles pour lesquelles cette configuration de test fonctionne:

Le trafic est diffusé vers tous les ports ou vers tous les ports auxquels le MAC correspond.
Le commutateur ignore le port source en option lors de la détermination du port de destination.
Le commutateur est en fait un commutateur de couche 3 et le routage est basé sur l'adresse IP et non sur l'adresse mac.

— Patrick
source

Explication intéressante! Merci d'avoir fourni des éclaircissements.

— utilisateur

Les effets d'une adresse MAC en double peuvent être subtils dans certains cas.

Les commutateurs distribuent le trafic aux hôtes en fonction des adresses "MAC vues". Lorsque vous allumez votre ordinateur et qu'il envoie son premier paquet sur le réseau, votre commutateur enregistre dans sa table MAC que "l'adresse MAC X provient du port Y". Inversement, alors, à l'avenir, lorsqu'il verra un paquet de monodiffusion adressé à l'adresse MAC X, il sait qu'il doit l'envoyer au port Y.

Étant donné que votre machine virtuelle est uniquement sur un seul port de commutateur physique, c'est à votre hyperviseur (VirtualBox) de trier où envoyer les paquets dirigés vers ce MAC virtuel. Dans le cas d'un doublon, il l'envoie probablement aux deux machines virtuelles et laisse la pile réseau sur chaque machine virtuelle le trier. (la pile de mise en réseau verrait probablement que le trafic a été envoyé à son adresse MAC qui n'appartenait pas à l'une de ses propres adresses IP, et abandonnerait silencieusement le paquet.) Vous pouvez donc imaginer que cela entraînerait une quantité considérable de travail supplémentaire, par exemple le système d'exploitation pour se réveiller et traiter chaque paquet, alors que si vous aviez des adresses MAC uniques, le matériel ou le pilote [virtuel] pourrait supprimer le paquet destiné à l'autre hôte, avant de l'envoyer dans la pile.

Sur un réseau commuté (contrairement à votre exemple de machine virtuelle), une adresse MAC en double entraînerait une confusion sur un commutateur pour savoir où envoyer le trafic. Chaque paquet envoyé par un hôte avec un MAC en double entraînerait généralement le commutateur à supposer que l'hôte "déplacé" d'un port sur le commutateur à un autre. Si les deux hôtes envoyaient et recevaient du trafic au même taux, vous vous attendriez à ce que chaque hôte perde 50% de son trafic de retour.

ARP et IPv4 peuvent ne pas être trop préoccupés par les adresses MAC en double, donc la mise en réseau IPv4 peut fonctionner correctement. (bien qu'une pile robuste, ou un hôte avec des outils de sécurité / réseau supplémentaires, puisse considérer une adresse MAC en double comme un indicateur rouge.) De plus, si vous utilisez DHCP, un serveur DHCP (en l'absence d'un ID client suffisamment unique) pourrait attribuer un adresse IPv4 en double, ce qui pourrait être problématique.

D'un autre côté, IPv6 base automatiquement les adresses configurées sur l'adresse MAC . IPv6 inclut également le concept de détection d'adresse en double , ce qui signifie qu'une adresse MAC en double peut provoquer les effets suivants (selon RFC 4862 section 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).

— mpontillo
source

Il existe des commutateurs de couche 3 qui acheminent en fonction de l'IP et non du MAC.

— Patrick

@Patrick Les commutateurs de couche 3 sur lesquels j'ai travaillé utilisent toujours des adresses MAC sur la couche 2. Quand ils disent «commutateur de couche 3», ils signifient généralement que le matériel de commutation sait également comment acheminer le trafic sur la couche 3. (agir comme un routeur IP ) Le trafic routé au niveau de la couche 3 est traité différemment du trafic commuté au niveau de la couche 2. (les paquets routés entrant ne peuvent donc pas être affectés par la perte de paquets, mais les paquets commutés de la couche 2 sur le même réseau le seraient.) Mais de quel commutateur spécifique parlez-vous ?

— mpontillo