Closed thecoshman closed 4 months ago
All the "hidden" rules will be generated by code and never exposed to the user. Only "extra bits" like giving access to peer-groups for certain targets is controlled by the data. So the UI does not even mention IP tables or its rules.
IMO, we do not need this ticket.
I'm happy with the idea of the raw IP table rules being abstracted, but I don't like the idea of this system forcing things directly. It takes away potential flexibility of the underlying system
In that case, vi (or any editor of your choice) and the configuration files are the best choice. This UI is to allow even layman to manage the VPN without knowing the intricacies of IPTables chains etc.
"here be demons". There's a difference between making things easier to manage Vs taking away all control
"here be demons". There's a difference between making things easier to manage Vs taking away all control
It has to appear less daunting to use initially. Or else people will stop by, have a look at the screenshots and move on.
Then we can provide a default for it, based on the presumption they are using WG via docker compose like we will suggest in documentation, but if they want to deviate, they are free to do so. One the big advantages to this being a UI is that we can provide explanations and examples within the UI for the controls we are giving people.
Let's get version 1.0 out which does minimal stuff we plan to do and then start adding frills to it.
Ah, I see in the latest develop
right now, on the Server Configuration page, you've got what I'm looking for
@thecoshman With the way this project is progressing, I think this is not required anymore. The users can live with the IPTables rules generated by the app or find some other solution.
In #14 you are setting things up to configure the IPTable rules based on the peers that are configured. But if I'm not mistaken, we also want a way to provide the IP masquerading rules that handle the NAT issues of WG running within Docker