OpenVPN: why is the PtP address not being pinged?

Question

openvpn

I wanted to deal with OpenVPN.
I generated certificates, set up the server using the default config that comes with OpenVPN, the tun interface is up and everything seems to be working, but I can’t understand why it works like this.
The bottom line is this: in the server config there is a directive " server 172.31.1.0 255.255.255.0 " when the server starts, the following interface will rise:

~$ ip addr list tun0
24: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 172.31.1.1 peer 172.31.1.2/32 scope global tun0
       valid_lft forever preferred_lft forever
~$

On the client, in turn, the following interface will rise:

~$ ip addr list tun0
23: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 172.31.1.6 peer 172.31.1.5/32 scope global tun0
~$

I saw something familiar in these IP addresses, but I didn’t immediately understand what was happening, the network search clarified the situation with addresses, it turns out that the server cut the 172.31.1.0/24 subnet into 172.31.1.0/30 and 172.31.1.4/30 subnets and assigned the first IP from these subnets as its IP and client IP, and the second address as the peer's address. And everything would be fine, but the address of the feast does not respond. Neither 172.31.1.2 nor 172.31.1.5 and this confuses me. That is, he should not ping in this situation, the logic suggests that the IP on the client should be 172.31.1.2 , and the peer address is 172.31.1.1 and then everything will fall into place. At the same time, the server is successfully pinged from the client by its IP172.31.1.1 , and the client pings from the server on its IP 172.31.1.6 .
A colleague has an OpenVPN server on Mikrotik, it uses the tun interface, and when connected to it on a laptop, the following interface will come up:

~$ ip addr list tun0
23: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 172.16.1.29 peer 172.16.1.30/32 scope global tun0
~$

And the feast quite successfully responds. Several clients can connect to Mikrotik (unfortunately, neither the version of OpenVPN on Mikrotik nor what its config looks like in the near future will be known).
Why is this happening and how can I make it so that I can ping the peer?

Answer 1

Thanks, @ValdikSS
Yes, topology is what you need (and even better it turned out to be possible to assign tun to interface IP 172.30.1.1/24). What an inconspicuous option, for some reason I haven’t seen it before, but I don’t know what to look for in the documentation, you won’t either ... I
found out that the developers recommend using subnet topology , but do not assign it by default for backward compatibility, the default is just a confusing way of cutting into /30 subnets. In order for the peer address to be pinged, topology ptp should be used , then an authentic tunnel will be obtained.
Here is the actual interface on the server:

~$ ip addr list dev tun1
45: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 172.30.1.1/24 brd 172.30.1.255 scope global tun1
       valid_lft forever preferred_lft forever
~$

And this is on the client:

~$ ip addr list dev tun1
32: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 172.30.1.2/24 brd 172.30.1.255 scope global tun1
~$

And the routing table looks less confusing. It used to be something like this:

172.31.1.1 via 172.31.1.5 dev tun0 
172.31.1.5 dev tun0  proto kernel  scope link  src 172.31.1.6

Now for the brevity itself:

172.30.1.0/24 dev tun1  proto kernel  scope link  src 172.30.1.2