Now im looking for a possibility to adapt the above settings, that when the vpn server change, the username / password depending on the server will also change?
something like this:
if vpn is connected to remote server2.somevpnservice.com
then use in config: User2 / Password 2
if vpn is connected to remoteserver3.somevpnservice.com
I don't believe there's any way to do this within OpenVPN itself. OpenVPN does support the connection profile directive (as described in the following document: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage ), but that apparently does NOT include the ability to specify a different username/password (specifically, the auth-user-pass directive) on a per connection basis. If it did, you'd be in business.
Although I haven't tried it myself, you could try placing the auth-user-pass directive (set with your own credentials file stored in jffs) in the Additional Config field. Then use one of the OpenVPN events ("up" or "tls-verify" look promising) where you change the credentials file w/ your up/tls-verify script just before the OpenVPN client accesses it. Of course, I'm assuming the "up" or "tls-verify" event will pass you the contents of the remote directive it selected (via an environment variable). What gets passed varies from event to event, and I've rarely used these particular events. I'm also assuming the OpenVPN process has NOT read the contents of the credentials file before calling these events. I suspect it *has* given you can't specify auth-user-path in the connection profiles (that would explain the lack of support for that directive), but don't know for sure.
Anyway, I'm not really sure the above would work. I'm just thinking off the top of my head what *I* would try if I was in your circumstances.
The only other way I know to accomplish this would be to manage the OpenVPN process yourself from the CLI (command line) and where YOU scripted those changes. IOW, you randomly choose a server, then configured the OpenVPN client, passing the auth-user-pass directive (w/ the appropriate credentials file for that server) as a command line option, or in the config file.
On a side note, rather than shutting down the OpenVPN client entirely, sleeping for 30 secs, and restarting, you could use the following, which achieves the same effect, but without the need to delay the restart. IOW, it's going to be more efficient.
It will also prevent any OpenVPN server from being restarted as well since it is specifically looking for the OpenVPN client config file in the process table. As currently configured, your cron command would likely restart *both* the OpenVPN client and server, assuming both were active.
UPDATE: I just realized that the OpenVPN client stores it process ID in the file /var/run/openvpncl.pid. So you don't need to scan the process table. Just reference it directly.
Code:
kill -s SIGUSR1 $(cat /var/run/openvpncl.pid)
Probably similarly for OpenVPN server (I'm not running OpenVPN server at the moment).
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Mon Aug 03, 2020 21:50 Post subject:
A minor aside: the cat approach is great of course, the best really, but an alternative is $(pidof openvpn). Something to note for future situations involving other processes! _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
A minor aside: the cat approach is great of course, the best really, but an alternative is $(pidof openvpn). Something to note for future situations involving other processes!
Using pidof is normally the best approach, agreed. But the problem w/ $(pidof openvpn) is that if *both* the OpenVPN client and server are running at the same time, it will return *both* process IDs. And passing that to the kill command would affect both client and server. They only differ by the directory each uses for the config file (client uses /tmp/openvpncl/openvpn.conf, server uses /tmp/openvpn/openvpn.conf).
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Mon Aug 03, 2020 23:04 Post subject:
eibgrad wrote:
SurprisedItWorks wrote:
A minor aside: the cat approach is great of course, the best really, but an alternative is $(pidof openvpn). Something to note for future situations involving other processes!
Using pidof is normally the best approach, agreed. But the problem w/ $(pidof openvpn) is that if *both* the OpenVPN client and server are running at the same time, it will return *both* process IDs. And passing that to the kill command would affect both client and server. They only differ by the directory each uses for the config file (client uses /tmp/openvpncl/openvpn.conf, server uses /tmp/openvpn/openvpn.conf).
So at least for openvpn, it's better to either scan the process table looking specifically for the relevant directory, OR, reference the file where each stores its own unique process ID.
Nice insight! Thank you! _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Did a little more checking. It appears using signals (SIGUSR1) will NOT necessarily change the server. It will force a restart on the *same* server, but you may get a different assigned ip on the tunnel.
So either using "service openvpn restart" or the OP's original way will likely change the server. However, in either case, it's likely to affect both the OpenVPN client and server if both are active at the same time (if that's not the case for you, it's not an issue).
Only thing that makes sense (if you have both the OpenVPN client and server active at the same time) is to kill the active OpenVPN process and manually restart it.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Aug 05, 2020 11:45 Post subject:
SIGHUP to the client openvpn process will restart with a server change (assuming a remote/remote-random config is in place). IIRC, it will not reread the .conf file. I've been using it for that purpose for a year or so. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
SIGHUP to the client openvpn process will restart with a server change (assuming a remote/remote-random config is in place). IIRC, it will not reread the .conf file. I've been using it for that purpose for a year or so.
As they say, you learn something new everyday.
So it appears we have …
Code:
# restart OpenVPN client (likely the same server)
kill -s SIGUSR1 $(cat /var/run/openvpncl.pid)
# restart OpenVPN client (likely a different server)
kill -s SIGHUP $(cat /var/run/openvpncl.pid)
Again, assuming you use the remote-random directive.
Funny thing though. It appears that "service openvpn restart" (and presumably the OP's method as well) results in a more random choice of servers than using SIGHUP. I suspect using SIGHUP results in the same scrambled list of servers, whereas using "service openvpn restart" or the OP's method, the list of servers gets rescrambled, resulting in a better mix (i.e., more random choice) of servers (at least when using quite a few servers; I have about twenty at the moment). Hard to be sure, but it sure feels that way when I test it.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Aug 05, 2020 13:09 Post subject:
eibgrad wrote:
Funny thing though. It appears that "service openvpn restart" (and presumably the OP's method as well) results in a more random choice of servers than using SIGHUP. I suspect using SIGHUP results in the same scrambled list of servers, whereas using "service openvpn restart" or the OP's method, the list of servers gets rescrambled, resulting in a better mix (i.e., more random choice) of servers (at least when using quite a few servers; I have about twenty at the moment). Hard to be sure, but it sure feels that way when I test it.
I actually had the same impression, but I was never sure. If SIGHUP just goes to the next entry in the prescrambled list, it means you won't happen to land on the same server again. For my purposes that's good, actually, even if it's "less random." _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
thanks so much for your information to this Topic! How can i test this out, would you give me the novice steps, please
Which do you want to test? Trying to use one of the OpenVPN events to change the username/password (which I'm not so sure will work), OR, just script the whole thing from the CLI? The latter should definitely work if only because you now have full control, but will be more complex to setup, esp. if you have little scripting experience on the router.
Frankly, even dealing w/ the OpenVPN events isn't particularly easier either. You get involved w/ scripting there as well.
I pasted the above into an ssh session *before* the OpenVPN client started (or was restarted), which created the necessary up and tls-verify scripts in the /tmp folder.
I then added the following to the Additional Config field of the OpenVPN client.
Code:
up /tmp/up
tls-verify /tmp/tls-verify
When the OpenVPN client starts, each of these events will be called at the appropriate time.
Quote:
--up
Executed after TCP/UDP socket bind and TUN/TAP open.
--tls-verify
Executed when we have a still untrusted remote peer.
Both scripts dump the environment variables passed by the OpenVPN client, so I can see what's available at that time.
In each case, among many other environment variables, I get the following in the output files.
Code:
untrusted_ip=64.185.230.171
untrusted_port=1195
What this tells me is that the OpenVPN client has already selected a specific remote (the domain name has been resolved) and port, but as yet has not attempted the connection (hence why it's untrusted). I assume a subsequent failed connection would result in a different remote+port, and these scripts would be called again. It was my *hope* the OpenVPN client had NOT yet read the credentials file, and that if I changed its contents based on the untrusted_ip and untrusted_port, it would use those changes (which for testing purposes, I just used bogus values). Unfortunately, it made no difference. The connection was established successfully. And when I checked the contents of the credentials file, it had my changes. So clearly OpenVPN client has already read the contents of the credentials file *before* these events. And as far as I can see, these are the earliest events available.
The fact you have different username/password requirements for each remote (server) strongly suggests these are NOT the same VPN provider. And if that's the case, don't you need to configure them differently in terms of their certs, keys, tls-auth, etc., as well?
That's the problem, for example, w/ NordVPN. The use of multiple remote directives doesn't work because all their servers have different certs and keys. It's why I refuse to use them.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Aug 05, 2020 22:15 Post subject:
eibgrad wrote:
That's the problem, for example, w/ NordVPN. The use of multiple remote directives doesn't work because all their servers have different certs and keys. It's why I refuse to use them.
FWIW, Nord moved to identical certs and keys a couple of years ago, though the only way you could tell was to download them all and run a giant diff script (which I did). I used the remote-random thing with them successfully -- sort of -- for months before I moved to AirVPN.
The "sort of" is because I moved to get away from Nord's practice of constantly retiring servers with no notice. I had to revise my "remote" list over and over, every few weeks basically. And the only way I could find out what was retired was to try to connect. Eventually I wrote a script to do it, but even using that was so annoying that I finally moved on to a vpn provider that's about providing a great system rather than marketing claims about having 80 bazillion servers and marketing lies about supporting Netflix. Re the latter, they apparently pay reviewers to repeat the Netflix lie. I don't need Netflix over vpn, but bold-faced lies offend me. Air makes a point of refusing to pay reviewers, so the usual review sites (you know, the awful, error-filled reviews that sound like advertisements) won't touch them. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
