On Mon, Nov 15, 2021 at 1:42 PM Rui Santos <rsan...@ruisantos.com> wrote:
> 0 > > On 15/11/21 17:06, Jan Just Keijser wrote: > > Hi Rui, > > > > > Hello Jan! Thanks for getting back to me :) > > > this is indeed what you use the management interface for. Read up at e.g. > > https://openvpn.net/community-resources/management-interface/ > > > > the command is > > kill <client-CN> > > or > > kill <client-IP>:<port> > > > > You can query the list of existing connected clients using the > > status > > command. > Yes, I did all that. The problem with that is that, by using those > commands, I was never able to "tell" the client to connect to the next > server. With the approach you mentioned, the client will 1st try to > connect to the same server it was initially connected to. What I need, > is for the client to connect to the "next" server on the connection > list, compose of several --remote directives. > > However, in the meantime, and getting desperate, I went to look at the > source code, to see how exactly, the --explicit-exit-notify directive > actually accomplishes it. And I found out how to successfully do it. For > the record, and all good and helping people of the open community, > here's the solution: > 1. Open the management interface > 2. Get CID > 3. Issue: client-kill <CID> RESTART,[N] > > Hope this will help someone else :) > > Now, what I still miss to accomplish, is bullet number 2: How to make a > client connect to the next server, without trying the server he was > connected to in the 1st place. > This is useful, for example: Imagine a server has a network issue of > some sort, and a ping-timeout happens on the client (normal behavior). > Now what the client actually does, is 1st try to connect to the same > server, which is down. Although the client will eventually connect to > the next server, it will take some time to figure out that the current > server is actually down, thus leaving the network behind the client, > without a working tunnel for longer. > How can this be tweaked? > I do not know any way of avoiding the retry of the current remote once on ping-restart. You could probably alleviate the issue somewhat by using a short "--server-poll-timeout". The default is pretty long (60 sec or 120sec for UDP?). But too small a value would cause unwanted failures. That said, ping restart also takes a while to trigger, so there is not much you can do to avoid a period of broken tunnel. Selva
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
