Client-connect Deferred

[mimesm]

‏Hello,

‏We implemented client-connect deferred based on the documentation and sample code provided in this repository, without setting any environment variables as mentioned in the README.

‏Currently, we’re encountering an issue: instead of handling connections in a truly deferred manner, the plugin operates asynchronously. This allows clients to connect immediately, and only afterward does the plugin carry out the intended client-connect logic.

‏Our goal is to have clients wait until the client-connect process completes, so they aren’t fully connected until the plugin determines whether they should be granted access or rejected. In other words, we need a solution where client-connect can run without stalling the main OpenVPN thread, while still controlling the client’s access based on the client-connect outcome.

‏Could you please guide us on how to achieve this behavior?

‏Thank you very much!

[cron2]

This is really not what the issue tracker is for (tracking bugs, not answering user question).

If your script runs truly async, and OpenVPN is not waiting for it, you forgot to tell OpenVPN that you want to do deferred operations.

One of my test scripts does approximately this:

#!/bin/sh

# tell server we want deferred handling (= it should regularily
# check that file for updates
echo 2 >$client_connect_deferred_file

(
         # ... run client things in background process
        ...
        # signal success (1) or failure (0) to openvpn process
        echo $ret >$client_connect_deferred_file
) &

# parent process
exit 0

[mimesm]

Hello,

Thank you very much for your response. I understand the issue now. However, I have an additional question regarding how this is handled in the plugin.

Could you please explain the differences between client_connect_v1, client_connect_v2, and client_connect_defer? Additionally, could you clarify which of these are compatible with API version 2?

I would also appreciate an explanation on how to implement each of these.

[cron2]

Look at sample/plugins/sample-client-connect.c - it's basically a test/demo plugin that can behave in any desired way (sync/deferred, succeed/fail) by setting environment variables. So it has all the code paths.

There also is a README that explains how to excercise it, and extensive comments in the .c file that explain the difference between v1 and v2, which is mostly the way arguments and return values are passed. ..._defer_v2() plays together with ..._connect_v2() to signal return status, while ..._connect() (v1) is file based, without an extra query function.

[mimesm]

Thank you very much. I reviewed the file, but when I checked, I noticed that the environment variables were not set. Should we manually set these values, and are they necessary for the functionality?

Additionally, I have another question: is it possible to run connect_v2 in a truly deferred manner on its own, or does it require connect_v2_defer?

Lastly, is version 2 compatible only with API V3?

I would be grateful if you could provide more details.

Thank you for your assistance.

[cron2]

The UV_* env variables can be set by a connecting client or by setenv in the server.conf to get the behaviour from the sample script that you want. This is a demo script that can do everything - succeed, fail, sync, deferred - so you use the env vars to make it do what you want. For your own script, or plugin, these are not needed (unless you want to have something like a config setting via setenv MY_PLUGIN_THING ... in the server.config). Since there is no real "functionality" in the sample plugin, the question "are they necesary for the functionality?" is not trivially answered...

connect_v2 needs connect_v2_defer to signal the result back to OpenVPN (because no control files). If you want to fork something external which can easily write control files, use connect (v1).

No idea about API versions (I would need to go and read files), but I'm not sure why this is a relevant question. The script, as provided, works with OpenVPN 2.5 and up (and anything earlier does not have deferred client-connect yet). So "this is the API version you want to use".