-
Notifications
You must be signed in to change notification settings - Fork 406
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
On selecting server/remote from the GUI #452
Comments
I played recently with RiseUP VPN. It negotiates peers list via json communication. can we review aproaches of RiseUP VPN ? |
IIUC, what you have in mind would require a tight control on the config file (like constructing it from scratch, or massively re-writing it) before passing it to the OpenVPN command line. In OpenVPN-GUI, we impose almost no limitations on the config file, let the daemon decide what is allowed, and strongly depend on what the daemon provides via the management interface. Changing that would make a different UI. OpenVPN daemon (core) does not support selecting an arbitrary remote. One is limited by the semantics of "remote SKIP", "remote ACCEPT" and "remote MOD host port" commands. The latter gives the impression that any user-defined value can be set, but, in practice, it does not work that way. What you have in mind could be supported by having the remote list constructed by the GUI, and then passing preferred ones or the selected one at start as a "--remote host port protocol" option. But that would work only if the config file has no --remote option specified. Some niceties like remembering previous selection can be easily added though. |
also what comes to mind from AirVPN and NordVPN, small country flag is displayed for each connection. I'm pretty sure it is some arbitrary graphic image. dealing with "udp 1194" is not comfortable as dealing with icons |
I'm closing this as the required patches to the core never got enough traction. See above for details. |
Hi,
On Sat, Dec 17, 2022 at 03:09:37PM -0800, Selva Nair wrote:
I'm closing this as the required patches to the core never got enough traction. See [above](#452 (comment)) for details.
Can revisit when the situation changes.
Sorry for that. I tried, but this did not proceed due to lack of
review capacity. Please leave the issue open, and feel free to poke
me or @schwabe occasionally.
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany ***@***.***
|
An experimental support for using
--management-query-remote
with the GUI is here:https://github.com/selvanair/openvpn-gui/tree/query-remote-v2
Comments / tests would be much appreciated.
Depends on two proposed changes to OpenVPN core:
(i) Have an option to query the daemon for the list of remotes available
We could work around this by parsing the connection entries / remotes in the config file , but querying this via management looks more logical, and more reliable to me. If
remote-random
is in use, parsing the config is not an option as ordering consistent with the daemon is important for an efficient implementation (see (ii) below).https://patchwork.openvpn.net/patch/1942/
(ii) Extend the "remote SKIP" management command to take an argument for skipping multiple remotes.
Without this,
--management-query-remote
is pretty much unusable when there are more than couple of remote entries. Each command sent to the management takes up to a second to get acted on causing long delays if a large number of remotes have to be skipped one by one. This also requires a consistent ordering of the remote entries in the daemon and the GUI.https://patchwork.openvpn.net/patch/1945/
OpenVPN feature branch including these patches: https://github.com/selvanair/openvpn/tree/query-remote
The list could be sorted alphabetically by clicking on any column header. A location icon could be added to the list but currently there is no support in the config file for such metadata in connection entries.
The text was updated successfully, but these errors were encountered: