According to this Heficed's KB article:
When you have bought a server with a main IP and assigned additional
IPs, additional IPs are routed statically on your main IPs, thus no
gateway or broadcast addresses are needed when configuring the IPs on
your NIC.
server1's main IP address is used to reach other IP addresses, so one can imagine server1's router (if it were Linux too) has probably a setting similar to this:
ip route add 192.0.2.160/27 via 203.0.113.43
There's no need to have eth0 bridged and having it bridged will create additional difficulties for the goal. The complexity needed to have to use anyway uncommon routing in the end (still using a gateway not part of the IP LAN) is not worth it.
So server1's network configuration can be simplified into:
auto eth0
iface eth0 inet static
address 203.0.113.43
netmask 255.255.255.0
gateway 203.0.113.1
Beware of connectivity loss when changing configuration, you should have a remote/virtual console access available as backup.
Below are solutions without bridging the host's main interface, using routing, either with TAP (possibly allowing for example server1 to run a DHCP server for server2's side) or with TUN.
To keep the 32 IP addresses available, some unusual route settings are used, for which OpenVPN has a few issues. So a script is used to override the --ifconfig option. If one chooses to sacrifice 3 IP addresses from the /32 pool: one assigned to server1 as well as 192.0.2.160 and 192.0.2.191 used as network and broadcast network addresses then everything becomes simple and there's no need of additional script.
Notes:
To configure server1 as an IPv4 router, required for any of the methods described below, one can for example uncomment/add this entry in /etc/sysctl.conf or /etc/sysctl.d/<somefile>:
net.ipv4.ip_forward=1
and also run this as root just after the configuration was changed:
sysctl -w net.ipv4.ip_forward=1
commands evolve:
openvpn --mktun --dev {tap,tun}0
can be replaced with one of these:
ip tuntap add dev tap0 mode tap
ip tuntap add dev tun0 mode tun
ip tuntap appeared "only" in 2009.
TAP
Simple method
To stay really simple, no permanent TAP interface is used (feel free to change this configuration).
It will consume 192.0.2.160, 192.0.2.161 (assigned to server1) and 192.0.2.191 out of the pool.
server1:
openvpn --dev tap --ifconfig 192.0.2.161 255.255.255.224
server2:
openvpn --remote 203.0.113.43 --dev tap --ifconfig 192.0.2.162 255.255.255.224 --route-gateway 192.0.2.161 --redirect-gateway def1
You could also add any of the 28 remaining IP addresses between 192.0.2.163 and 192.0.2.190 to server2 on any of its interfaces (eg: assign it on tap0 or assign it on lo so it won't disappear even before):
ip address add 192.0.2.163/32 dev lo
Method keeping all 32 addresses usable
server1:
Add a TAP interface in /etc/network/interfaces to simplify server1's OpenVPN's config:
auto tap0
iface tap0 inet static
pre-up ip tuntap add dev tap0 mode tap || :
address 10.10.10.10/32
up ip route add 192.0.2.160/27 dev tap0
down ip link delete dev tap0
Run ifup tap0 if just done and run:
openvpn --dev tap0
server2:
have an executable called up-cmd-server2.sh (the variables used inside will be inherited from OpenVPN):
#!/bin/sh
ip address add "$ifconfig_local"/32 dev "$dev"
ip link set dev "$dev" up
ip route add "$route_vpn_gateway"/32 dev "$dev"
and run:
openvpn --remote 203.0.113.43 --dev tap --ifconfig-noexec --ifconfig 192.0.2.160 255.255.255.255 --route-gateway 10.10.10.10 --redirect-gateway def1 --script-security 2 --up up-cmd-server2.sh
The IP address 10.10.10.10 will never be seen outside of the VPN, and even inside will only be seen in case of errors, like in the result of a traceroute command or of course if it's used to reach server1 from the VPN rather than from Internet. A traceroute run from outside would show errors from 203.0.113.43.
What about having containers or VMs on server1?
If some traffic should be routed over the VPN and some traffic be local, then tap0 above can again be enslaved to a bridge. This bridge will still be for a routed LAN: it will not bridge eth0 and 10.10.10.10/32 should be assigned to it instead of tap0. Beside this, above settings and explanations still apply. Containers can use veth links and VMs additional TAP links, all enslaved to the bridge.
TUN
TAP is useful if properties related to using Ethernet over the tunnel are needed like having server1 run a DHCP server for server2 or actually share LAN traffic over the VPN (TUN could be used for mixed use too with a few more route tweaks and proxy ARP, but it's then probably not worth the configuration complexity). Else TUN can be used with less overhead (eg: IP packet smaller than Ethernet frame and no ARP). As both cases are routing, the settings are almost the same as above.
Simple method
server1:
openvpn --dev tun --topology subnet --ifconfig 192.0.2.161 255.255.255.224
server2:
openvpn --remote 203.0.113.43 --dev tun --topology subnet --ifconfig 192.0.2.162 255.255.255.224 --route-gateway 192.0.2.161 --redirect-gateway def1
Method keeping all 32 addresses usable
server1:
Add a TUN interface in /etc/network/interfaces to simplify server1's OpenVPN's config:
auto tun0
iface tun0 inet static
pre-up ip tuntap add dev tun0 mode tun || :
address 10.10.10.10/32
up ip route add 192.0.2.160/27 dev tun0
down ip link delete dev tun0
Run ifup tun0 if just done and run:
openvpn --dev tun0
server2:
Use the same up-cmd-server2.sh as above in the TAP version and run:
openvpn --remote 203.0.113.43 --dev tun --topology subnet --ifconfig-noexec --ifconfig 192.0.2.160 255.255.255.255 --route-gateway 10.10.10.10 --redirect-gateway def1 --script-security 2 --up up-cmd-server2.sh
