search

a-barinov / liteqube

Liteqube - put Qubes OS on a diet
52 stars 5 forks source link

vpn stability issues #8

Closed dostisurta closed 1 year ago

dostisurta commented 2 years ago

I'm trying the vpn-ssh functionality but I find it very unstable. At first I couldn't connect at all, failing on the split-ssh part. After some tinkering I increased the memory available to core-keys and core-vpn-ssh and worked ok for a while but after a few minutes I lost connection again. Core-keys keeps shutting down by itself, then the split-ssh dialog appears, turns on core-keys and maybe restores connectivity for a little while or, I believe some timeout happens and no connection is made. I turn on core-keys manually at boot because I want it to be ready every time I need it. I don't know if the shutting down behavior is intended (turn on, split-something, turn off) or it's something failing.. Please advise

Also a few things to note:

regards

a-barinov commented 2 years ago

Surprised to hear core-keys needs more memory for you. It runs nicely for me with 128Mb. Two possible reasons come to my mind:

  1. I limit video memory allocated to qubes to 16Mb with qvm-features dom0 gui-videoram-min 16384 qvm-features dom0 gui-videoram-overhead 0 You may have more memory allocated by default, this will be deducted from your qube memory.
  2. You have some services running in core-keys that take up memory. You should only have the following enabled in debian-core: multi-user.target.wants/qubes-sync-time.timer multi-user.target.wants/xendriverdomain.service multi-user.target.wants/qubes-mount-dirs.service multi-user.target.wants/qubes-misc-post.service multi-user.target.wants/qubes-qrexec-agent.service sysinit.target.wants/liteqube-vm-template.service sysinit.target.wants/qubes-sysinit.service sysinit.target.wants/qubes-db.service

core-keys shuts down after 2 minutes of inactivity, that's to avoid any possible attack getting persistence. You need to remove shutdown instruction from a few scripts if you want to avoid auto-shutdown:

But core-keys shutting down should not be a problem for core-vpn-ssh as ssh key is needed only once, at connection time. I suspect that you have the same problem in core-vpn-ssh as you have in core-keys: you are running out of memory. Diagnosing this is easy: just give core-vpn-ssh 512Mb of memory and see if your problems go away. If this turns out being the reason, check my advice above before you resort to increasing qube memory.

Now, to your other questions:

I left a ping running from the client vm and it never stops, making me think icmp is never routed trough the vpn.

Tunneling over ssh is done using socks proxy, which means tcp traffic only. I'm sure there other tunneling protocols that can do icmp, happy to integrate this into liteqube provided there are debian packages for client and some test server.

It is really necessary for the vpn-ssh vm to be disposable? Maybe having some little private storage could allow to have more than one vpn vm with different configurations and not pollute debian-core with vpn settings. It could be read-only.

I'd do this slightly differently. Instead of running default ssh connection on startup unconditionally (which is really handy for single connection) I can do a service that you run in core-vpn-ssh with connection name as a parameter, something like qvm-run --autostart --no-gui --service core-vpn-ssh liteqube.VpnConnect+ConnectionName. This will retain the buty of DispVM but will give you flexibility you ask for. Will this fit your use case?

Are you planning on write a more detailed documentation? I can help you with that

'One day' would be my honest answer. I still need to do a few things to call my work on liteqube generally complete:

  1. A set of mail qubes;
  2. Some form of panel applet / systray icon for wifi, tor, vpn, mail and sound;
  3. Ensure all qubes can auto-shutdown the way core-keys does it;
  4. Create scripts to save new NetworkManager connection in the same way it currently works for passwords;
  5. Add support for mic sharing from core-sound;
  6. Systemd service hardening

Until this is done, documentation will remain second priority, I'll be updating it based on my answers to the issues being raised. So yes, any help with this will be appreciated.

dostisurta commented 2 years ago

Thank you for your detailed answer. I did the following:

But no change, it starts ok and works for a few minutes and the the connection is lost (in the browser). This time I see a bunch of errors in the dom0 screen (top-right): Failed: liteqube.SplitSSH - failed to execute liteqube.SplitSSH (from core-vpn-ssh to core-keys) and then: Core-keys has shut down Core-keys has started At some point the browser starts working again, for a few more minutes. My guess is that the liteqube-vpn-ssh service is restarting itself for some unknown reason and if it core-keys is not ready to do the splits it fails (maybe waits a few seconds and timeouts). Core-keys is trapped in a loop, shutting down and starting. I tested starting the tunnel manually, entering my password and there it worked ok for a few hours, until I left. Please advice on how to debug furher. For more info, I have a vanilla brand new install of Qubes 4.1 and liteqube 9.2, no other use or config besides the tor stuff mentioned on the other tread. Installed the ssh keys by putting them on the 4.VPN/custom/keys folder, so I don't believe I ever touched core-keys.

Regarding the other questions: Sorry I didn't do a more extensive reading on socks, I'm used to openvpn where everything gets tunneled. For my use-case, icmp would be only a nice-to-have, to test and debug connections. But I do believe that not tunneled traffic should be blocked to avoid leaks. By the way, what happens with dns querys (udp)?

And regarding the multiple connection approach, I think it can be done that way also, but should have username, port and domain/ip as a parameter, or all this defined outside debian-core (imho) (maybe in core-keys)

thanks again best regards

a-barinov commented 2 years ago

Found it! core-vpn-ssh depends on netstat to detect when ssh connection gets established and restarts ssh-client otherwise. While previously one of the installed packages used to depend on net-tools that provides netstat, this is no longer the case. Therefore ssh connection does not get detected even while it's there therefore the restarts.

I'll push a commit later today to get this fixed, in the meantime just install net-tools to debian-core and ssh vpn will start working for you as expected.

BTW, if you updated to Qubes 4.1.1 then pleas also bump memory for core-net and core-sound from 192mb to 208mb otherwise these will be failing for you most likely. An installer tweak will be committed today as well.

a-barinov commented 2 years ago

Speaking of other vpn questions raised n this thread:

Since ssh provides a socks proxy only, it cannot tunnel dns requests, these go to your main dns provider. While I don't consider this to be a big issue, I'll research if there are lightweight dns-over-https proxies that would allow me forwarding dns traffic over socks proxy. Doing the same in core-net to get a better dns privacy out of the box might not be a bad solution either.

With multiple ssh profiles the only issue I have is passing parameters to systemd service, but I'm sure there is a way to do this.

I think i'll implement openvpn shortly after my summer break, seems to b a popular vpn option these days. Being able to tunnel dns and possibly icmp over it is a great advantage over ssh.

a-barinov commented 1 year ago

Latest commit supports ssh, ssh with dns-over-http and OpenVpn. VPN connection can be fixed on the fly (so multi-profile support is there)