I’m attempting to tunnel from a "digital interface" on Machine A to a bodily interface on Machine B. All concerned programs are Linux-based and have bridge instruments, iproute2 and related kernel choices put in. All networks depicted beneath are /24. I can not change any community settings on C and D, nor can I set up software program on them.
Machine A is behind a masquerading NAT however can attain Machine B. Machine B can not attain Machine A. Machine B has a second NIC on a subnet along with Machines C, D (and a few others).
What I plan to realize is to have a brand new community interface on Machine A that’s in the identical subnet as Machines C and D so I can ping them. Ideally a layer 2 tunnel.
Most guides I discovered assume some software program outlined switching, VMs or Kubernetes. Nothing is concerned in my case.
First thought was to create a Wireguard tunnel between Machines A and B and to bridge it to eth1 on Machine B. I have not tried that but since I learn that wireguard is layer 3 solely and thus does not help bridging.
Subsequent I learn on layer 2 tunneling potentialities: GRE, VXLAN and Geneve.
Since all appear to require that Machines A and B can speak to one another (= in each instructions), I created a Wireguard community between them. That is working and Machine A and B can ping one another on their wireguard IPs (192.168.66.0/24)
Then (on Machine B), I arrange a bridge interface br0, eliminated the IP from eth1, added eth1 to br0 and configured the IP from eth1 on br0. Pinging from B to C and D nonetheless works.
Then I attempted organising a Geneve tunnel between Machines A and B (utilizing the wireguard interfaces for "distant"), including interface geneve0 on Machine B to br0 and giving geneve0 on Machine A an IPv4 in the identical subnet as br0 on B. I don´t bear in mind the precise instructions however I feel Machine A was in a position to ping B (within the 192.168.0.0/24 subnet) however not Machines C and D and B was not in a position to ping A (unusually).
So I attempted to do the identical with VXLAN as an alternative. Instructions used:
Machine A:
ip hyperlink add vxlan0 sort vxlan id 6666 dstport 4789
ip addr add 192.168.0.210/24 dev vxlan0
ip hyperlink arrange vxlan0
bridge fdb add 00:00:00:00:00:00 dev vxlan0 dst 192.168.66.1
Machine B:
ip hyperlink add vxlan0 sort vxlan id 6666 dstport 4789
ip hyperlink arrange vxlan0
bridge fdb add 00:00:00:00:00:00 dev vxlan0 dst 192.168.66.2
brctl addif br0 vxlan0
At this level, Machine B can nonetheless ping C and D. Machine B also can ping Machine A on 192.168.0.210 (which tells me that the VXLAN appears to be working).
Machine A can ping Machine B on 192.168.0.200. Nonetheless, Machine A CAN NOT ping Machines C and D. Machine B has proxy_arp and ipv4.ip_forward enabled.
Utilizing "tcpdump -i vxlan0" on B I can see the ping requests from A to C however no replies. Nonetheless, the ARP requests are forwarded and the ARP desk on A comprises the entries with the right IPs and MACs. Utilizing "tcpdump -i eth1", I can see that the ping requests from C don’t make it out to C and D.
By some means bridging the vxlan0 to br0 works however packets are usually not forwarded to eth1 although it’s on the identical bridge as properly however I can not see what I’m lacking. Why does ARP work however ICMP not?
How would Machine A know that the MAC addresses of C and D are behind B and never another machine that might be a part of the identical VXLAN? Do I want to inform or ought to it auto-learn (like a swap that remembers which MAC addresses are on every port)?
Any concept what I might attempt subsequent? Or would there be a better strategy to realize what I would like? Thanks!