trailofbits / algo

Set up a personal VPN in the cloud
https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-that-works/
GNU Affero General Public License v3.0
28.66k stars 2.32k forks source link

Installing only Wireguard. Why so many dependencies? #1579

Closed johnnyutahh closed 5 years ago

johnnyutahh commented 5 years ago

Summary

I want to install Wireguard and nothing else (at least for now), on a DigitalOcean VPS.

Why must I specify/configure/install/whatever:

  1. dns_servers or
  2. a DigitalOcean API token, or
  3. anything else (that is upcoming in my ./algo script that stopped due to #2)?

Details

If these dependencies (between a Wireguard rig and DNS+DO_API) are real, then there are fundamental things about Wireguard I (grossly) do not understand.

This video shows (I think?) a simple Wireguard peering setup, with no DNS or hosting-provider-interfacing incantations. Why can I not get something like this in an automated fashion from Algo?

And in this scenario, why does Algo care about what kind of hosting_provider is serving my Ubuntu 18.04.2LTS localhost (from which I'm installing and running cd /root/algo-master/algo; ./algo)?

fyi - here's a mish-mash of every pertinent variable I could find thus far (and finding all the pertinent variables is proving so far to not be easy), some of them are stdout from ./algo, others are config.cfg variables, to disable all the stuff I do not initially want. Not sure if I captured all of them. And I've not you tried running ansible-playbook vs ./algo--each of which which are effectively mutually-exclusive approaches, yes?

algo_provider "digitalocean"
algo_dns_adblocking "False"
algo_ssh_tunneling "False"
wireguard_enabled: true
dns_encryption: false
ipsec_enabled: false
dns_encryption: false

And here's ./algo requesting DO stuff (for what purpose I do not understand, per above) from my Ubuntu system running on DO

[cloud-digitalocean : pause] Enter your API token. The token must have read and write permissions (https://cloud.digitalocean.com/settings/api/tokens):

My initial install ecosystem:

I'm seeking the simplest way to create a minimally-working, Wireguard "VPN" on a single DO VPS (where we run a set of server apps) running Ubuntu 18.04.2 LTS interfacing with (for now) less than 20 total macOS, Linux, Apple iOS, and Android clients without having to understand/learn/install/configure all the procedures. A very cursory read of every Wireguard install blog I read suggests (to me, at first glance anyway) that all the procedures could be automated with some simple read of exchange of keys between peers (with each server/client automated-install or automated-configuration software taking as input public keys from their peers), especially with what appears to be the prepackaged Wireguard apps for most if not all of the client-side platforms I listed above.

Am I missing something?

I'm seeking an automated-install rig to do the above. So far the only candidates I've found are Algo and https://github.com/mina-alber/wireguard-ansible. Algo has (as of 2019-09-06) 14k+ github.com stars. mina-alber/wireguard-ansible has 43. So I'm trying Algo first. Alas, I'm starting to wonder if Algo might be "too much Swiss army knife" and thus causing unnecessary problems (like above dependencies) for my initial, smaller, Wireguard-only scenario.

The first line of the README.md reads:

Algo VPN is a set of Ansible scripts that simplify the setup of a personal IPSEC and Wireguard VPN.

I'm really hoping this is the case -- for Wireguard, only -- and that the problems I'm experiencing thus far are me being an ignorant (Algo) user.

If it can, it will save my team lots of effort for many different server/ecosystem installs. Otherwise, I'll try https://github.com/mina-alber/wireguard-ansible or (ugh) we have the develop the automation ourselves, which would very-unfortunately take our efforts away from more-important things.

Thoughts?

johnnyutahh commented 5 years ago

Expanding further:

From TC1977's post (which is much appreciated, thank you TC1977):

ansible-playbook main.yml --skip-tags ipsec -e "provider=ec2
> server_name=algotest1
> ondemand_cellular=false
> ondemand_wifi=false
> dns_adblocking=true
> ssh_tunneling=true
> store_pki=false
> region=us-east-1"

In my scenario, why must one specify a provider, server_name, and region? Wireguard does not need to know these things. I specifically do NOT want it to know these things. (Minimizing dependencies and simplifying system components is critical to robust [eco]system architecture.)

I do not understand. What am I missing?

My best guess: Algo (maybe?) wants to be a Leatherman Multi-tool. However, I'm (initially) only seeking pliers that won't accidentally cut me. Thus far, it feels like I can't get the simple pliers to work without being forced to pry open all the other Multi-tool functions.

jackivanov commented 5 years ago

You don't understand how Algo works. Algo is a software that spins up a server in a cloud for you. That's why you have to specify all those api tokens and other variables. You don't need to specify them when deploying locally. From your message it seems like you are deploying locally, but for some reason you chose the cloud DigitalOcean deployment, instead of existing ubuntu server.

johnnyutahh commented 5 years ago

That's why you have to specify all those api tokens and other variables. You don't need to specify them when deploying locally.

Right, got it. I overlooked the the menu-choice number 10, my bad:

What provider would you like to use?
    1. DigitalOcean
    2. Amazon Lightsail
    3. Amazon EC2
    4. Vultr
    5. Microsoft Azure
    6. Google Compute Engine
    7. Scaleway
    8. OpenStack (DreamCompute optimised)
    9. CloudStack (Exoscale optimised)
    10. Install to existing Ubuntu 18.04 or 19.04 server (Advanced)

...and now it's asking me for a public IP address (which seems reasonable) because it must verfiy the certificate:

[local : pause]
Enter the public IP address or domain name of your server: (IMPORTANT! This is used to verify the certificate)
[localhost]
:

What certificate? Wireguard simply swaps public keys. Maybe "certificate" means "public key" in Algo-speak, for this context?

You don't understand how Algo works. Algo is a software that spins up a server in a cloud for you.

You're right. I'm a new Algo user. And a new Ansible user. I have no idea how Algo works. It might be worth considering adding a README.md blurb that reads "Algo is not meant to be run on the server your installing the VPN. Those who are not experienced in Ansible should not be using Algo." Or something like that.

My hope was to run a utility that would hide complexity from me so I didn't have to figure everything out. We like the "just run this one-line command on your server and it just works" paradigm. Makes our world much easier. Maybe Algo was not meant to provide that kind of ease, and I need to reset my expectations?

Or, maybe someone can provide the ansible-playbook one-liner command that can point me in the right direction for my install?

Somewhere, somehow, Wireguard peers need to share public keys -- correct? I have not yet seen that spelled out how that happens. I'm hoping to find some ./algo or ansible-playbook stuff/interaction/config_file/etc that handles this.

jackivanov commented 5 years ago

You don't need to be familiar with Ansible. The Advanced deployment is for advanced users, if you don't know how to proceed, we suggest you to use the cloud installation. You just run ./algo and answer the questions, as simple as that. For one line command see the docs and scripted deployment (this is what you probably are looking for)

johnnyutahh commented 5 years ago

Two points:

  1. Scripted deployment - yes!

Thank you, very helpful. This is definitely some of the magic we're looking for. As we plan run our own Ansible deployments in the future (migrating from an older, less-desirable auto-deployment platform).

Suggestion: if you want to serve "old school / power users" like my team, you might consider adding a line to your README.md that reads something like "For advanced users familiar with setting up their own firewall rules, IP addresses, etc, consider bypassing the regular install scripts and go to scripted deployment."

  1. ./algo generated Wireguard ./configs --> questions below, at end of this post

I ran with the interactive ./algo script and supplied the localhost (Ubuntu 18.04.2 LTS) server's lone public IP address (and I blew off concernt about "certificate," whose question from above remains unanswered) and ./algo ran with no further errors. (Woo hoo!)

So among other ./configs output goodies, I see this (with 'xxxx' / [IP_address] for the "private" parts, I think?):

root@node110 Sep 06 15:17:00 /root/.../165.22.41.9/wireguard# cat johnny-iPhone8.conf 
[Interface]
PrivateKey = xxxxxxxxxxx
Address = 10.19.49.2/24 
DNS =  1.1.1.1,1.0.0.1 

[Peer]
PublicKey = /IiePiFBJMAZfeQOcENtM5KpRlu3qkoP7w0XUt3EsCY=
PresharedKey = xxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 0.0.0.0/0
Endpoint = [IP_address]:51820
root@node110 Sep 06 15:17:21 /root/.../xxx.xxx.xxx.xxx/wireguard# 

Questions:

  1. Does the DNS field matter, since I'm not using any (I think?) DNS-specific stuff? ie, can I just blow it off?
  2. Do I give the PublicKey, Endpoint, PresharedKey (and nothing else) to the Wireguard peers/clients?
  3. The AllowedIPs are the IP addresses of the clients, server(s), something else? (This is where my newbie-ness/ignorance of Wireguard shows, too.) Or is this another artifact I give to the peers/clients?
  4. Why is the 10.19.49.2/24 (presumably the private-VPN address) address (seemingly) hard-coded in the Algo software? Can I [re]configure this somehow?
TC1977 commented 5 years ago

@johnnyutahh Really, Algo pretty much is a turnkey solution, if you want it to be - there's no need to mess with the installed defaults unless you know what you're doing. You're already done deploying the server locally (which is the environment that causes the most frequent issues), now just send out config files or QR codes and call it a day.

To answer the question you had farther up the thread, about the 'verify the certificate' language - I believe that's because the default local install uses IPsec, which does need a certificate. You're installing with ipsec_enabled=false, so it doesn't apply to you.

Question 1 - That's the DNS server configured for your server, which is either Cloudflare or (if you enabled DNS adblocking) the VPN server itself. You shouldn't mess with it unless you want to change DNS servers. Note that this can also be configured on the individual client device, using the appropriate Wireguard app.

Questions 2 and 3 - The fields you're asking about are all part of the standard Wireguard client .conf file. 0.0.0.0/0 is required if you want your client to be able to connect to the Algo server from any IP address. Client deployment instructions are in the README. I highly recommend QR codes rather than sending out .conf files - you can send them over FaceTime instead of worrying about insecure email or other methods of delivery.

Question 4 - That's the private subnet for the VPN. The only reason to change that would be if you were already using that exact same subnet on a local network somewhere. You'd need to reconfigure that not only on every single client.conf, but also on the server-side settings in /etc/wireguard/wireguard.conf. The easier way would be to modify wireguard_network_ipv4 in config.cfg before you run Algo (if you run the non-interactive ansible-playbook, it will pull any needed variables that you don't specify out of this file). Once again, not sure why you'd want to change that.

jackivanov commented 5 years ago

I'm closing this for now. You may use Gitter for further questions