Static IP over L2 OpenVPN tunnel - what's missing and why doesn't it work?

Question

openvpn

Situation: there is a VPS with a white IP and there is a certain student project that lives deep in the campus network under two NATs, i.e. not accessible from the outside.

Task: the ability to access the project from the outside from the Internet (from home, for example).
General solution strategy: buy 2 more white IP addresses for VPS and forward at least one of them using OpenVPN to the project server.
Solution steps: Two white IP addresses from the IP1 and IP2 ranges are purchased. They are on the same /24 subnet, that is, apparently, the VPS was simply included in such a VLAN, where reserve addresses are found. IP Forwarding on VPS is enabled.
At first, I set up an OpenVPN tunnel in dev tun (l3) mode, assigning these white addresses to both ends of it. The tunnel itself worked, but the problem arose in the fact that in this VLAN, in which both of these addresses were sitting, the router constantly sent ARP who-has to both addresses (and others) and, of course, only that end could respond to such requests tunnel that was on the VPS itself. The second one could not, because ARP does not go through L3 tunnels, and without this, the router did not know the MAC and could not send IP packets to it.
All right... I lift the tunnel in the dev tap (L2) mode. Here is the server config

proto           tcp4-server
bind            XXX.9.71.223
cipher          AES-256-CBC
dev             tap
secret          /etc/openvpn/static.key

Here is the client

proto           tcp4-client
remote          XXX.9.71.223
cipher          AES-256-CBC
dev             tap
secret          /etc/openvpn/static.key

Everything is minimalistic. I check the tunnel - it works. Well, that is, IPv6 NDP is starting to rush and something else from both ends. Next - on the VPS I make a bridge from eth0 and tap0, I transfer all the settings from eth0 to br0 so that everything works as before. I raise tap0 on the VPS side - and on tap0 on the other side of the tunnel, many ARP requests begin to go, including those on IP1 and IP2. Well! So, you need to check if the answers are returned. I hang tcpdump on both ends of the tunnel and configure that end on the project side to the IP1 address. I see in the dumps that the ARP responses have gone. The router still does not send IP packets to the IP1 address in this vlan. That is, how - I do a ping from the outside to this address, knowing that there will be no answer (because on the project server, access to the Internet through two NATs with a completely different address) but an echo request, logically, I should see both on the VPS and on the other end of the tunnel. But he's not there.
I forgot something, missed it, or misunderstood it... Just what?
I'm sorry for the not very clear wording of the task, but - yes, I want to forward the white address through the tunnel to issue it to the project server.

Answer 1

I understood the question, but I didn’t master your decision,
I wouldn’t do tap at all and other br0
, everything can be simply routed
according to this scheme:
everything is solved by simple routing
on your server C, assign IP1 to the lo1 interface
sudo ip link add name lo1 type dummy , set
up an openvpn tunnel (B server, C client and do not forget to push "redirect-gateway def1" in the config)
on ​​host B, specify a static route to IP1 to the tunnel
Next, ask the person who issued the IP1 address how it is routed to A.
if as a host route where next-hop points to host B, then everything should already work.
if it was just reserved for you in VLAN (link1) without a separate route, then there are two ways

1. proxy-arp i.e. interface B must respond to arp for host IP1 with its mac
   
2. announce IP1 dynamics
   

Answer 2

Yes, it turned out beautifully. That is, after all, it turned out that it was possible to lift this entire structure to L3, and not L2.
I had to tweak your method a bit and it worked. It turns out that the static proxyARP is raised quite by the regular means of the OS, the cat might think.
First, there was no need to create dummy interfaces - I hung both white IPs on both ends of tun0/tun0.
Secondly, the static route on the server B OpenVPN prescribes itself, if you specify the p2p topology in its settings
. Thirdly, most likely, you will have to use redirect-gateway on the client side without def1, because there is also an interface with a local address, in which the change of the default gateway causes misunderstanding. I will experiment.
Thank you very much!