dco-linux: iroutes disappear in case of quick client reconnect

[ordex]

CONTEXT

When using DCO on Linux or BSD, iroutes are implemented by adding standard routes in the system table, having the client VPN IP as nexthop. This entries help DCO later to figure out which peer to send the traffic to.

THE ISSUE

OpenVPN process client exits in a two step fashion: first the exit/timeout is detected and a purge routine is scheduled for execution after 5 seconds. Then the timer fires and the actual purge is performed.
The DCO iroutes are deleted by the delayed purge routine.
If a peer (with iroutes configured) quickly disconnects and reconnects using the same username and gets the same IP assigned, then it will race with the delayed exit routine.
Specifically the following will happen:

• client disconnects, purged scheduled after 5s
• client reconnects immediately (within 5s) and a new instance is created
• DCO iroutes are installed, but that fails with EEXIST
• 5s timeout fires -> DCO iroutes are removed (thinking they belonged to the previous client)
• new client is fully connected, but no iroutes are in place

This behaviour exists since 2.6.x.

STEPS TO REPRODUCE

1. provision a client, say client1
2. create a ccd folder with client1 containing two entries:

ifconfig-push 10.10.0.3 255.255.255.0
iroute 8.8.8.8

The first one ensures the client always gets the same IP (picked within the server pool for simplicity).
The second one is just a random iroute to be used to demonstrate the bug.
3. launch the server with --client-config-dir and --duplicate-cn to ensure a new instance is created when the clients reconnects.
4. start the client with --explicit-exit-notify and wait for connection
5. check the system table for the iroutes
6. disconnect the client and reconnect immediately
7. watch the server to observe the behaviour described above
8. after 5s check the routing table to see the iroutes being gone

[ordex]

A fix was proposed:
https://gerrit.openvpn.net/c/openvpn/+/1682
https://gerrit.openvpn.net/c/openvpn/+/1683

The first patch is a refactoring that allows the fix to be as small as possible and easy to grasp.
The second patch is the actual fix.

The idea behind the fix is to perform invoke dco_delete_iroutes() immediately in schedule_exit(), rather than in the delayed purge routine. This way get rid of the routes right upon client disconnection and allow any other peer to take over them happily, without racing.

[ordex]

To be noted that this issue is possible only when the scheduled exit logic is activated.
This means one of the following reasons:

• EEN received
• RESTART sent
• AUTH_FAILED sent

other cases are handled without delay.