search

eventure / hide.client.linux

Hide.me CLI VPN client for Linux
https://hide.me
GNU General Public License v2.0
90 stars 35 forks source link

hide.me disconnect command is missing #5

Closed kevinmrl closed 2 years ago

kevinmrl commented 3 years ago

There is a hide.me connect, but where a command for disconnect? In order to properly connect and disconnect a VPN connection using CLI

tcohar commented 3 years ago

There is no such command. Hide.me CLI will start it's shutdown on SIGINT ( CTRL-C ), SIGTERM or SIGKILL. It will clean up, disconnect and exit. If you're using Hide.me CLI as a systemd managed service then disconnecting and terminating the client is done in the same manner as with any other service: systemctl stop hide.me

kevinmrl commented 3 years ago

That's what I am trying to say..it is not a valid/proper way to not have a command which would do a proper disconnect. If you are using CLI and run command let's say automatically where is no proper way to disconnect and CTRL-C is not an option.

In short: other VPNs that provide CLI does have/provide disconnect command and here is unfortunately lacking

tcohar commented 3 years ago

When Hide.me receives a SIGINT signal ( that's what CTRL-C causes ) or SIGTERM it does a proper disconnect. We could implement a simple function which would send a terminating signal to a running instance of hide.me CLI, but that's error-prone as we can't tell which instance to actually terminate. It's much better if you do:

kill $(pidof hide.me)

This one-liner does, in fact, send SIGTERM to a hide.me CLI process. Hide.me CLI will disconnect and exit properly. Rationale behind all of this is that you could run multiple hide.me CLI instances ( each one under a different name if you wish to control them manually, ofc ) in order to establish multiple tunnels. For example, you may wish to use one server for IPv4 tunneling while some other server for IPv6 tunneling. In order to do so, you just run two instances of hide.me CLI with appropriate switches, namely -4 and -6. Such usage is perfectly fine with us. Now, combine that with SystemD and service templates you could manage those tunnels easily, monitor them or isolate them appropriately. Our solution, although it seems lacking in functionality, is way more flexible. Try to replicate this use-case with the competition's solutions ... you can't as far as I know.