openvpn issueshttps://0xacab.org/leap/container-platform/openvpn/-/issues2024-01-27T05:06:38Zhttps://0xacab.org/leap/container-platform/openvpn/-/issues/7rate limit torrents/p2p2024-01-27T05:06:38Ztaggartrate limit torrents/p2pEver since riseup deployed the vpn we have endpoints that are saturated by torrent traffic. We have continued to add endpoints(19 so far!), but it seems no matter how many we add they get filled. These endpoints being saturated probably ...Ever since riseup deployed the vpn we have endpoints that are saturated by torrent traffic. We have continued to add endpoints(19 so far!), but it seems no matter how many we add they get filled. These endpoints being saturated probably means a worse user experience (but we also don't have a good way of measuring that currently).
Looking at the connection tracking numbers, our endpoints have between 20k-76k entries, while connected users varies from 150-900. These endpoints could support more users and provide more bandwidth per user if the few users torrenting weren't using all the bandwidth. I don't think we need to flat out ban torrents, but I would like it if we could rate limit by client somehow. I did a little research on approaches to this:
* Some use DPI to try to id this type of traffic and then setup firewall rules to block/shape that traffic. But the main solutions I found for this are all old iptables classifier things like ipp2p, L7-filter, opendpi that are abandoned upstream. This would limit only the problematic traffic which is nice.
* Some people used hooks in openvpn to run scripts on each client connecting/disconnecting to setup `tc` shaping. [example](https://serverfault.com/questions/701194/limit-throttle-per-user-openvpn-bandwidth-using-tc). This would limit all traffic per client.
* openvpn itself has a `--shaper` option, however this requires that openvpn but running in `p2p` mode and we currently use `subnet`. Also this only limits outbound traffic, inbound would need to be limited on the client which we don't always control (but many people use the client as is, might still work). So this means (if the client isn't also shaping) someone torrenting might have slow downloads, but their seeding would not be limited. This still might be enough if it gets them to stop torrenting over the vpn. This would also limit all traffic per client.
I suspect all we really need to do it get the worst abusers to move somewhere else and things will get a lot better for everyone else.https://0xacab.org/leap/container-platform/openvpn/-/issues/4use --tls-auth/--tls-crypt for openvpn2022-10-12T07:54:38ZKali Kanekouse --tls-auth/--tls-crypt for openvpnI'd like us to start using `--tls-auth`.
From the documentation:
```
Add an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks
and attacks on the TLS stack. In a nutshell, --tls-auth en...I'd like us to start using `--tls-auth`.
From the documentation:
```
Add an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks
and attacks on the TLS stack. In a nutshell, --tls-auth enables a kind of "HMAC firewall" on
OpenVPN's TCP/UDP port, where TLS control channel packets bearing an incorrect HMAC signature can be dropped
immediately without response.
```
If I'm seeing this correctly, this is a backwards-incompatible change, so besides generating and distributing the tls-auth key, we need to devise a way of gradually implementing that - and stop supporting it at a given platform:client version.
I think the path of less resistance (for this and other backward-incompatible changes) is to 1. group together all the changes for api major changes, 2. add a tag to specific gateways (so that newer client can just select those), 3. issue deprecation warnings for clients (and providers) that are still stuck on old api versions.
I think we can try to coordinate this change for `v3` of the api.https://0xacab.org/leap/container-platform/openvpn/-/issues/3Explore a way to use more than one CPU2022-03-08T18:26:15ZKali KanekoExplore a way to use more than one CPUWe believe this might be the most important single optimization that we can do for openvpn performance in the platform side.
As far as I know, there are no open-source solutions for a server-side coordinator that is able to scale to all ...We believe this might be the most important single optimization that we can do for openvpn performance in the platform side.
As far as I know, there are no open-source solutions for a server-side coordinator that is able to scale to all available cores.
One possible, easy (and perhaps too simplistic) way that we see would be to dynamically generate configuration files for the process supervisor inside a single container, with a predefined tcp+udp port sequence (and inform vpnweb + menshen of this, so that each ip:port is treated like a separate location for load balancing purposes).
This is currently done with chaperone, but @micah is considering a switch to s6:
see: https://github.com/just-containers/s6-overlay#the-docker-way