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

External State Management #116

Open
ChrisPortman opened this issue May 27, 2024 · 4 comments
Open

External State Management #116

ChrisPortman opened this issue May 27, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@ChrisPortman
Copy link

I would like to be able to run a WAG instance in a cloud environment where it is deployed as a single instance that is periodically replaced by a new vm (e.g. EC2) instance. The instance cannot run NAT so that we preserve the traffic source information in application logs - hence the single instance.

Currently the stable version uses an sqlite database local on the machine, and the new beta appears to be using an in process etcd solution.

Ideally, it would be great if the users/device/other_state could be stored in a database SaaS offering (RDS postgres or similar) so that WAG servers could by brutally replaced without loosing state. Potentially allowing WAG to connect to an external etcd cluster could be an option, but it doesnt appear like any of the cloud providers provide a SaaS etcd service akin to RDS.

Perhaps if the state management could be restructured as an interface, so that a sqlite, etcd, other data store implementation could be supported, i'd be keen to contribute a postgres option

@NHAS
Copy link
Owner

NHAS commented May 27, 2024

Hi Chris, Im going to assume you want to destroy the wag boxes aggressively so it becomes incredibly difficult for an attacker to maintain persistence on your ingress machine?

Or is this for updates/infra as code?

I'd be more than happy for this to be an addition to wag as I think it makes sense.

I am currently working on a couple things which will delay my involvement in this. Such as moving on from eBPF, Websocket challenge response, and better etcd cluster roaming.

@NHAS NHAS added the enhancement New feature or request label May 27, 2024
@ChrisPortman
Copy link
Author

Hi Chris, Im going to assume you want to destroy the wag boxes aggressively so it becomes incredibly difficult for an attacker to maintain persistence on your ingress machine?

Or is this for updates/infra as code?

Yep, both of these essentially. :) Happy to help

Such as moving on from eBPF

Side Note: Are you looking to replace eBPF?

I am currently working on a couple things which will delay my involvement in this.

I'm happy to help - let me see how my next few weeks are shaping up, might be able to have a stab at it.

@NHAS
Copy link
Owner

NHAS commented May 27, 2024

I am indeed looking to replace eBPF because I've realized my solution is much more complicated than it needs to be and it can all be squashed into just pure go.

There are also a bunch of other thing its may enable, like better cluster roaming as then I may fork wireguard-go and add in the ability to set keypairs for different peers. Which would mean that even under aggressive loadbalancing users would never face downtime

@NHAS
Copy link
Owner

NHAS commented May 27, 2024

Im more than happy for anyone (yourself included) to open pull requests! With the obvious caveat that I might be quite picky with what people implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants