Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client-connect Deferred #632

Open
mimesm opened this issue Oct 25, 2024 · 5 comments
Open

Client-connect Deferred #632

mimesm opened this issue Oct 25, 2024 · 5 comments

Comments

@mimesm
Copy link

mimesm commented Oct 25, 2024

‏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
Copy link
Contributor

cron2 commented Oct 25, 2024

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
Copy link
Author

mimesm commented Oct 25, 2024

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
Copy link
Contributor

cron2 commented Oct 25, 2024

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
Copy link
Author

mimesm commented Oct 25, 2024

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
Copy link
Contributor

cron2 commented Oct 25, 2024

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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants