Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wireguard #9

Open
leoTlr opened this issue Nov 12, 2019 · 8 comments
Open

wireguard #9

leoTlr opened this issue Nov 12, 2019 · 8 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@leoTlr
Copy link
Member

leoTlr commented Nov 12, 2019

We plan to switch from openvpn to wireguard for performance reasons

@c-goes c-goes added documentation Improvements or additions to documentation enhancement New feature or request labels Nov 14, 2019
@c-goes
Copy link
Member

c-goes commented Nov 15, 2019

team number must be encoded in the ip addresses for #12 to work
for openvpn we have 10.41.(team number).X/24
Can we use 42 for wireguard?

@antfeh
Copy link

antfeh commented Nov 20, 2019

When using this setup on a productive server, does it spawn the two vms like in the development environment, or is everything installed directly on the machine hosting the ctf?

@c-goes
Copy link
Member

c-goes commented Nov 20, 2019

@antfeh directly on the host like described in https://github.com/hsasctf/lxctf/blob/master/docs/local.md. the two VMs are just the development environment.

I will adapt the document after pushing the dynamic inventory.

@c-goes
Copy link
Member

c-goes commented Nov 24, 2019

@antfeh Thanks for your work. A little feedback to your branch: "delegate_to: 127.0.0.1" is meant only for tasks should run on the system running Ansible. For the "local" installation, the remote and local system are the same. But it's not the case for development environment or other undocumented installation types. When you install wireguard and copy the configuration it should not run on 127.0.0.1.

Maybe in the wireguard case it would be easiest to run everything at remote (e.g. template to remote like here https://github.com/hsasctf/lxctf/compare/feature/wireguard#diff-d8238564479491178cd9312e2a4ec074R238) and then fetch or slurp the files to the paths in role (https://docs.ansible.com/ansible/latest/modules/fetch_module.html#fetch-module, https://docs.ansible.com/ansible/latest/modules/slurp_module.html).

@c-goes
Copy link
Member

c-goes commented Nov 24, 2019

Instead of my suggested changes, we can also take out the controller VM from development environment, should work better then. And it's more like a production environment.

@c-goes
Copy link
Member

c-goes commented Nov 25, 2019

@antfeh for idempotence you should use "creates" for the shell tasks that create files https://docs.ansible.com/ansible/2.8/modules/shell_module.html
won't it overwrite the keys after each run or raise an error if the key exists?

@antfeh
Copy link

antfeh commented Dec 2, 2019

@c-goes wireguard automatically overwrites the existing keys, so there should be no problem.

@c-goes
Copy link
Member

c-goes commented Dec 2, 2019

@antfeh
In my opinion it's a problem if the keys change after every run. You cannot fix problem after the keys are handed out and the configuration is destroyed when Ansible is run by accident after the keys are given to users. Please confirm that the keys are not overwritten.

You could create a pull request and I'll show you what changes are needed

@antfeh antfeh mentioned this issue Dec 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants