vantage6 / vantage6

The main vantage6 repository: code for the central server, nodes, CLI and Python Client
Apache License 2.0
27 stars 10 forks source link

[Change Request] Compatibility with EduVPN v3 #1180

Open dsmits opened 3 months ago

dsmits commented 3 months ago

Currently v6 works with eduvpn v2. However, eduvpn v2 is not compatible with the newer linux distro's. It would be great if vantage6 could be compatible with eduvpn v3 as well. In this issue I will dump all the changes that need to be made in order to make eduvpn v3 work with vantage6.

Api calls

Endpoint discovery

Important endpoints (api endpoint, authorization endpoint and token endpoint) are listed at /.well-known/vpn-user-portal (see server endpoint discovery) The application MUST retrieve this document at least once per application run. This endpoint also tells you which version of eduvpn is running.

Mapping from v2 to v3

The vantage6 server does a number of calls to the vpn server. These need to be mapped as follows:

eduvpn v2 eduvpn v3 link comment
POST portal_url/_form/auth/verify portal_url/_user_pass_auth/verify Authentication
GET portal_url/_oauth/authorize portal_url/oauth/authorize
POST portal_url/oauth.php/token portal_url/oauth/token
GET api.php/profile_list vpn-user-portal/api/v3/ info
GET api.php/profile_config
POST api.php/create_keypair vpn-user-portal/api/v3/connect connect

EduVPN configuration

Original way to configure vpn is to edit /etc/vpn-server-api/config.php. However, the folder vpn-server-api does not exist anymore. However there is now another configuration file at /etc/apache2/conf-available/vpn-user-portal.conf. This file contains a whitelist for admin-api based on ip addresses.

Client registration

Client registration is different from before. A json file now needs to be created in /etc/vpn-user-portal/oauth_client_db.json.

Firewall rules

Firewall rules are now configured with nftables. Config file can be found in /et/nftables.conf for debian/ubuntu and /etc/sysconfig/nftables.conf for Fedora/EL.

SSH access

It is probably a good idea to restrict ssh access. The eduvpn documentation describes how to do this.

Client to client traffic

In order to enable algorithms to talk to eachother, client-to-client traffic needs to be enabled. The way to do this is I think to modify the chain forward rule in nftables.conf to:

        chain forward {
                type filter hook forward priority filter; policy drop;
                tcp flags syn tcp option maxseg size set rt mtu
                ct state vmap { invalid : drop, established : accept, related : accept }
                iifname { "tun0", "tun1", "wg0" } oifname {"tun0", "tun1", "wg0" } accept
        }

This way, traffic from the vpn interfaces tun0 and tun1 (probably for openvpn) and wg0 (I assume for wireguard) can only be fowarded to these same interfaces. This will also restrict traffic to the outside world.

dsmits commented 3 months ago

@frankcorneliusmartin @bartvanb do you think I've listed all the api calls to the eduvpn server?

bartvanb commented 2 months ago

I think that you have listed the API calls but it has been a while that I looked at it - what I do know for sure is that all API calls are done in resource/vpn.py.

Are you planning to keep EduVPN v2 support? That might be useful for not having to switch on short term, and I expect that should be rather straightforward. Also, I think it would be good to mention that a fair bit of documentation should be updated when completing this work.

On a side note, I think it would be good to mention that I don't expect Frank or me to be working on this soon, as we have other priorities for now.