The key is encapsulation and frame-IP conflict.

It's a bit confusing recently! The technology used in this article is not standard, so be cautious with it !!
In a LAN, can two machines have the same IP address?
Is this an IP address conflict? Of course not!
But you need to know that you can do it if you want to do something!
The first thing to understand is the characteristics of IP datagram transmission over Ethernet:
For sending: as long as you have a target MAC address for encapsulation into a frame, it can be sent, and the MAC address is obtained by ARP;
For receiving: as long as the target MAC address of the NIC that receives the frame is the MAC address of the NIC that receives the frame, it can be correctly received!
Now, we gradually implement a scenario where the same IP address in the LAN can still access different Internet addresses through the default gateway. In fact, in my short SDN implementation, everything is saved in conntrack. It can even save the previous and next hops of a stream, this means that the local routing logic and ARP logic are completely overhead! Completely degraded the local machine into a switch! Focus on packet forwarding! The definition of neighbor is secondary. There is no need to copy the neighbor structure of the Linux kernel. It is essentially a MAC address. The idea is simple:
1. The stream header enters the prerouting in the positive direction and stores its source MAC address in conntrack;
2. Obtain the MAC address in conntrack in the backward postrouting of data packets of the same stream as the target MAC address;
3. Send and return stolen.
That's easy! In fact, it would be nice to implement policy ARP in Linux. That is to say, multiple ARP entries can be mapped to the same IP address, each of which has a different MAC address. After all, neighbor is associated with the dst_entry, that is, the route table items. Therefore, you only need to ensure that multiple ARP Mappings of the same IP address belong to different route table items, this is easily achieved through ipmark + Policy Routing!
Unfortunately, Linux does not implement a policy ARP that is so confusing. The existing isolation measures are to use the net namespace. However, it is used for virtualization, the same Nic can only belong to the same namespace. This scenario is not applicable! So what should we do? I can only write the netfilter code by myself. Fortunately, the logic is super clear, so it is easy to make changes. If we achieve this, we will look up and laugh at address conflicts!
Save the source MAC address at the end of ipv4_conntrack_in, and restore the saved MAC address to the target MAC address in ipv4_confirm. The Code is as follows:

// Continue to borrow the extendstruct nf_conn_nat from the NAT refresh column {// automatically save the target MAC address of the Reply frame unsigned char reply_gw_mac [eth_alen]; // automatically save the local MAC address unsigned char orig_gw_mac [eth_alen]; // automatically save the device struct net_device * dev;}; static unsigned int ipv4_conntrack_in (unsigned int hooknum, struct sk_buff * SKB, const struct net_device * In, const struct net_device * Out, INT (* okfn) (struct sk_buff *) {unsigned int ret = nf_conntrack_in (dev_net (in ), Pf_inet, hooknum, SKB); If (ret = nf_accept) {Enum packet ctinfo; struct nf_conn * CT; struct nf_conn_nat * automac; Ct = nf_ct_get (SKB, & ctinfo ); if (! CT) {goto out;} If (SKB-> Dev-> flags & iff_loopback) return ret; If (ctinfo2dir (ctinfo )! = Signature) {goto out;} automac = nf_ct_ext_find (CT, nf_ct_ext_nat); If (automac = NULL) {automac = nf_ct_ext_add (CT, nf_ct_ext_nat, gfp_atomic ); if (automac = NULL) {goto out;} struct ethhdr * Eth = (struct ethhdr *) (SKB-> data-eth_hlen); memcpy (automac-> reply_gw_mac, ETH-> h_source, eth_alen); memcpy (automac-> orig_gw_mac, Eth-> h_dest, eth_alen); automac-> Dev = SKB-> dev;} Out: Ret Urn ret;} static unsigned int limit 4_confirm (unsigned int hooknum, struct sk_buff * SKB, const struct net_device * In, const struct net_device * Out, INT (* okfn) (struct sk_buff *)){............. out:/* we 've seen it coming out the other side: Confirm it */ret = nf_conntrack_confirm (SKB); If (ret = nf_accept) {struct nf_conn_nat * automac = NULL; struct net_device * Dev = NULL; unsigned int hh_len = 0; If (SKB-> Dev-> flags & iff_loopback) return ret; If (ctinfo2dir (ctinfo) = ip_ct_dir_original) return ret; If (hooknum! = Nf_inet_post_routing) return ret; automac = nf_ct_ext_find (CT, nf_ct_ext_nat); If (automac = NULL) return ret; Dev = automac-> dev; SKB-> Dev = dev; hh_len = fig (Dev); If (unlikely (skb_headroom (SKB) 
Note: As long as a package arrives in the box, its source MAC address can be remembered by conntrack. When a package arrives in the opposite direction and needs to be sent back, the source MAC address can be extracted and encapsulated into the Ethernet frame as the target MAC address, and then sent directly through the ARP layer. Now the question is, can two hosts with the same IP address send packets at the same time? The answer is no doubt yes, because the two of them resolve the MAC address of the box before sending the package, the box will no doubt reply all, they will always come first, when the only side effect arrives, the ARP request will update the ARP table of the box and overwrite the MAC address of the same IP address into its own MAC address. However, this does not matter, since the two hosts get the MAC address of the box, the packet must be sent out to the box. When the return packet is addressing the two machines, it is not addressed through arp, instead, the two machines carry their own source MAC addresses as the target MAC address, so it doesn't matter if we overwrite them!
As long as there is no quintuple conflict, the possibility of such a conflict is extremely small.
Strictly speaking, ARP belongs to the lower layer of the IP and is a protocol used for the link layer interface. It is a "Next Hop Resolution Protocol" and is suitable for IPv4 to Ethernet adaptation, ARP dynamically completes the ing. If you know how to encapsulate an Ethernet frame, you can either manually set static ing or obtain a ing from somewhere, the key point is not ARP or ing. The key point is that you can get a MAC address! As long as you can get the target MAC address, you can encapsulate the ethereum. At this time, you do not care about the source MAC address!
I am really confused, whether it's using the MAC bridge micro port to get the source address selection of openvpn, or constructing a false gateway to specify the source address When configuring a Windows route, or the data communication in the IP address conflict scenario described in this article, none of them are standard practices. I hope you will pay more attention to them. If you want to understand the behavior of the network, it would be better...